Set APPLICATION_EXTENSION_API_ONLY on a SPM package

Panajev · July 17, 2021, 5:47pm

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.

lhunath · July 17, 2021, 5:57pm

Add NS_EXTENSION_UNAVAILABLE_IOS("...") to your method signature.

lhunath · July 17, 2021, 7:08pm

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.

paulb777 · July 18, 2021, 4:53pm

Thanks! Reference at Fix Xcode 13 beta 3 build issues by paulb777 · Pull Request #8405 · firebase/firebase-ios-sdk · GitHub

malone · July 19, 2021, 9:24pm

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.

mbrandonw · July 19, 2021, 10:54pm

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.

afarnham · July 20, 2021, 3:25am

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.

frank.schlegel · July 20, 2021, 6:20am

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?

simon.krucinin · July 20, 2021, 9:11am

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.

Panajev · July 20, 2021, 9:59am

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?

Logged: [SR-14944] SwiftPM and app extensions (compiles every package with the -application-extension flag) · Issue #4402 · apple/swift-package-manager · GitHub

frank.schlegel · July 20, 2021, 11:31am

Done. Thanks for the effort, Goffredo!

NeoNacho · July 20, 2021, 5:04pm

Thanks for all your feedback and bug reports, we'll take this into account and will reconsider the behavior here.

paulb777 · July 20, 2021, 9:45pm

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.

S2Ler · August 10, 2021, 6:24pm

Quick update: Xcode 13b5 reverts the change

pyrtsa · August 11, 2021, 1:30pm

I too can see it in the release notes. But have you or has someone actually verified that?

We still seem to be hitting the same issue with some 3rd-party libraries we use. They keep getting built with the -application-extension flag passed to swiftc by default.

S2Ler · August 11, 2021, 1:35pm

It works as before for me. So no more build errors.

billThePill · August 14, 2021, 4:43pm

Xcode 13b5 did not improve the experience in my scenario. My project is very large and uses 10 packages (7 from GitHub and three developed internally).

I created a small iOS project that included all the packages and imported them all into the empty UIViewController.

All went well until that point without any compilation issues.

Then I added a new, empty Sticker Pack extension target to the project, recompiled, and got all the failures ('shared' is unavailable in application extensions for iOS: Use view controller based solutions where appropriate instead.)

Removing the empty Sticker Pack extension from the project, all is good again.

So, it seems that if your project includes an application extension (even if the extension does not use the packages) the packages are compiled with the -application-extension flag/capability to allow them to be (potentially) included with ANY target in your project.

Is there any way around this?

billThePill · August 15, 2021, 4:50pm

Disregard my comment. I had installed Xcode 13b5 but may have been running Xcode 13b4 when I did the test. After a reboot and methodical retest, I am able to get a clean compile with Xcode 13b5 with my included packages and sticker pack. Sorry for any confusion.

FelixLisczyk · August 20, 2021, 9:17am

On Xcode 13b5 I get linking against a dylib which is not safe for use in application extensions warnings for all my dynamically linked Swift packages. I was able to reproduce this with a new project:

Create a Swift package and set its product type to dynamic.
Create a watchOS app or iOS app extension.
Import and link the Swift package as a local dependency.
Build the app.

Result:

ld: warning: linking against a dylib which is not safe for use in application extensions: ~/Library/Developer/Xcode/DerivedData/MyApp-gtbdztwxcysffgeyceqelchgacqm/Build/Products/Debug-watchsimulator/PackageFrameworks/MyPackage.framework/MyPackage

The warnings don't appear in Xcode 12. Is this expected behavior or still a bug?

fnuky · September 15, 2021, 8:40am

Same problem at me with Xcode13 RC version, did you find any solution? adding

swiftSettings: [
  .define("APPLICATION_EXTENSION_API_ONLY=YES"),
]

Into package definition does not work for watchOS and also iOS.