https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html#//apple_ref/doc/uid/TP40014214-CH21-SW1
host app app extension
a separate binary that runs independent of the app used to deliver it.
target
distribute
communicates
a running extension, the host app that launched it, and the containing app
A Today widget (and no other app extension type) can ask the system to open its containing app by calling the openURL:completionHandler: method of the NSExtensionContext class.
access shared data in a privately defined shared container
the system uses interprocess communication to ensure that the host app and an app extension can work together to enable a cohesive experience. In your code, you never have to think about this underlying communication mechanism, because you use the higher-level APIs provided by the extension point and the system.
An extension that launches too slowly is terminated by the system
Memory limits for running app extensions
In your extension scheme’s Run phase, you specify a host app as the executable. Upon accessing the extension through that specified host’s UI
App Extensions
An app extension is different from an app. Although you must use an app to contain and deliver your extensions, each extension is a separate binary that runs independent of the app used to deliver it.
You create an app extension by adding a new target to an app. As with any target, an extension target specifies settings and files that combine to build a product within your app project. You can add multiple extension targets to a single app (an app that contains one or more extensions is called a containing app).
The best way to start developing an app extension is to use one of the templates that Xcode provides for each extension point on both platforms. Each template includes extension point–specific implementation files and settings, and produces a separate binary that gets added to your containing app’s bundle.
To distribute app extensions to users, you submit a containing app to the App Store. When a user installs your containing app, the extensions it contains are also installed.
After installing an app extension, a user must take action to enable it. Often, users can enable an extension within the context of their current task. If your extension is a Today widget, for example, users can edit the Today view in Notification Center to enable your extension. In other cases, users can use Settings (in iOS) or System Preferences (in macOS) to enable and manage the extensions they install.
An app extension lets you extend custom functionality and content beyond your app and make it available to users while they’re interacting with other apps or the system.
Understand How an App Extension Works
An app extension is not an app. It implements a specific, well scoped task that adheres to the policies defined by a particular extension point.
An App Extension’s Life Cycle
A host app defines the context provided to the extension and kicks off the extension life cycle when it sends a request in response to a user action.
Because an app extension is not an app, its life cycle and environment are different. In most cases, an extension launches when a user chooses it from an app’s UI or from a presented activity view controller. An app that a user employs to choose an app extension is called a host app. A host app defines the context provided to the extension and kicks off the extension life cycle when it sends a request in response to a user action. An extension typically terminates soon after it completes the request it received from the host app.
For example, imagine that a user selects some text in an OS X host app, activates the Share button, and chooses an app extension from the sharing list to help them post the text to a social sharing website. The host app responds to the user’s choice by issuing to the extension a request that contains the selected text. A generalized version of this situation is pictured in step 1 of Figure 2-1.
How an App Extension Communicates
Behind the scenes, the system uses interprocess communication to ensure that the host app and an app extension can work together to enable a cohesive experience. In your code, you never have to think about this underlying communication mechanism, because you use the higher-level APIs provided by the extension point and the system.
When a host app sends a request to an app extension, it specifies an extension context. For many extensions, the most important part of the context is the set of items a user wants to work with while they’re in the extension. For example, the context for an OS X Share extension might include a selection of text that a user wants to post.
As soon as a host app issues its request (typically, by calling the beginRequestWithExtensionContext: method), your app extension can use the extensionContext property on its principal view controller to get the context. Child view controllers also have access to this property through chaining.
Next, you use the NSExtensionContext class to examine the context and get the items within it. Often, it works well to get the context and items in your view controller’s loadView method so that you can display the information in your view. To get your extension’s context you can use code like the following:
- NSExtensionContext *myExtensionContext = self.extensionContext;
Of particular interest is the context object’s inputItems property, which can contain the items your app extension needs to use. The inputItems property contains an array of NSExtensionItem objects, each of which contains an item the extension can work on. To get the items from the context object, you might use code like this:
- NSArray *inputItems = myExtensionContext.inputItems;
Each NSExtensionItem object contains a number of properties that describe aspects of the item, such as its title, content text, attachments, and user info.
To enable data sharing, use Xcode or the Developer portal to enable app groups for the containing app and its contained app extensions. Next, register the app group in the portal and specify the app group to use in the containing app. To learn about working with app groups, see Adding an App to an App Group.
After you enable app groups, an app extension and its containing app can both use the NSUserDefaults API to share access to user preferences. To enable this sharing, use the initWithSuiteName: method to instantiate a new NSUserDefaults object, passing in the identifier of the shared group. For example, a Share extension might update the user’s most recently used sharing account, using code like this:
- // Create and share access to an NSUserDefaults object
- NSUserDefaults *mySharedDefaults = [[NSUserDefaults alloc] initWithSuiteName: @"com.example.domain.MyShareExtension"];
- // Use the shared user defaults object to update the user's account
- [mySharedDefaults setObject:theAccountName forKey:@"lastAccountName"];
Figure 4-1shows how an extension and its containing app can use a shared container to share data.
Figure 4-1An app extension’s container is distinct from its containing app’s container
