Tech

Explaining iOS 8’s extensions: Opening the platform while keeping it secure

Comparisons to Android’s Intents only tell part of the story.

Andrew Cunningham – Jun 8, 2014 8:00 pm | 301

Apple's Craig Federighi introduces extensions at Apple's WWDC keynote. Credit: Apple

Of all the new features introduced in iOS 8 last week, app extensions are the ones that will have the biggest, most visible impact on the new operating system. The feature is most commonly described as a way for third-party applications to talk to each other, though that’s an oversimplification—that’s not the only thing app extensions can do, and technically third-party apps in iOS still can’t talk directly to one another.

We’ve read the developer documentation and watched the WWDC sessions. Now it’s time to break down how these features work, what they do, and how Apple is continuing to balance third-party access to the operating system with security.

What do app extensions do?

Choosing the type of extension you’d like to make in Xcode. Credit: Apple

Allowing third-party apps to communicate with other apps is just one of the problems extensions are meant to solve—third-party keyboards, connecting apps to cloud services other than iCloud, and the new Notification Center widgets are all their own kind of extensions.

Not all parts of iOS can be changed (or “extended”) by third parties. If you wanted to replace one of the default apps with your own or add some kind of toggle to the Control Center, you can’t do that. Apple defines a handful of pre-set “extension points” to show developers where they can add stuff. The iOS 8 extension points are as follows:

Today extensions, also called widgets, are used to deliver glanceable information in the Today view in the Notification Center. Think of them as an answer to Windows Phone’s Live Tiles or Android’s home screen widgets.
Share extensions allow for the posting of photos, links, or other files from one app to an online service. This will enable things like posting pictures to Pinterest or uploading files from an app into Dropbox or OneDrive. Older versions of iOS support posting to Facebook and Twitter, and Share extensions open up the doors to others.
Action extensions “manipulate or view content within the context of another app.” In English, that means editing a photo embedded in a text document or, as Apple showed onstage in the WWDC keynote, using something like Bing Translate to translate the text in a Safari window.
Photo Editing extensions can be used to take a picture you’re viewing in Photos and call upon features from another app to edit it (Apple showed off a VSCO Cam extension in the keynote). Photos keeps both the edited image and the unedited original, though this isn’t true for video files.
Storage Provider extensions will let productivity apps open documents from a variety of cloud services. One could, for example, use Dropbox to store documents that you can then open and edit in Office for iPad or Pages.
Custom keyboard extensions replace the default Apple software keyboard with a new third-party one.

We’ll focus primarily on iOS extensions today, but many of these (including Notification Center widgets and Share extensions, among others) work in OS X Yosemite just as they do in iOS. For apps in the Mac App Store tied to Apple’s sandboxing restrictions they’ll be useful, though of course many Mac apps continue to bypass the App Store and Apple’s restrictions altogether.

This pre-set list of extension points differs from Android’s Intents system. Android apps use “Intent Filters” to tell the operating system the kinds of things the apps can handle. The Twitter or Facebook apps can tell Android that they’re capable of posting photos or links; Google Drive and Dropbox can be used to upload most kinds of files; Chrome and Firefox can open Web pages; new launchers can completely change the way your Home screen looks and works. Third-parties can even specify their own custom Intent Filters to the operating system. By contrast, iOS is still more limited (though not without reason, as we’ll discuss later).

Keep this in mind, because it’s going to come up a bunch: Extensions greatly increase the list of things third-parties can do, and for many common use cases they’ll be functionally indistinguishable from Intents. The changes stop far short of Android’s “anything goes” mentality, though, largely in the name of preserving iOS’ security model.

How do you get extensions, and how do they work?

Extensions are delivered as binaries that live within a “containing app.” Credit: Apple

Like all third-party apps on a non-jailbroken iPhone, all iOS extensions are downloaded from the App Store. The biggest limitation here is that Apple won’t allow developers to offer apps that are just extensions. Each extension has to live within a “containing app,” and Apple mandates that the containing app must offer some functionality to the user. Unlike in Android, developers cannot offer apps that are just widgets or just keyboards (this applies only to iOS; OS X developers can offer apps that are simply wrappers for extensions).

This restriction sounds more onerous than it actually is. Look at Fleksy, a third-party keyboard app already offered through the App Store. Its containing app is little more than a keyboard tutorial, a field of text to practice in, and a settings panel. A basic Share button lets you send the text you type as an e-mail or Tweet. This app doesn’t do a whole lot, but it’s about as complicated as a containing app for a keyboard or widget would have to be.

