Using URLs to bring users into our app, and even to a specific feature, is a very handy feature. But it does mean leaving the app the user was in and coming over to ours. Throughout the history of iOS, each app has lived in its own sandbox, prohibited from directly interacting with other apps. Each app has its own section of the filesystem and can’t see anything outside its folders. Each app runs in its own process and cannot share resources like frameworks or dynamic libraries. This can lead to a lot of duplication of effort across apps.
Recent versions of iOS have poked some holes in the walls between applications by allowing apps to create app extensions. From the user’s point of view, extensions are packaged with an app and allow it to extend some of its functionality into other apps. From the developer’s point of view, the extension is another target in the Xcode project, one that can share code and certain runtime resources.
iOS defines several extension points, which are different kinds of functionality that an app extension can provide, and a hook into that functionality via an API or some aspect of the user interface. In iOS 9, the following extension points are provided:
Extension Point | Description |
---|---|
Action | Manipulate content from the host app, such as translating text or grabbing contents from a web page |
Audio Unit | Process audio in real time |
Content Blocker | Block web content (such as ads) from being viewed in Safari |
Custom Keyboard | Provide text input with custom keyboard input method |
Document Provider | Access and manage a shared filesystem |
Photo Editing | Edit a photo or video within the Photos app |
Share | Share text, photos, or other content with others, like via a social network |
Shared Links | Expose app content in Safari’s “shared links” list |
Spotlight Index | Expose app content to Spotlight, the system-wide search tool |
Today | Provide “glanceable” content in Notification Center |
In addition, Apple Watch apps use app extensions: a watchOS app target is just a storyboard for the user interface, and all the work of populating the UI (including “glances” and “complications”) and communication back to the host iPhone app is done with extensions. To learn more about developing for Apple Watch, check out Developing for Apple Watch, Second Edition.[3]
In most cases, we develop an app extension as a view controller, which allows us to customize the view for our extension as well as put the control logic behind it. Extensions have a shorter life cycle than full apps; they’re expected to be small and short-lived, since they come up only briefly in order to provide services to another app that’s already running. They’re also more limited in what they can do; extensions can’t access the camera or microphone, and some have to ask permission to do things like access the network.
The idea of an extension is to offer something that our app can do, that would be useful to other applications. Our app knows a lot about getting data from Twitter, so maybe there’s something we can do related to that.
13.58.182.29