Bug: rules_ios apple_framework does not support SwiftUI Previews in rules_xcodeproj

[m-petes]

Description

SwiftUI Previews do not work for rules_ios apple_framework targets in rules_xcodeproj. This can be seen in the existing rules_ios example in the repo by using the ContentView.swift file in the UI module.

By default, the swift files in the apple_framework target only show as included for the static library target created by rules_ios, not the framework target. This prevents the preview from working since it needs to be a part of the framework target.

If I manually add the the SwiftUI preview file to the framework target and select that framework as the current scheme in my xcodeproj, I receive an error.

HumanReadableSwiftError

ProviderError: ProviderError: noPreviewInfos(runDestination: Simulator - iOS 16.2 | iphonesimulator | arm64 | iPhone 14 Pro Max | no proxy, thunkConfiguration: <IDEBuildOperationConfiguration buildCommand: 8, buildParameters: <IDEBuildParameters:0x6000a024f3e0:action=build:command=<IDEConcretePrimitiveSchemeCommand:0x600003338150:Run>:config=Debug:dest=iPhone 14 Pro Max:arch=arm64:workspaceArena=<IDEWorkspaceArenaSnapshot: 0x600000859e30>:
overridingProperties=(
{ // Preview overrides (immutable)
   DSTROOT = 【𝗟𝗶𝘁𝗲𝗿𝗮𝗹𝗦𝘁𝗿𝗶𝗻𝗴:/Users/michaelpeterson/Dev/rules_xcodeproj/examples/rules_ios/DerivedData/rules_ios/Build/Intermediates.noindex/Previews/UI (Static Framework)/ReleaseProducts】
   ENABLE_PREVIEWS = 【YES】
   OBJROOT = 【𝗟𝗶𝘁𝗲𝗿𝗮𝗹𝗦𝘁𝗿𝗶𝗻𝗴:/Users/michaelpeterson/Dev/rules_xcodeproj/examples/rules_ios/DerivedData/rules_ios/Build/Intermediates.noindex/Previews/UI (Static Framework)/Intermediates.noindex】
   SYMROOT = 【𝗟𝗶𝘁𝗲𝗿𝗮𝗹𝗦𝘁𝗿𝗶𝗻𝗴:/Users/michaelpeterson/Dev/rules_xcodeproj/examples/rules_ios/DerivedData/rules_ios/Build/Intermediates.noindex/Previews/UI (Static Framework)/Products】
},
):
collectBuildTimeStatistics=NO
collectTimelineMetrics=NO>, executionEnvironment: Optional(<IDEExecutionEnvironment: 0x123b7b860>), singleFileToBuild: nil, buildLog: nil, parallelizeBuildables: true, dontActuallyRunCommands: false, buildImplicitDependencies: false, skipDependencies: false, buildables: Optional([<Xcode3TargetProduct:0x60000064e8e0:UI. blueprint:<Xcode3Target:0x1553a6660:UI (Static Framework)>>]), subsetOfBuildables: nil, buildDescriptionID: nil, scheme: Optional(<IDEScheme:0x15539b100:'UI (Static Framework)'>), schemeTask: 0, clientInfo: nil>, blueprintName: UI (Static Framework), sourceFilePath: /Users/michaelpeterson/Dev/rules_xcodeproj/examples/rules_ios/UI/ContentView.swift, thunkVariantSuffix: __XCPREVIEW_THUNKSUFFIX__)

I also tried adding link_dynamic = True to the UI apple_framework target and resolving the Info.plist issues that came with that, but I still received the same error.

Thanks so much!

Reproduction steps

You can use the rules_ios example in this repo with the ContentView.swift SwiftUI preview in the UI module, and follow the steps I tried above to see the outputs.

Expected behavior

It would be awesome if SwiftUI Previews were supported with minimal configuration needed in rules_ios apple_framework targets that are used in rules_xcodeproj.

rules_xcodeproj version

1.9.1

Xcode version

14.2

Bazel version

6.2.1

rules_apple version

No response

rules_swift version

No response

Additional information

No response

[thiagohmcruz]

@m-petes this is working in the Incremental generation mode which is going to be the default. In the epic there are instructions on how to test it, it would be great if you could help us verify it's fixed there for you too.

This is the diff to enable it leveraging link_dynamic (bundle_id is required by rules_ios when linking dynamically):

diff --git a/examples/rules_ios/UI/BUILD b/examples/rules_ios/UI/BUILD
index 9e387dcf..e791f5c5 100644
--- a/examples/rules_ios/UI/BUILD
+++ b/examples/rules_ios/UI/BUILD
@@ -8,6 +8,8 @@ rules_ios_apple_framework(
     srcs = glob(["*.swift"]),
     infoplists = ["Info.plist"],
     module_name = "UI",
+    link_dynamic = True,
+    bundle_id = "com.foo.ui",
     platforms = {
         "ios": "15.0",
     },

cc @brentleyjones worth trying to find a fix in the legacy one? IMO even if we find one it's likely to be short lived?

[brentleyjones]

I don't think it's worth trying to fix in legacy generation mode. I believe numerous fixes in incremental generation mode combined results in this working.

[m-petes]

Amazing!!! :D I can definitely try that out.

[m-petes]

Yep, fixed in incremental generation mode! :D Thank you so much!