Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support for iOS app extensions #3965

Closed
mbektchiev opened this issue Oct 2, 2018 · 7 comments
Closed

Feature Request: Support for iOS app extensions #3965

mbektchiev opened this issue Oct 2, 2018 · 7 comments

Comments

@mbektchiev
Copy link
Contributor

mbektchiev commented Oct 2, 2018

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
Copy link
Contributor

+1 from 1357156

@NickIliev
Copy link
Contributor

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

@adrian-niculescu
Copy link

adrian-niculescu commented Jan 16, 2019

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:
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.

@erkanarslan
Copy link

Thank you for adding this feature to new release. However I couldn’t find a documentation for that. Is this available right now or do we need to wait for a few more releases?

@NickIliev
Copy link
Contributor

NickIliev commented Mar 29, 2019

@erkanarslan I am currently working on the related documentation section - the working branch can be found here

@fpaaske
Copy link

fpaaske commented Aug 14, 2019

@NickIliev This is a really nice addition to {N}! Will this work with any kind of extension? For example CallKit?

@jessorlisa
Copy link

Has anybody ever been able to successfully build a release build containing a share extension while utilizing the nativescript cli build process (ns build ios --for-device --release ...)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants