Should there be an app for that?

'There is an app for that'. Almost every user who uses a smartphone, especially an iPhone, has heard of this famous catch phrase made famous by Apple in 2009's World Wide Developer Conference. Why was the line so catchy and why did it become so famous? We have to look at phones before iPhone to analyse it.

The situation before the growth of apps

Before iPhone hit mainstream along with its iconic App Store, where one could get hold of apps to practically do anything that could be done on a smartphone, the ecosystem of app development and hosting it on a central repository managed by the phone makers / phone OS makers was very fragmented. Most of the time, the development environment was too complicated, it was very unwieldy to make a custom app and hosting the app for download was mainly the responsibility of the developers themselves and it was upto good SEO for an app to be spotted. Nokia did try to ease matters by introducing the Ovi Store, but anyone developing for Nokia using their Symbian platform and later on J2ME would agree that making an app needed a lot of skill, time and patience. The system was not as easy as iOS and Android are today. Blackberry's platform was slightly better, but their focus on business meant that their apps were centred around business and productivity tools and there was nothing by way of games or apps like Instagram, Whatsapp or any of the Google Apps in the Blackberry World. In summary, user who bought a Nokia or Blackberry were generally content with (or let us say, stuck with) the apps that were pre-installed in the phone during purchase.

With iOS and Android, Apple and Google focused exclusively on building an ecosystem where developers could easily build apps with powerful tools and APIs and upload them to the respective app repositories (App Store and Google Play) in a jiffy.

App explosion

Fast forward to July 2015. According to the numbers in statista.com, Google Play has 1.6 million apps and Apple App Store has 1.5 million apps. Now surely we cannot do a million and a half different things with a smartphone. Chances are that a typical user uses only between 2 to 15 distinct features on his/her smartphone. Typical uses would include Internet access, photography, geolocation, bluetooth connectivity and storage on SD card (a feature not supported by Apple anyway). Even if an app were to use a combination of the mentioned features, the number of combinations will run only into a few hundreds. So, it is clear that hundreds of apps are competing against each other over the same combinations of functionality. E.g. there are hundreds of photo snapping and sharing apps, hundreds of apps that deal with bluetooth sharing, etc.

Full-blooded competition

This means that when a company makes a new app, they may be actually competing with hundreds of apps which are achieving the same thing, although with their own set of conveniences and user experiences which draws a certain set of users to their app. But it does mean that those users will also install competing apps and may or may not stay loyal to any of the apps.

In fact, observations show that apart from the pre-built apps, a typical non-techie smartphone user has only 3 apps actively installed and being used from the app store. More techie users will generally have upto 15-20 apps. But both sets of users generally use only upto 7-8 apps on a regular basis, i.e. at least once a week.

With such user choosiness and such an oversupply of apps, the situation looks just like the scene from Finding Nemo where a flock of seagulls are chasing after a pelican to get their bite of morsel.

Cut-throat competition among apps means that they are constantly stuck in a cycle of having to grab the user's attention using marketing, promos and awareness tactics. When a new user wants to install apps, it looks like the apps are shouting out to the user like the seagulls in Finding Nemo!

Why you should care

The situation paints a grim picture for anyone who wants to roll out his/her own app. Is it really such that after putting in so much time and money on building an app, marketing and acquiring users, we can actually wake up one fine morning to find that users are actually jumping ship to a rival? The hard truth is YES. As long as an app is an also-ran among a pool of rival offerings, there is no guarantee that users will stick to the app unless it has something uniquely valuable to offer. And that value has to be really ground-breaking, disruptive and radical for someone to hang around. Or it must have enough fan-following and generate a humongous amount of content currently not being done so by the rivals.

The moment of truth

Companies and individuals must stop and think why they really need an app to achieve their objective. To put the question more specifically and to make things clearer:

What kind of functionality am I introducing into my product that is making me overlook a mobile enabled website and instead making me invest my time, money and resources into making one app per platform, i.e. Android, iOS and Windows Mobile?

What am I bringing into this product such that the convenience of writing a one-size-fits-all HTML5 has to be intentionally ignored and the hassle of writing 3 seperate codebases is the only option to achieve the means?

If your answer is, "Everyone has an app and I do not want to miss out on the mania" or "If I do not make this app and instead make a mobile website, my customers will think that I am antiquated", then relax. You may think that everyone including your customers and share-holders may care if you have an app or not. In reality, they couldn't care less as long as there is a solution that solves their problem and works 100%. It does not matter if it is an app or a website as long as the user has somewhere to turn to as a solution for his/her problems.

Giving HTML5 and responsive web a chance

