Even though Android, and even jailbroken iOS devices, have been able to have apps interact with each other and the OS itself quite some time, Apple’s announcement of extensions is nothing to “Simpsons did it” about. Well, maybe the custom keyboard extension, but they’re all still pretty cool.

What’s interesting about this planned extensibility is how Apple managed to keep their sandboxed security system, but produced a method for apps to still interact with each other. Basically, your apps still live in their own bubble, but use iOS’ security mechanisms to reach out to one another. This can allow apps to do things like use another app to post something to the web, or even project UI to define how content is seen, shared, and generally used by other apps.

Apple pushed these new capabilities heavily as benefits for the developer, but they also benefit designers: we get to play with and figure out new and exciting UI that can help users interact with these new functions. A fair amount of examples were displayed during the keynote, as well as within Apple’s documentation. But really, this is just the tip of the iceberg. Developers and designers should start thinking about the possibilities of how extensions can benefit and enhance their app’s flow and the user’s experience.

To recap what was displayed during the keynote, here are the different extension types developers will be able to implement into their apps and how users can benefit.

Today (iOS and OS X)
These are extensions, referred to as widgets, that are displayed on the Today view of the Notification Center. Their goal is to give a user quick updates about something, or perform a quick task. One example Federighi showed was the eBay extension, which allowed users to keep track of their bids and watch list, see if they’ve been outbid on an item, and place a new bid.

You can pretty much bet that this means the return of posting to Twitter or Facebook (and now even more Social Media venues) directly in the Notification Center, which was lost in the transition between iOS6 and iOS7.

Share (iOS and OS X)
Share extensions are pretty straight forward: Share some content that the user is viewing / interacting with to another platform. The example shown during the keynote was sharing an image from a webpage to a user’s Pinterest board.

These extensions will customize a user’s share / action sheet, giving more options than the default sheet used currently. Developers can define their own UI for a share extension, and it keeps a user in the app they’re currently using. This is pretty familiar to Android users, who can see their share options expand with every new app they download.

Actions (iOS and OS X)
Actions allow users to view or manipulate content within another app, such as translating content into another language through Bing (as Apple will keep promoting Bing over Google because reasons), or editing an image within a document. They too will customize a user’s share / action sheet depending on what apps they install.

What will be nice with these extensions, as well as Share extensions, is reducing the back-and-forth nature we currently see with app “interactions”. Users can complete a wider range of tasks while staying in the app they’re currently using. This goes beyond deep linking and make iOS8 a lot more interactive than previous versions.

Photo Editing (iOS)
These are extensions that can add features into a user’s Photos app, such as filters. Share and Action extensions will work well in combination with Photo Editing extensions, in the sense that if the User wants to edit an image, such as to pretty it up to share out or edit within a document, they’ll bring the image into the Photos app and allow the user to apply the customized filters and effects. Apple suggests that if you develop one of these extensions, they shouldn’t require any prolonged interaction – let the user get in, fancy the image up, and get out.

And good news for users: edits will be non-destructive, meaning you’ll always be able to revert back to the original version of the photo, even after you’ve used an extension on it!

Finder Sync (OS X)
Specific to Yosemite, and a unique extension in general, this extension doesn’t provide features that can be used in other applications. They only modify the behavior of the Finder itself. They can therefore be used to do things like setting badge icons on items / directories, creating custom shortcut menus, and monitor content.

One use case given in the iOS Developer Library is that they can send a notification to a user or another platform when a user starts or stop browsing in a monitored directory. For example, the extension can receive a notification when the user opens the directory in the Finder or in an Open or Save dialog.

Storage Provider (iOS)
This one I’m really excited about. This will kill a lot of annoyances in terms of getting documents from one app and opening it in another. Referred to as storage providers, they act as the interface between files an app manages and the other apps that want to use them, allowing them to import or open files. They can also export or move their own documents in the extension’s container.

They consists of two parts: the Document Picker View Controller, which provides the storage provider’s UI, and the File Provider, which provides access to files outside the host app’s sandbox. It also creates placeholders for remote files, downloads local copies when needed, and uploads any changes made by the host app.

This is another one that will help reduce the current method of back-and-forth interaction; a user can call up this extension in one app and browse through the files of another app, which can then be opened and used within the original app.

Custom Keyboard
Like I mentioned in the beginning: Simpsons did it. But this doesn’t mean it’s not a big deal for iOS users. Even with how other extensions will customized UI elements of iOS8, keyboard extensions are closest users can get to truly customizing their device for their needs. But within limits, of course. Apple took a lot of precautions to allow this functionality, such as not allowing a custom keyboard to be used when a user is typing into a secure text field (passwords).