Tell that to whoever wrote XCTest framework!
Someone in my org made a Swift package that adds some custom extensions to XCTest. But it won't compile because the package has bitcode enabled by default and XCTest doesn't.
Just another example of how SPM is not suited for mainstream use yet.
SPM is not really a viable replacement for Xcode project files as a way to define local modules. The way SPM is integrated with Xcode and the design of SPM itself are not built for the same use-cases as Xcode project files and do not allow you to do many things that Xcode projects can do. This makes it totally ill-suited for use as a replacement for Xcode project files for local use, and Apple and other people should never have started recommending it to people as such, because they made no effort to ensure feature parity or to guarantee that for a particular setting or use-case, SPM supports the same capabilities as Xcode project files.
For example SPM:
- does not support linking a package target to a third-party pre-built framework or XCFramework dependency outside the directory structure of the package itself
- does not support directly providing an .xcassetcatalog to consumers of a package
- does not support mixed Obj.C/Swift targets
- does not support linking a package target to a local Xcode project's build product
- does not support Xcode's "find implicit dependencies" properly and turning it off leads to phantom dependency cycles unless you list every package in your workspace in the build list
- does not support linking an Xcode project to a locally-defined Swift package if it uses any "unsafe" flags, which is clearly a bug but no effort has been made to fix it
Every time some measures have been taken to rectify some of these many problems, after going through the Swift evolution process, the resulting change to SPM winds up not addressing the actual need at all. For example when people complained SPM does not allow linking to a prebuilt binary, the "solution" for this was to allow SPM to link to prebuilt binaries—but only if they are inside the directory structure of the package itself, rendering this feature totally useless for most situations in which we need to link to a binary. Or when they added support for AssetCatalogs, they made it extremely limited by forcing you to write a public API to access anything from in the catalog—making this totally incapable of serving assets to a mixed Swift/Obj.C consumer because @objc Swift APIs in Swift packages can't be seen by Obj. C code in consumers of that package, due to the fact that the package framework that gets produced is always missing its Frameworks folder (and thus, there's no bridging header!).
I could go on and on; earlier this year it had become almost a part-time job for me to try to actually report all the SPM bugs and issues to Apple and to constantly get pulled into Zoom calls with other engineers who were running into yet another new bug with the SPM/Xcode integration and no clear solutions. Evenutally I got to the point where I will no longer recommend anyone to use SPM for anything else until I see some actual fixes in a future Xcode.
Which is sad because we can't even use SPM as a package manager due to all the performance issues related to that use-case. Just trying to add Firebase as a dependency takes 15-20 minutes to get past the first step where you paste in the repo URL into Xcode's "Add a remote package dependency" window. on a gigabit connection, because the UI is blocked until Firebase and all its package dependencies, and all those packages' package dependencies, are deep-cloned into a local cache. And then another 15-20 minutes after adding it as a dependency for the same operation to happen again.
12.5 did add the ability for Xcode to cache the result of all this madness so subsequent times when you open the project it will only take a minute or so, but since our CI system rebuilds each Jenkins node from scratch every time, we can't justify adding 20 minutes to our build times. Even if we could due to some new cacheing solution that doesn't exist yet, having all of Firebase's dependencies show up in the remote package dependencies list in Xcode causes the whole IDE to slow down noticeably for some reason.
I have nothing against SPM and I think it's fine for certain use-cases but it has not proven to be ready yet to replace Carthage for a large enterprise app and it's somewhat limited in how you can use it for replacing local Xcode projects. As long as you use it within the safe boundaries of what it currently does well, then it's fine, but this year we've been constantly running into issue after issue where SPM is unable to do something that, by all accounts, it should be able to do, and it's gotten to the point after multiple DTS tickets and no progress made in Xcode that I've started to wonder what's actually going on.
