On app discovery

Inter-app communication is still in its infancy. Indeed, as powerful software publishers would have it, each app or each suite of apps would attempt to lock users into a unique file format to achieve a sort of monopole. This is clearly what Microsoft was doing in the 90s with MS Office. Since then, the strong competitive and market forces got the best of the crypted files – Microsoft eventually gave way and started allowing a “clear” version of their files (.docx, .xlsx, .pptx), and even published the specifications of their native files (see the Microsoft Open Specification Promise).

Opening up the file format helped other vendors create alternative office suites, perhaps with competing formats, but almost always with a way to interchange files via an export menu option (Apple’s Keynote and Google Docs import and export to Powerpoint, to PDF, etc.). When that happens, the now competing vendors then focus on innovation inside, end users are no longer taken hostage, can focus on getting work done, and manage to share the end-result seamlessly with friends and colleagues. The OS knows what application can open what file given its “extension” (.doc, .pdf, .zip, .txt). Sadly, this is pretty much how inter-app communication works on the Desktop.

On the web, documents are typically represented by URLs. Unfortunately, the sharing tends to follow the exact pattern of the above mentioned “defensive” mechanism: the SaaS vendor will let you share to an email, which then loops back to the same proprietary platform, with its own user base, with a dedicated user/password platform (or if you’re lucky, a single sign-on from Google, FB or Twitter). But still, you’re back to being “locked-in”. Sure, you may export to a static file, but that sort of defeats the purpose of working online.

Luckily, this Chinese Walls model is changing as many open-up their SaaS platform via an API. This is especially true of CRM platforms and other enterprise grade services that initially rely on importing data from legacy systems or connect to complementary databases (HR, Customer Databases, etc.). In the non-enterprise field, it is much less the case – and Google Apps “plugins” are no better; they tend to only work within Google Apps and Google Mail… Semantic Web or Web Intents to the rescue – but we’re still far off.

On smartphones, the story is a little different. Each app typically represents one function, one feature, one task, symbolized by one icon. By default or by design, publishers come to realize that their app better excels at one thing and one thing only. The more focused it is, the better: clear winners of this paradigm include Instagram/Path, Evernote, Dropbox, Twitter, etc. This generally prevents feature overload and tends to polarize the publishers between the top-of-mindshare leaders and the rest of the pack (the long tail).

Yet, contrary to the afore-mentioned model, those leaders rarely attempt to lock their users in for any action that sits outside of their core focus. Many “document” oriented apps have a single “save to Evernote or ReadItLater”; messaging apps have a single “Tweet this via Twittie/Twitter, TweetBot, Seesmic”; apps that recognize a phone number have a “Call via Phone, Skype, Viber”, etc… Inter-app communication has never been more prevalent on smartphones than any other previous computing eco-system.

How is this possible?

Actually, you all know how this works without necessarily knowing it; the mechanism is pretty universal and widely relied upon by all OSes, mobile or not. Except that the examples hereafter are the byproducts of 20+ years of internet protocols and  hyperlinking. When an app attempts to open something that starts with “mailto:john@doe.com” then the OS will open the default Email client, and prepare an email for John Doe. Similarly, when an app attempts to open something that starts with “http://” then typically the default browser opens (same goes with ftp:// and a couple more obscure protocols). Archaic and limited.

Not so archaic on smartphone OSes

While iOS may have had URLHandlers management since the first release of their SDK, Android is ahead on this one. Android has the notion of “intent”; a few, but it’s a good start. For instance, an app may say “share this message with a messaging app” – the Android OS will then pull a list of apps that are registered to handle messaging, and the user will (re)discover all her apps that can do the job, and link straight to it with the payload (it also helps that on Android, launching a separate app feels part of the same left-to-right screen navigation, and back). On iOS, it’s a little trickier since there is no single registry nor any official nomenclature for handling intents. That being said, the Twitter – Facebook – DropBox clients all have been quick to publish an API that helps other developers bind to their apps. And so, on iOS, inter-app communication works and works pretty well in fact. We all use it all the time. It is seamless, self-less, and brings tons of value to end users.

Some developers have started creating repositories of such URLHandlers; but it’s a manually painful and poorly nomenclatured process, even if crowd-sourced. A number of pundits are envisioning or rumoring ways this could play out, and this extends to app discovery and search. Appsfire certainly has reconstructed one of the most extensive private URLHandlers database in the World (after Apple of course). This has helped us achieve a fairly robust in-app detection of “my apps”, allowing our users to share apps that they own. But still, further development is needed at the core SDK level, especially on intents and corresponding nomenclatures, allowing developers to tap into this wealth of complementary features and functions, and ultimately, allowing end users to discover apps that can help them achieve better sharing, better productivity, better flow, better choice. Taken to higher level, this may even help re-discover apps that they own, or discover apps that they didn’t know existed. And of course, we at Appsfire are working on that.

Implementing intents and helping the discovery process at the same time

Smartphone OS vendors can certainly build upon the foundation by creating a large and documented repository of intents, all following a strict nomenclature, and let developers tap into it. A central registry, tied to the OS, with a validation process, and yes, a dreadful accept/reject procedure. This sort of process is required for QoS, avoid foul play, make sure there is no collision in the naming nomenclature, and ultimately help maximize the utility of such a system. Once in place, the system will dynamically know what to do with specific type of content, be it text-based/clipboard or file based, and then which intents make sense for it. The diagram above illustrates how this might play out on iOS for example, with iCloud having an asynchronous role in identifying apps that are already purchased but that are no longer or not yet installed, and then suggesting apps worth acquiring to deal with the task at hand.

This concept would enable a whole new level of app (re)discovery in a very meaningful way.