Something makes me think the decision is #2, but if that were the case I think that saying it earlier on and interacting as Apple with some of the major third parties libraries that invested in the SwiftPM ecosystem would have been nice.
NS_EXTENSION_UNAVAILABLE_IOS("...") to your method signature.
In the interim I am toying with the idea of performing runtime checks using a combination of
[[[NSBundle mainBundle] bundlePath] hasSuffix:@".appex"] and
-performSelector: to guard blocks and hide safe API usage from the compiler.
Just wanted to echo the request for some setting at the
Package.swift level. The app I'm working on is entirely inside of SPM, so this change means my entire codebase will be polluted with these annotations, even though we don't have any app extensions.
I would like to add another data point to this thread. Our application is entirely built in SPM, and now fails to compile in beta 3. Adding enough annotations fixes it, but it's very strange to have to do that.
We spent considerable time migrating our code base to Swift Package Manager, starting around November of 2020, and finished this work 2 weeks ago. It is very large and very old by iOS standards (launched on day 1 of the AppStore). To suddenly find we need to annotate hundreds of methods is quite discouraging.
We do not have any app extensions.
I also found that now every package is always build with
-application-extension, even when not building an extension. As mentioned before, this breaks a lot of external (and internal) dependencies.
Also it seems wrong. Shouldn't this flag only be set when actually building an extension target?
Same here. Our app uses some app extensions, but they do not use any of the Swift packages, yet the 3rd party packages fail to compile in Xcode 13 beta 3. Adding annotations for every consumption is very tedious. It would mean dozens if not hundred checks.
Hello, could you please duplicate FB9337463 (I added a reference to the " -application-extension" flag). @NeoNacho should this be moved to an issue on the SwiftPM repo itself?
Done. Thanks for the effort, Goffredo!
Thanks for all your feedback and bug reports, we'll take this into account and will reconsider the behavior here.
Great! After going through the transition, we appreciate that our SDK customers will see issues at build time instead of runtime, but it would have been nice to have more control over the timing of the transition via an option.