There's a really frustrating crash with Xcode Previews because it cannot find the design resources package using the Bundle.module accessor (filed FB9479423). Is there something wrong with the package setup?
I have some Swift packages dependent on another package containing design resources. Xcode Previews do not work because XCPreviewAgent crashes:
CompanyDesign/resource_bundle_accessor.swift:27: Fatal error: unable to find bundle named CompanyDesign_CompanyDesign
Is there some other way packages should be locating their resources, rather than relying on the Bundle.module static property?
Our current work around is to build and run a new Xcode app project that includes the package as a dependency, builds the library target and uses the library API in the Simulator (Xcode Previews are a bit hit and miss in this case). But it's a really messy solution requiring us to keep unrelated Xcode projects up to date and working properly.
This is a known issue when using resources of transitive dependencies while previewing a standalone package. Using an app as the preview host as you are doing is the recommended workaround at the moment.
Thanks for the reply, in appreciate it because you took the time to confirm I’m on the right track.
Is there anything that can be done about it SwiftPM side that I could contribute towards or do I point people to FB9479423 and endure it in the hope it is fixed one day?
To re-iterate, while I can use Xcode projects, it’s not a great work around because I end up creating lots of unrelated projects that do not keep up with each other (if the APIs in the common package changes, I don’t get compiler errors for unopened projects). I could create less projects but that starts to affect the Xcode Previews ability to respond quickly to source changes.
Yep, I agree that having to create a project is not a good workaround in any way, just wanted to confirm that this is the only way to go right now.
Thanks for offering to contribute, there isn't really anything to be done from the SwiftPM side of things, this all happens inside Xcode. Basically what's happening is that normally resources only get embedded into "top level" targets such as apps, so in theory resources wouldn't work at all for previews of standalone packages. We implemented a minimal solution to support resources in the package you are actively previewing and what's missing is tackling this for transitive dependencies as well.
That seems to fix the issue as long as the file you are previewing is directly included as a dependency in the app target. If it’s not, you need to set your active scheme to the scheme that owns that file. It’s a lot better than having to add additional app targets though!
Thanks for sharing this! My team is trying this to mitigate Xcode project explosion until the Xcode build system can deal with all resources of the dependency graph.
I have the same problem while developing a multi-module iOS app. The question I have is if multiple module create their own Bundle extension with the same variable how Swift resolves the ambiguity? In Objective-C there is no guaranty if two modules add the same method/var in a type using a category which will be called, in Swift is there anywhere documented how this is handled?
Using the SPM Plugin mechanism I've implemented this workaround by automatically generating the Bundle extension (called Bundle.current) during the prebuild phase.
It does work quite well for our project with multiple modules providing resources that are shared across targets .
An example implementation can be found here GitHub - ctreffs/swiftui-previews-module-resources-fix: Swiftui Xcode previews module resources fix
Would appreciate some feedback from the community before converting this into a standalone plugin package.
I could do that, but as @NeoNacho already stated that is not a SPM thing to fix at least as far as I understand this. Opening a PR to SPM for this would leak Xcode specific implementation details to SPM which is not intended.
@Fogmeister We fixed a bug that could cause this symptom in Xcode 16.2 beta 1 (if it's previewing an iOS app in the simulator) / macOS 15.2 beta 1 (if it's previewing a macOS app) / iOS 18.2 beta 1 (if using an on-device preview for iOS). If you're able to try the beta and still see the issue, please file a feedback with Apple so we can look into it further.
I'm not aware of any changes to embedding of package resources, so I would assume you would still need this workaround if you needed it before (maybe worth double checking though!). I was only commenting on a regression in Xcode 16 where it was finding the main app instead of the correct bundle path.
I have two packages. One for a feature, another containing design resources (icons, illustrations, colours etc). The feature package is dependent on the design package and the feature implementation accesses resources provided by the design package. Using Xcode 16.2 beta 1, I was able to remove the BundleFinder type and associated code in the design package and preview the feature package with Xcode Previews without crashes. To rule out false positives, I reset the package cache, cleared the build folder and re-opened Xcode.
This is very positive news and I hope you have similar findings!
On a semi related note, could you ping whoever it is that controls the Xcode release notes to get them updated with notes for fixes like this? Right now 16.2b1 shows nothing.
Wow, I had an epic battle with packages to fix it in 16.0 (and I won), but my colleagues just figured out this thread and confirm that it works with 16.2beta without any changes. About four days of developer productivity down the drain.
What happened:
Local packages set-up
We are re-using SharedModel and SharedUI across all packages
One of these packages is called Identity and takes care of all things related to sessions and identity
We created a new module for the home screen, that imported SharedUI
We were adding a profile related screen there, that needed Identity to get the current profile
As soon as we added Identity (for it's logical / data side), previews stopped working with bundle errors
I tried the following:
Created a new package for the profile screen
Suspected a UI-in-UI issue, or an issue where SharedUI was imported from two sides and it got confused. Split up Identity in IdentityDefinitions (only logic + data + SharedModel) and IdentityUI (only UI + IdentityDefitions) -- this didn't work
Then I started suspecting that we might have an issue in SharedModel. It had some third party libraries for legacy reasons. Butchered out the third party libraries -- stuff started working
It turned out that in this particular sequence of attempts to fix it the last step of removing an HTML conversion related library fixed the issue.
So a certain combination of them fixed the issue. Just getting rid of the third party library for HTML without any of the other changes still had the issue under 16.0
Xcode 16.2 beta did not need any of these changes.
