FIX 'shared' is unavailable in application extensions for iOS

[knox]

This fixes the AppExtension target (see #459)

[wtmoose]

The iMessageDemo extension works for me. Got repro steps?

[knox]

I have a share extension for my app and i'm integrating SwiftMessages with cocoapods like this:

target 'MyApp' do
  pod 'SwiftMessages/App', :git => 'https://github.com/knox/SwiftMessages.git' #'9.0.0'
end

target 'MyAppShare' do
  pod 'SwiftMessages/AppExtension', :git => 'https://github.com/knox/SwiftMessages.git' # '9.0.0'
end

Will try to set up a basic example if you wish.

[knox]

I was looking at the given iMessageDemo but could not figure out how that project setup works.

So i created an example Xcode workspace with an empty app and share extension that integrates SwiftMessages using CocoaPods.

This example demonstrates the problem of accessing to unavailable API. To reproduce:

$ cd ShareDemo
$ pod install
$ xcodebuild -workspace ShareDemo.xcworkspace -scheme ShareDemo -destination 'platform=iOS Simulator,name=iPhone 12'

[wtmoose]

Yeah, the iMessageDemo adds SwiftMessages directly and that setup doesn't have an issue. The problem is only with CocoaPods, which creates its own SwiftMessages framework and sets APPLICATION_EXTENSION_API_ONLY = YES.

[knox]

The problem is only with CocoaPods, which creates its own SwiftMessages framework

I dont think the problem has to do with CocoaPods. Thats just one way how to spot it.

The actual problem is that certain API is not available in app extensions. So code aiming at both regular apps and extensions at the same time has to deal with this somehow. Despite not beeing a very elegant approach using compiler flags such as APPLICATION_EXTENSION_API_ONLY seems a quite common one.

And that is how it has been done in SwiftMessages before, too. Any calls to UIApplication.shared are wrapped into this flag. The change proposed in this pull request simply extends this approach to the recently introduced but yet unwrapped call.

So if SwiftMessages shall be usable for app extensions in the future - and i'd really appreciate if it would - the issue of unavailable API has to be addressed in one way or another.

iMessageDemo adds SwiftMessages directly and that setup doesn't have an issue.

I am not familiar with iMessage extensions but given that UIApplication.shared is marked as unavailable API i rather see a misconfiguration in the iMessage demo setup: the compiler does not know it is compiling SwiftMessages for an app extension target. That's why it does not complain at compile time but the code would crash at runtime.

[wtmoose]

I am not familiar with iMessage extensions but given that UIApplication.shared is marked as unavailable API i rather see a misconfiguration in the iMessage demo setup: the compiler does not know it is compiling SwiftMessages for an app extension target. That's why it does not complain at compile time but the code would crash at runtime.

Not quite. It works because all of the call sites are wrapped in conditionals.

[knox]

Ok, so you say there is no code path to the unavaible API at runtime. Nevermind.

But it's still unavailable API and so the code cannot be compiled for an extension target. If you don't like the proposed change are you going to provide another solution? How should the change be improved to fit your expectations?

[wtmoose]

The change is fine

[wtmoose]

Closing this because they changes were made in the wrong branch, but I've put up a work/9.0.2 branch with your change as well as changing the iMessageDemo project to CocoaPods. If you want to take a look, I'll hold off on releasing 9.0.2 for a bit.

[knox]

I've upgraded my app to the work/9.0.2 branch successfully and looked at the iMessageDemo at a glance. Thanks for resolving the issue.

[wtmoose]

It's released