There is much debate in the tech industry about Apps on mobile and whether they are simply a trend which will pass, and whether eventually all apps will be web apps. I don't want to get into this argument today. But regardless of what side of the fence you sit, it is undeniable that in modern smartphones, people are using apps - and lots of them. The average iPhone user has 40 apps installed on their device. I personally use about 12 apps at least once a week, but many of them every day.

There are many different types of apps available on smartphones today, including games, utilities, converters, remote access tool etc, but for the purpose of this post I'd like to specifically consider web connected apps - i.e. apps which often replace a desktop optimised website with a more mobile friendly app that connects to the web through an an API to get data. Examples include the Engadget app, Propertynews, Twitter Clients, Dropbox, iPlayer and many, many more. Often these apps are fantastic, and offer a slick mobile optimised experience to the user which can make full use of the hardware capabilities of the device. My biggest frustration with these types of app is the disconnect between these apps and the website for actions initiated from outside the app. For example, when you get an email from Twitter telling you that you have a new follower or a mention. Clicking any of the links within the email will load the Twitter mobile website, which provides a less slick and friendly experience than the native Twitter app.

Apple do provide solution... sort of...

Apple provide a feature to developers called URL schemes, where a developer can register as part of their app that it supports a particular URL scheme. In this situation the URL scheme is the "http" bit in the link http://www.gcdtech.com, and for instance the Propertynews app could be setup to handle links like pnew://www.propertynews.com/brochure.php. The issue is that there is no way in an email or on a webpage to detect if a particular app is installed on a particular device, and out put the appropriate link, and if the app is not installed the links will simply not work at all. Also due to a lack of names spacing in URL schemes, if two apps try to retiree the same scheme the last app wins. Furthermore it is not possible to override Apple declared schemes including http, FTP and itms etc.

A better way

My proposed solution to this issue is to allow apps at point of install to register that they handle requests for a particular fully qualified domain name (FQDN). In order to prevent abusive apps requesting to handle domains which they are not associated with, a dns lookup could be made to a specific txt record on the domain which could contain a list of app bundle identifiers which were allowed to register interest in a FQDN. The user could also be prompted to accept or decline the request.

With a system such as this in place, any link to a registered domain from any external source could be passed to the associated app, which would then either choose to handle the request or if it can't, pass it back to the browser.

This would give a much more seamless experience. With the Twitter app for instance, all links from email or around the web would open in the Twitter client automatically, providing a much slicker and familiar interface. This same protocol could obviously extend across all mobile platforms and in fact could also extend to the desktop. Taking the Twitter example, I use to mac Twitter Client and when I click follow, or profile links within emails it would be preferable to stay within that familiar app environment.

This approach is very similar to mailto: links which we are all familiar with and how they open our default mail client. The idea is to bring apps and the web closer together, giving people the choice of which way they wish to consume content.

by Andrew Gough