Swift 5.3 SwiftPM Resources in tests uses wrong bundle path?

Does Xcode 12.5 fix this?

Also does Apple have any plans to support Swift Packages being used as a replacement for Xcode project files? Because right now, every time we try to convert an Xcode project into a package, we run into yet another bug in the SPM-Xcode integration.

As of Xcode 12.5 Beta 3, no.

Won't find out until a future WWDC. Apple is very tight-lipped about it's proprietary products. Also, from an Xcode point of view, it has to support multiple languages, Interface Builder and other tools, Xcode Server, and a bunch of other stuff that is rapidly going to be at odds with open-source SPM.

1 Like

Also does Apple have any plans to support Swift Packages being used as a replacement for Xcode project files? Because right now, every time we try to convert an Xcode project into a package, we run into yet another bug in the SPM-Xcode integration.

One can dream.

Its nice not getting merge conflicts every time someone changes a file.

It seems that this is fixed in Xcode 12.5 RC - using .module has correctly been finding the bundle during unit tests.

1 Like

I'm afraid this issue is still not fixed in Xcode 12.5 RC. My project is still crashing in 12.5. I have public computed property that returns the .module from my swift package.

// Style Package
public extension Bundle {
    @objc
    static var styleBundle: Bundle { .module }
}

Im referring the that bundle from one of my Objective C module like below.

@import Style;

+ (void)load
{
    // Crashes here
    NSBundle *bundle = [NSBundle styleBundle];
}
1 Like
  • (void)load

Curious why are you using + (void)load here? "load" This method has specific behaviors that could be why you're seeing a crash. See:

I created a feedback for it with a demo repo with the issue for apple: GitHub - simonpierreroy/bugSwiftPMResources

I can't believe this. I just ran into the same problem on a different project, at a different company--and when I searched for it, I found my own comment from a year ago. I don't know what's worse--that I didn't remember having the problem before, or that Apple still hasn't fixed it. :man_facepalming:

1 Like

@NeoNacho @eskimo sorry for the shout, but maybe you know the best people that could provide either an update or some help… it may be that this is not believed as good practice (unit tests are meant not to use resources, it could be a good argument) and/or the intended use would be say with a test iOS app project that uses the SPM package in question (and thus you have a proper integration / E2E test), but I am not sure what the exact use cases are that trigger this and it feels a middle ground that is not unsupported or discouraged nor working (this thread dates back years).

1 Like

Unit tests should absolutely be able to use resources. For example, whenever I test API compliance, I save server responses as JSON files and inject those into mock servers when unit-testing.

In practice, what I see in many open-source projects is that they continue to do development (including unit testing) using their Xcode project files, and reserve the Package.swift file for others to integrate against. One easy way to tell this is to see whether Package.swift includes a testTarget().

2 Likes

I do not necessarily disagree but those would be integration tests more than unit tests which should not be hitting the network or the filesystem. Anyways, it does not change the heart of the problem in this thread and I hope it is addressed and/or acknowledged.

Wanted to migrate from Cocoapods to SPM, but we are hitting this and is blocking us.

Here is a workaround which should help you: Add workaround · RemiBardon/xcode-preview-spm-resources-bug@6599c31 · GitHub

I don't know why Apple still hasn't fixed it, but I've used it in multiple projects now, and it always worked.

2 Likes

This is awesome! Thank you.
This bug is infuriating, because it completely eliminates much of the benefit of Swift Package Manager and SwiftUI Previews.
Either you had to accept that you weren't gonna use SwiftUI Previews, or you'd have to build all your views etc. in the main app target, which doesn't fly when you want to build a heavily modularised application.

have you been able to check with xcode 14 beta?

I have, and it's still not fixed in either of the betas that have been released.

1 Like

too bad... i wonder how this can be fixed... im assuming the code for this is not in the open-source part of swift?

I think I tried, and @rhysmorgan did too, so I'm pretty sure it's still broken :confused:

Honestly, I didn't think about contributing to fix it. I thought it would be temporary, but now it's starting to be a long time :hourglass_flowing_sand: