First everybody wanted a website. Then along came Flash and so people wanted a Flash site. Then there was Facebook and that became the must-have thing to be a part of. Now everybody wants a mobile app. But do they really need one?
After all, the process of creating a mobile app is not without its challenges.
I delve deeper into this topic in a Learnable screencast at the end of this article by taking a look at case studies where the decision to go native perhaps wasn’t the best.
The Problems with Going Native
When smart phone app stores first launched there was a land rush to fulfill consumer demand for native applications. In those early days there were some incredible opportunities. But those days are gone.
With well over 1 million apps in both the iTunes and Android stores, supply has exceeded demand.
Worse still, getting found is difficult in stores lacking sophisticated search functionality. Where once being on the App Store provided unprecedented exposure, and there are still some ways to improve your app marketplace ranking, today it is likely your app will be rarely seen.
Even if a user does see your app and downloads it, that does not guarantee they will keep it. With limited storage space users only keep so many apps on their device. They’re ruthless when it comes to deleting apps. Users tend to only keep apps that they are using on a regular basis.
The biggest problem with native applications is their cost. Unlike learning HTML and CSS, there is a high barrier to entry when it comes to developing native mobile apps. This means that hiring application developers is expensive compared to their web counterparts.
But the real cost comes in supporting many platforms and devices. Unlike the web you cannot build once and be sure that it will work everywhere. You cannot even use the same language to code across more than one platform.
It is not only expensive to build your application in the first place but also to maintain it over time. Every new device released could force you to update your app. Changes in the screen size, resolution and OS can lead to alterations in your application.
Despite that, there are occasions when the costs are worth it because the use case justifies it.
When Native Apps Are a Good Idea
There are situations where having a native application makes a lot of sense.
For a start there is some functionality that is not available via the web-based alternative. Most smartphones limit access to some native features unless you build a native app. For example, a web-based app cannot access the address book on your iPhone.
Speed can be another reason to go native. Although it is possible to cache a mobile friendly website, they are never going to be as responsive as a native application. So when speed is crucial it is worth considering a native option.
Where native apps excel is for empowering users to complete clearly defined tasks on a regular basis. Taking photos, updating social networks, and messaging friends are better handled by native applications. This is because their task orientated and the user will want them instantly available at all times.
Home sweet home
One of the main reasons given for wanting a native application is to be in the App Store and appear on people’s home screens. At one time this reason may have been justifiable. But not any more. Thanks to responsive design the quality of mobile friendly websites has improved. This means users are more comfortable using them.
Furthermore, users can add websites to their home screens just like any other application. Websites can even send notifications like a native app.
The decision to build a native app or a mobile friendly website hinges on the frequency of use and the functionality it delivers.
Content vs. Behavioral
Although the decision of whether to go with a native application or mobile friendly website is a complex one, there is a rule of thumb. Generally speaking, if you are trying to help users complete tasks then a native application may be the way to go. But, if you are primarily delivering content then turn first to a mobile friendly website.
A website can accommodate task-based applications, especially in simple use cases; unfortunately as with so many things in life it is not black and white.
At first glance hybrid applications may seem like the perfect solution. The barrier to entry is lower and you can build once while delivering across many platforms. It also provides you access to much of the functionality you find in a native application.
But before you rush out to build your first hybrid application it is worth noting that they do have some drawbacks.
For a start, hybrid applications do not offer all the functionality available to a native application. They also suffer from some performance and compatibility issues.
But perhaps the biggest problem is perception. Often they just do not feel like a native application. Unlike a mobile friendly website, users expect hybrid apps to behave like a native application. They expect it to look and behave like an iPhone or Android app.
If you are building once and delivering across all platforms that is not going to be possible. As a result hybrid applications can sometimes feel like an uncomfortable compromise between the two approaches.
So What Is the Answer?
With each approach having its own drawbacks deciding how to proceed is a difficult challenge. As with all things it comes down to return on investment.
We need to think through the decision whether to develop a native application or mobile friendly website. We cannot respond in a knee jerk reaction of “everybody has an app so we need one too.” Instead, there needs to be a solid business case.
At the moment that often means a responsive website. But as mobile continues to grow at an exponential rate things may change. Add to that the speed increases in the cellular networks and perhaps we will be looking at a fourth option — web based applications. But that is in the future and that is the thing: the mobile market is still evolving at a rapid rate. We need to think hard before investing large amounts of money in applications that may well be obsolete in a few years.