Feature Request: Support for iOS app extensions

[mbektchiev]

Description

iOS App Extensions are the iOS way of enabling some of the rich native app experiences. For more info see the App extensions documentation page

Describe the solution you'd like
CLI should be able to:

• Add targets with their dependent files
• Embed the new extension targets’ products in the app target
• Allow each target to optionally reference NativeScript.framework. Note: WatchKit Apps can no longer support that after version 2.0 of watchOS.
• Provide ability to control behavior via additional keys in package.json

Describe alternatives you've considered
There are a couple of rather outdated proof-of-concept implementations with Today widgets available:
* https://www.nativescript.org/blog/making-a-today-widget-in-ios-with-nativescript-and-ui-for-nativescript
* https://github.com/NativeScript/ios-runtime/tree/master/examples/TodayExtension

They require manual changes to the Xcode project platforms/ios which is undesirable. The platforms directory is considered ephemeral -- it shouldn’t be committed in source control and should be eligible for safe deletion at any time.

Additional context

• By following the Today widget article, JavaScript code will be duplicated in both the app and the extension. When tns_modules is big this could significantly bloat the app package size. To solve this we could make the extension directory in App_Resources have its own package.json – this can potentially reduce the amount of duplicated modules.
• There’s a way to enable resource sharing between the two bundles. It might be better suited in order to avoid the above-mentioned duplication: https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html#//apple_ref/doc/uid/TP40014214-CH21-SW6
• If the extension and the app don’t need to share common JS logic it might be better to not refer NativeScript.framework and implement the logic entirely in Swift and/or ObjectiveC. These extensions are iOS specific and they can’t share code with other platforms (Android). Another great benefit will be that Xcode’s built-in tooling for UI and code writing could be used for developing them.

[NickIliev]

+1 from 1357156

[NickIliev]

Currently the above can be achieved by implementing the above "manually"- blog post here.

[adrian-niculescu]

Starting with the somewhat outdated blog post mentioned above I tried to do the manual steps to accomplish this.
It works +- some cumbersome things such as the fact that the auto-generated platforms/ios is affected.

The big problem that should be of a great concern at this point is this linker warning:

linking against a dylib which is not safe for use in application extensions: /<path>/sampleiOSToday/platforms/ios/internal//NativeScript.framework/NativeScript
This linker warning is explained in Apple's docs here. The problem is that some APIs are unavailable to app extensions
Apple warns there that:

The App Store rejects any app extension that links to such frameworks or that otherwise uses unavailable APIs

One problem in the NativeScript.framework is the usage of UIApplication.sharedApplication

NativeScript.framework in its current form cannot be used inside app extensions, otherwise the application will be rejected from publication to the AppStore (leaving aside the obvious runtime error caused by using it).

The runtime needs to be split into at least 2 frameworks suitable for linking with app and app extension targets respectively.