Containing apps don’t necessarily have to be complicated, but they do have to do something. The Fleksy keyboard’s containing app is an extremely basic note-taking app primarily used for practicing. Credit: Andrew Cunningham

Other things are recommended by Apple but not mandated. The company suggests that extensions be designed to complement Apple’s built-in software. Third-party widgets should look and act like Apple’s own widgets. Photo editing extensions that work with the Photos app shouldn’t look radically different from that Photos app. There will definitely be developers who won’t follow these guidelines, but most iOS app developers are already practiced at making apps that meld with Apple’s UI.

While these guidelines are more restrictive than what Android developers will be used to, Apple imposes no limitations on the number or types of extensions your containing app offers. You can add an extension to your app by adding a new “target” to it in Xcode, and Apple provides default templates for all the different kinds of extensions.

Each type of extension is activated in different ways. Widgets are enabled and disabled from the Notification Center, and keyboards are changed in the Keyboards section of the Settings (where you’d go to select a different language or enable the emoji keyboard in iOS 7). Photo Editing and Storage Provider extensions only come up in specific situations—when using the Photos app and using any app that has a document picker, respectively. Share and Action extensions can be invoked from within any app, but developers should add Activation Rules to the extension to specify what kind of data it will work with. If your extension is only meant to share photos, Activation Rules can be configured to make sure that extension doesn’t appear when the user is trying to share a URL or a document.

Activation rules tell the OS what kind of files your extensions can work with. You won’t want to be offered a photo editing extension if you want to upload a document. Credit: Apple

While they all need to be packaged up inside containing apps, extensions are generally run separately from the containing app itself. Each extension is its own little binary with an .appex file extension that can open, do its job, and close without ever running the containing app. For extensions that need to be able to perform some of the same tasks as their containing app—an Instagram extension that adds a filter to an image, for example—developers are encouraged to use an “embedded framework” to share the code responsible for those tasks. Create the framework, drop the code into it, and then embed that framework into both the containing app and the extension. The only caveat is that apps set up this way will require iOS 8.0 or later, and they won’t run on earlier versions of the operating system.

One reason why extensions are launched separately from their containing apps is because of strict Apple-imposed memory limitations. Widgets are especially constrained, since the user can have many of them running at the same time. We’ll have to see how a Notification Center packed with widgets will perform on a memory-constrained device like the iPhone 4S or the iPad 2.

Apple has designed extensions to have a “short lifecycle.” They open, they do their job, and they close. Credit: Apple

Also, in part because of memory limitations, extensions don’t run for very long and are aggressively cleared out of memory by the system. Extensions are designed to do their task and then get out of the way. For extensions that perform lengthy background tasks like uploading, Apple recommends that extensions pass that upload task to the system and then close down.

This covers the basics of how extensions are packaged, how they’re accessed, and how they’ll behave while they’re running. Even with their restrictions, they stand to add a lot to the operating system—they’re probably the biggest functional change we’ve gotten since iOS 4 or iOS 5. What’s more impressive is the way these extensions work without sacrificing Apple’s sandboxing model, which should help keep you and your data about as safe and as private as it can be these days.

Preserving security and privacy, and how iOS differs from Android

In a sentence, the difference between Android’s approach to security and privacy and iOS’ approach to it is that Android will give users and developers enough rope to hang themselves.

Leave the default settings enabled and read the extensive list of things that applications can ask to do every time you install something, and Android users are in little danger of contracting malware or giving their personal data to someone without realizing it. But those app permissions can be confusing. Some people want to sideload applications from places other than Google Play, and others want to unlock their bootloaders and gain root access to their phones and install alternate Android distributions. Android lets people do these things. It’s a feature that draws some people to the platform, but you do all of it at your own peril.

By contrast, even with extensions, iOS still puts up barriers between applications, their extensions, and applications’ data in an effort to protect users (and their information) from themselves. For starters, applications still don’t really talk to one another directly—as we mentioned before, extensions are small binaries that are usually launched independently of their containing app. The app that called for the extension (which Apple calls the “host app”) talks with the extension directly once it has been launched, but the host app never communicates directly with the containing app. Even when a host app wants to use an extension, it sends a request via Apple’s system frameworks, which then launch the extension—apps don’t launch extensions directly.

Extensions and “host apps” that launch extensions can communicate, but the extension doesn’t directly communicate or share data with its containing app. Credit: Apple