Apart from the obvious fact that one codebase and one URL will work on any device, be it iOS, Android, Windows mobile, tablets, desktops, kiosks and a lot of HTML-compliant devices in the future, responsive web is super easy to design and code, needing much fewer lines than native code to achieve most tasks. With a plethora of frameworks now available, such as jQuery, Angular, React, Bootstrap, Meteor and Polymer, the feel of mobile web is getting closer and closer to a native experience. 

Browsers are getting faster, HTTP as a protocol is getting more streamlined with two-way connectivity using websockets, HTML5 and CSS3 are matching native apps special effect for special effect and animation for animation.

It would be a mistake not to consider making a responsive website to get a solution up and running as quickly as possible. If after careful consideration, app specific features are needed, then one must consider building an app.

To appify or not to appify

Fear not my friends, after all my lecture, I would like to end this post on a productive note. The following section lists some key functionalities of smartphones. Some of these features demand that an app be made to support them. For others, a responsive website will provide a sufficient and even better experience.

1. Text content editing with fallback offline storage: Think Google Drive and Evernote. If the data is text only, then look no further than responsive web. It is well capable of syncing with cloud to permanently store the data, while at the same time storing data offline just in case the user decides to document his trek from a mountain with no coverage. The only reason that Google Drive and Evernote had to make apps was reason 2, which is coming up.
2. Photography: Alas, on this one, the app wins. Responsive web has not yet found a way to use the camera.
3. Photo effects: Surprisingly, a responsive website is enough, provided photos are uploaded from the device instead of being taken directly from a camera. Pixlr is a good example.
4. Push notification: With the introduction of websockets, push notifications are now supported directly by responsive web. Facebook has integrated this seamlessly.
5. Drawing tools: One look at the website draw.io and you will never consider writing 3 seperate apps to replace your paper napkin diagrams.
6. Geolocation: GPS support has been in responsive web for almost 8 years now, ever since HTML5 made its grand entry. Google Maps has been pushing a pin on the top of your apartment on its web edition for several years now.
7. Sensors: Going for a jog? A swim perhaps? Sorry, a website won't help you here. Sensors are still off limits for responsive web and are expected to stay that way until W3C and IEEE join hands to form some standards on how to interact with sensors via web programming.
8. Shortcut on the phone's home screen: Answering this is a bit spotty. iOS has been supporting this feature for websites off the bat. Their Safari browser was beautifully integrated with their home screen. For Android, since Lollipop and with Chrome's latest mobile version, a website can set up an icon on the Android home page. But, hey wait, what if I love to use Opera. Well, in that case, things start to get tricky. To get the shortcut on the home screen, one MUST open the website on Safari (for iOS) or Chrome (for Android). But once the shortcut is placed, the website can be opened on any browser.
9. Completely offline content: Websites were not made to be consumed offline. Sure, one can always make a webpage with a barrage of links to download content to be viewed even when offline, but apps can be made such that they have offline content as soon as they are installed.
10. Audio / video streaming:  HTML5 introduced the support for playing audio and video without having to use memory guzzling Flash and Silverlight plugins. However they support only open standards and formats such as WebM and some popular formats like mp4, which is good for consuming publicly free to play videos. To play DRM encrypted / licensed content, special algorithms must be used. Their algorithms cannot be plugged into the browser on demand, but certainly can be integrated in an app when it is getting built.
11. Bluetooth: Bluetooth has been the domain of apps for quite sometime. However the introduction of Web Bluetooth and its support on every browser will bring this functionality to the browser. Currently it is a drafted specification and there are code sources for download to implement Bluetooth Low Energy, which is a lower energy version of Bluetooth, more favoured for tracking devices, rather than offering full functionality like file sharing and streaming. Full stack functionality and complete adoption by every browser will take time. Currently only Chrome supports web bluetooth in Low Energy mode.
12. Chat: Chat has been a browser-centric exercise even before the Google Talk era. Players like Yahoo chat and various dating and speed dating sites were websites before chatting apps for the desktop caught on.
13. Features requiring rapid changes: The odds are heavily stacked in favour of websites here. When features are nascent and need to be changed almost on a daily basis, websites can make sure that changes reach the users almost instantly. This is because the codebase of websites is present on the web servers of the product company rather than on the user's phone. With apps, it requires the user to find and trigger the installation of the latest version of the app. Sure, there are ways to force the user to update the app, but all methods have an element of friction and ultimately the user is the one who has to choose to download the latest version. With a website, the user doesn't have to opt to download or install anything. When s/he fires up the website during the next usage, the changes are automatically reflected by the browser.
14. Using protocols other than HTTP: The only way to go is to use apps. Browsers are inherently built to work on HTTP protocol. Period. For using any other protocol such as peer-to-peer networking like torrents, a browser simply does not have the support. A lot of protocols can be supported by a layer of HTTP, e.g. Email, streaming video calls, such that the browser can work with the HTTP layer and those HTTP messages are then converted into the underlying protocol messages, e.g. SMTP for email.