Do you really need a mobile app?
Disclaimer: I’m somewhat biased against mobile apps. I dislike the walled garden approach to software distribution that Apple represents (Facebook is another major culprit). I’ve also had some bad experiences with arbitrary decisions by Apple that affected already launched apps, with no avenue for appeal. So take this with as many grains of salt as you see fit!
When you’re thinking about building a software product, one of your first choices will be whether to build and launch it as a native mobile app (i.e., built specifically for iOS and Android devices and distributed through the the app stores of Apple and Google), a web application, or possibly both1.
Mobile apps have a few advantages over web applications accessed via a mobile browser. Primarily among them are increased speed and responsiveness of the user interface; access to certain restricted phone features and data (e.g. contacts, SMS); installation on the home screen; and no need for repeated authentication.
These advantages are mostly concerned with user experience (UX), which is the focus of many articles comparing native apps favorably to web applications.
Now I’m going to say something mildly controversial: User experience is not the only aspect to take into account when making a technology choice you will live with for quite some time. It might not even be the most important one for you.
Writing and deploying native apps for iOS and Android has some distinct and non-trivial downsides. Most of these revolve around your ability to keep control, both of your users’ experience and of development and operations cost.
Here are a few things to keep in mind when considering going down the native app route:
Updates are slow and may never reach all users
Each update to a native app has to be submitted to the app stores. In Apple’s case, the mandatory review process for each update takes 24-48 hours in the best case. It can take weeks for the most trivial of reasons2.
And once your updated app has made it to the app stores, it still must make it downstream to your users’ devices. Some of them will have auto-updated enabled, but certainly not all of them. Over time, you will have an uneven distribution of new and old versions across your user base. You may even get negative reviews for bugs that have long been fixed, from users running old versions of your app.
A mobile-first web app, on the other hand, is basically just a website - the code runs on your servers. So when you push an update, it is instantaneously effective for 100% of your users.
Apple may kill your app at any time
Apple3 has very stringent requirements for applications submitted to their app store, and is known for both changing and enforcing them somewhat arbitrarily. Especially for business-to-business (B2B) applications where all functionality is only accessible to registered users, you may well end up being forced into their cumbersome, user-unfriendly and basically horrible business connect program.
Even if you have been approved to the regular app store, the risks of changing terms and conditions persists and may catch you any time you submit the smallest update to the app store4.
You’ll have to keep up with changing phone technology
Do you expect your app to be around a few years after release? Then you better be prepared to keep your developer on hand to ensure it continues to work as iOS and Android operating systems evolve. Anything that works on the web today is pretty likely to still work a few years from now5. That is decidedly not the case for native apps.
You may have to share your revenue
Both Google and Apple charge up to 30% commission and fees on any purchase made and delivered through an app distributed through their app stores. If your application is primarily an eCommerce interface for digital content, that alone is probably a prohibitive barrier for your business.
Note that this does not apply to physical goods (e.g. Amazon), services delivered outside of the app (Uber, AirBnB), or subscription services when the subscription itself is paid outside of the app (Netflix).
You’ll pay more for development
Writing true native apps for distribution to both iOS and Android devices requires maintaining two completely separate code bases, written in different programming languages (Java for Android, Objective-C for iOS). This will basically double your investment in development and maintenance, while still incurring the risk of divergent user experiences across both platforms.
You can overcome this problem partially by writing a hybrid app. This approach basically allows you to write the application only once, using a web-based technology stack, and convert them to natively running apps for both platforms automatically. However, this approach negates one of the primary benefits of native apps, which is the fast and smooth user experience only true native apps can offer.
You may not be able to take advantage anyway
If your application relies real-time access to a backend for its core functionality, such as a database or some third party service provider, the latency of requests and responses between the client (the mobile device) and the server is the dominant performance factor - just like for any website! So there is little point in choosing native technology primarily for the faster user interface - all you’ll end up with is slightly smoother progress bars and spinning wheels while waiting for network responses.
What web apps do better
Native apps have their place, and are the only way to go for applications that absolutely require the best and smoothest user interface (think games like Angry Birds) or need access to restricted phone features (your contact list, for example).
But absent of such strict functional requirements, building a mobile-enabled web application gives you business and operational advantages that may well outweigh UI/UX concerns.
What does mobile even mean to you?
If “mobile” is just another channel for you to offer into an application that already exists on the web, consider building (or rebuilding your existing website as) a mobile-first web application instead.
With a little bit of extra development effort and some judicious choices of technology, you can build it as a so-called “progressive” web application, which offers some of the benefits of mobile apps such as home screen installation and offline support without the need of going native.
Here is a hit list of some of the advantages of a web app over native mobile apps:
- Updates are immediate and reach all your users (and so do rollbacks)
- You have insights into user statistics and behaviour which the app stores may not provide
- You’ll never lose control over your distribution channel
- You need fewer development resources
- Existing websites can be adapted for a better mobile experience without starting over
Keep your options open
Web technology is ever evolving, and many features that a few years ago where the sole province of native apps are now available to web applications6, which can be built and deployed without the added overhead and business risks of distributing native apps through Apple and Google.
Particularly for startups or businesses that want to get an initial app version into the hands of real customers as fast as possible, and then learn from and improve the app with customer feedback in regular and fast iterations, the advantages of deploying web application may well outweigh the disadvantages.
Yes, there are other types of software, I know. This article is simply focused on the trade-offs between mobile and web. ↩
Like, a new model of iPhone came out since your last release, and you have not yet updated the screenshots in your store listing to reflect Apple’s latest burst of design genius. How’s that for a reason to hold up your urgent bugfix update? No, I’m not bitter ↩
Yes, I have strong opinions on Apple. Apple has strong opinions on your app, too. I also work on a MacBook, so I’m not all that biased. Or maybe just a hypocrite. ↩
Google is much less stringent about these things than Apple. If you can live without the iOS market, the risk of store rejection is much less severe. But it’s never zero. ↩