Eduardo Fonseca, an iOS developer at FortyTwo Inc., helped explain how iOS keeps applications and extensions shielded from one another.

“Every extension is a separate bundle inside the main app bundle, containing a separate executable inside,” Fonseca told Ars. “The funny thing is that an extension is not an app. It gets called via Apple’s System Frameworks, using a well defined interface that spawns a process and executes the extension—all the code is executed in a separate execution context, meaning nothing gets executed inside the third-party ‘App Space.’ So no risk for any apps that will support extensions (such as Safari), nor any problems about running your Extension inside other Apps. They are like oil and water—they don’t mix.”

Even if the extension needs to communicate with its containing app, it must do so indirectly through system APIs. By default, containing apps and their extensions can’t even access each other’s data.

When extensions and their containing apps communicate, they must do so indirectly through APIs and special shared data containers. Credit: Apple

To share data between a containing app and its extensions, you need to make both the containing app and its extensions part of an App Group, which allows some data to be shared between the two of them in a third container outside of both sandboxes. If you’ve ever wondered why signing into Chrome on iOS can also sign you into Maps or Google Drive, it’s because they’re all members of Google’s App Group. Even App Groups are limited to sharing certain types of data that is “not user-facing.” They can share databases, caches, and login information, for example, but not locally stored media or documents.

Placing a containing app and an extension into the same app group allows them to share some kinds of data in a shared location. Otherwise, apps and extensions keep data in separate containers. Credit: Apple

A simple way to summarize all of this: Apple doesn’t want one app to be able to get into another app’s sandbox. Extensions are like little sandboxes-within-sandboxes that facilitate communication between different apps while never sharing all of their containing app’s data directly with the host app.

The way extensions are executed also differs from the way apps are executed. If you begin to use the same extension in two or more host apps at the same time—if you fire up an extension in Safari and then hop over and start the same extension in Mail, for example—the system actually launches two separate copies of that extension and runs them as separate processes. They don’t share the same memory addressing space. This keeps the two host apps from having their data in the extension’s sandbox at the same time, and it will keep all instances of the extension from going down if one crashes. Browsers like Chrome and Safari run all individual tabs as separate processes for the same reasons.

Android provides its own application sandboxing model that aims to protect data stored in one app from being accessed by an app that doesn’t have permission to access it, though this can be bypassed by developers if they want. Especially dangerous permission settings that would make all of an app’s data readable and writeable by any other apps were deprecated back in Android 4.2, but Content Providers and Resolvers can still work together provide apps with access to data in other apps.

Again, these are mechanisms that will protect your data just fine when used properly, but all an Android user has to do to put this data at risk is grant permission to a malicious application, and people can’t be counted on to read those app permissions dialog boxes carefully every time they install an app. Apple also offers handy lists and toggles for all apps that have requested access to data stored in first-party apps, a feature Google considered for Android 4.4 but removed in the final release. This isn’t directly related to the way extensions work, but it’s an example of how iOS 8 will continue to sacrifice flexibility in the name of security and privacy.

Apple has placed other limits on extensions—they can’t use all the APIs applications can, and custom keyboards in particular are restricted by many different mandatory and suggested rules—but this should cover the basics if you were wondering how Apple’s extension model differs from Google’s various inter-app communication mechanisms. At its heart, iOS 8 is still a locked-down operating system compared to Android. Third-party apps still can’t directly share all of their data with one another. Certain elements of the iOS experience, including the home screen and the default applications, remain uniform on every single iPhone and iPad that exists.

Still, it looks like Apple has addressed one of the biggest complaints about the platform in a way that doesn’t drastically increase the operating system’s memory requirements or compromise its security model. We might not see all the weaknesses of Apple’s implementation until we’re using iOS 8 devices with tons of extensions installed, but on paper it looks promising. We’ll have a chance to take a better look at extensions in practice in our full iOS 8 review this fall, and in the meantime Apple’s publicly available documentation and WWDC presentations on extensions are useful resources if you’d like to learn more. Federico Viticci of Macstories has also written this excellent overview that talks more about what specific extensions can and can’t do, and how developers are reacting to the feature.

Listing image: Apple

Andrew Cunningham Senior Technology Reporter

Andrew is a Senior Technology Reporter at Ars Technica, with a focus on consumer tech including computer hardware and in-depth reviews of operating systems like Windows and macOS. Andrew lives in Philadelphia and co-hosts a weekly book podcast called Overdue.

301 Comments