When I use TFL‘s online services to check when my bus will arrive, or if the Jubilee line is still suspended, I personally rely on the official mobile web site. Not on any of the hundreds of Android apps that offer the same services, using the TFL API’s and live feeds. That is mostly because I believe in and prefer web versus native apps, but also because I feel that it is much faster and convenient in this particular case. Recently, while using the TFL mobile site I thought “Would basing a business on a mobile web main app plus an API be a good idea?”. Not really sure it would, although some aspects tend to prove it is possible to satisfyingly embrace this approach…
The mobile web + API approach is basically the fact for a business to focus on a cross platform mobile web app while providing an API (or live data) for third party developers to extend the reach of the core service. The idea behind this approach is to leave the app development to third parties, in order to have a native presence on platforms where users are numerous.
Cost reduction and users’ choice
Developing a mobile web app, which requires a relatively limited amount of tweaks to be accessed by the vast majority of mobile users makes sense, however some users may prefer the native experience. Some companies may do more profit within a native environment. Fair enough. By providing power users and third parties with an API and documentation, businesses can extend their reach while limiting their costs.
When a service is really popular – but is not available as a native app – a public API is logical since the probability of having power users within the user base is high (it would actually be an interesting thing to estimate). Services like Twitter are a good example of this effect. The company released its API in 2006 and their first native app for iOS in 2010. The API allowed millions of applications (all platforms together) to be created, resulting in the fact that Twitter didn’t really create their native app, they allowed its existence. After “natural selection” aka users’ choice, they bought the most promising, saving time and dollars in developing, advertising, workforce, support, etc. I am not really sure that was a planned strategy, but it is not irrelevant to consider such an approach for a similar service. Instead of developing native apps internally, why not offer third parties some incentives to do it instead? It could be under the form of a direct incentive (affiliation model) or less direct, which is basically the model on which the current mobile OSes are based (i.e. come and make money within our ecosystem). Lastly, private companies offering API access are, with this move, also offering third parties an untold but critical incentive; the buyout.
Too good to be true
The problem in the above examples sits in the difficulty to grow a big enough user base, or attractive enough product to have all the advantages of a developer community.The apparent lack of real planning behind these examples is not there to help either. If Twitter released their API, it was not really because they wanted to avoid developing costs, it was just because they saw power users having fun with their product.
“Some smart folks out there on the that series of tubes we call the Internet have been putting together interesting projects like this map and this page without any help from us so we thought it was high time to release an API.” blog.twitter.com
It is hard to imagine an unknown company offering an API from the beginning of its existence, in the hope that some developers will do all the work for them. This doesn’t really make sense indeed. Not to mention that offering an API, maintaining it alongside with a documentation as well as dealing with community management are not minor duties. It is also very unlikely for some verticals to adopt such a strategy due to the nature of their product (banking, betting, eCommerce) or if their main product needs to be a native app (gaming, media editing, etc).
It is more true everyday: mobile web has a lot of advantages over native apps, especially for content consumption. Facebook native apps demonstrate this situation, since they are so painful to use, according to a majority of their users and testers. Some of the former will rely on mobile web or native clients such as Friendcaster to have a better and faster Facebook experience. It wouldn’t be too surprising if Facebook were to acquire a successful third party client, whether for Zuck to use its popularity to enhance the social network native offering, or for Facebook to fully control their mobile presence with the objective to monetize it more efficiently – or at least start doing so.
Facebook, Twitter. Using these two as an example to validate the mobile web + API approach is certainly not perfect, and even if I’m still trying to find more examples, I believe the TFL one is a decent proof of concept. Because public transport are by definition mainstream, the popularity of the TFL data is not shocking, and London is surely not the only area in the world offering access to its transit data feeds. It proves that mobile web is definitely the quickest way for a service to push a minimum viable product to market, as long as the product in question doesn’t need deep integration with mobile OSes.
Using a mobile web + API strategy has probably been a great way for some to extend their native presence, but the lack of positive examples I could find is not really confirming the viability of this approach. The good news is : I haven’t looked properly.