Where's the inter-app-erability?
· 4 minute read
Having now existed for over four years, the App Store impresses not only with revenue numbers and download statistics but by having turned the act of installing software into something fun and easy, that even the most casual smartphone and tablet users feel comfortable doing. As the number of apps and services that an iOS user engages with increases, it’s only natural for developers and users alike to seek integration across these various services. While many apps already integrate nicely with one another, let’s discuss the shortcomings that exist today and how app interoperability could potentially be improved going forward.
Most of the best iOS applications are not completely standalone, but rather pull data in from external sources or provide the option to share outwards. Timehop is a great example of the former. A charming application that helps you reminisce about experiences you may have forgotten, Timehop resurfaces photos, tweets, Foursquare checkins, and other types of data from years past. The value that Timehop delivers correlates directly to the quality and quantity of data that the user provides it with. In terms of sharing outwards, a photo editing application will generally be more appealing to users if it offers an easy way to post to their photo sharing services of choice.
Sadly, the ease with which you can allow one application to integrate with another on your behalf can vary dramatically. Granting access to your Facebook or Twitter data is trivial, as Apple has selectively chosen to deeply incorporate these credentials at the OS level. For other services such as Foursquare or Evernote, this is not the case.
While many of your favorite services likely provide APIs that developers can connect their apps to, there’s a significant time cost in doing so. It’s simply impractical for a developer to manually integrate with the growing number of services that their users may be interested in. Additionally, there are UI considerations when presenting the user with the ability to authenticate with or share to a third-party service. If you were to build a new camera application today, think about how many potential destinations (Flickr, Instagram, etc.) you would have to support. This can result in a large amount of duplicated effort across the developer community.
Services such as Pocket, Facebook, and Dropbox do a great job of mitigating these shortcomings by providing SDKs, bundled code that other developers can drop into their applications in order to easily integrate. Despite this, it’s still unrealistic to expect every app to explicitly define the interactions they have with every other app, many of which may not even exist at the time of development. There should be a better way.
Every iOS application should be able to define types of input and output data. For Tumblr, an input type could be a photo or a video to post, while an output type could be a credential that another application could use to communicate with the Tumblr API. For 1Password, an input could be a URL, and the output a corresponding username and password. Allowing applications to be stitched together dynamically based on the data types that they know how to act upon would allow iOS users to be productive in ways that are not possible today. These are not new ideas.
Thankfully, Apple has been laying the groundwork for some of what has been described above. iOS 6 introduced “activity controllers”, the grids of icons you have likely seen when trying to share from an application such as the default Photos app. While more visually appealing than the text-based sheets that preceded them, developers still need to manually specify the activities that their app can perform. Looking at the way that Apple requires activities to be implemented, however, allows one to envision a scenario in which applications could dynamically display activities defined by other applications, depending on the type of data being processed.
An activity can optionally provide a screen that iOS will present to the user when selected. When the email activity in Photos is chosen, for example, a compose screen is displayed on top of the app. As of iOS 6, this compose screen is actually being pulled in from outside the app it is being displayed in. While this may not be particularly interesting quite yet, it bodes well for a future where apps can include user interfaces provided by other applications, preventing developers from having to build their own login forms and share sheets for each third-party service that they want to integrate.
Like many of iOS’s built-in applications, Safari also displays an activity controller when the user taps the “actions” button in the toolbar. Many iOS apps currently embed their own crude “browsers” in part due to their inability to augment Safari with functionality specific to their application. These in-app web browsers don’t contain access to bookmarks, iCloud tabs, or Smart App Banners, resulting in a hindered experience for the user. If Safari’s activity controller could dynamically include activities such as “Read Later” from Instapaper or “Fill Credentials” from 1Password, developers could potentially stop building their own in-app alternatives and everyone would benefit.
As iOS evolves, it continues to empower developers with new capabilities for enriching the lives of our users on a daily basis. Allowing apps to be smarter about exposing data to and consuming data from other applications would be a natural progression. By providing dynamic inter-app communication, iOS would allow developers to focus on what makes their particular applications great. For users, a seamless integration of services would make our ever-increasing time spent on mobile devices more productive.