We’re here to settle the debate once and for all.
By the time an entrepreneur is ready to start building an app, they’ve likely already got a strong vision, a strong idea of who the target audience will be, and perhaps even a good sense of what belongs in the MVP. But when it comes to the question of which platform they’ll use to develop the first iteration of their app — be it mobile web or native — many entrepreneurs simply aren’t aware of all the factors that should be guiding their decision, nor how important their ultimate answer will be.
In our experience, entrepreneurs far too often choose to build their MVP in native mobile, and it’s not hard to see why. For some time now, experts in the tech space have hailed mobile as the future of digital media: after mobile traffic overtook desktop for the first time last year, the consensus is that practically everything will be read on phones and tablets in the very near future. But the truth is that mobile native is very often the wrong approach not just from a design standpoint, but from a business perspective as well.
That’s not to say there’s no instance in which a mobile native approach is ideal: for any app where you know the primary functionality will exist only on mobile, such as a mobile game or a dating app like Tinder, it makes sense to design and build for the smartphone user. Or, if you’re already certain that most of your revenue will come from mobile purchases (this is often true for restaurants and eCommerce retailers), it makes plenty of sense to focus all of your attention on making the mobile UX as clean and seamless as possible.
However, if there isn’t a distinct advantage to building only for mobile, the approach comes with significant disadvantages. For example, if users download the app and don't like the MVP, there's a high likelihood they will delete it, never to download it again. 90% of users eventually stop using the app by the 90-day mark — if you are going to make a mobile app, you must be absolutely sure it’s good as it can be. As we all know, though, most MVP’s are far from flawless.
Another huge downside of mobile native is that you’re forced to multiply the development work for each platform supported. Android and iPhone apps usually require different code bases — either that, or you’re forced to choose between the two platforms. By contrast, web apps will work on anything with a web browser, although designs are usually intended for either desktop or mobile.
But perhaps the biggest drawback of building your app for mobile users is the process of getting your product accepted by the app stores. The Apple Store in particular has a very specific set of standards for acceptance and a long review process — developers spend weeks waiting for a decision only to find they’ve been rejected for anything from broken links to improperly displaying ads, then must scramble to make fixes, send a new version, and wait even longer for another decision. This process is especially frustrating for Agile advocates, as it’s inefficient and far from iterative.
By contrast, building a responsive web app through a platform like React offers designers and developers more freedom, allows for more efficient testing, and speeds your time to market. While past web technologies suffered from responsiveness issues that caused applications to lag on certain devices, web technologies like React are today fast and powerful enough to make your app look good and perform well in practically any setting.
Then there’s the simple fact that designing a responsive app means you’re building for a bigger screen, which means you have access to more tools and more possibilities. Any problems concerning UX are far easier to identify and fix, which is ideal when designing your minimum viable product (MVP). And while you don’t want to waste time and effort on functionalities that may not belong in the mobile version, you can’t know which features are going to give you a competitive advantage until the first prototype is released. It’s better to test and evaluate features that may not be practical than to limit your imagination to whatever’s available on mobile.
Another thing to note is that once the responsive app is built you can easily adapt it for mobile. Although some design and frontend work is involved, it is far less difficult than building an entirely new app from scratch.
Finally, there’s no acceptance or approval process for responsive web apps: develop your first prototype and show it to whomever you want, whenever you want, on any device you want. That not only means you’ll be able to test the MVP on a wider audience, but that the testing and approval process will take far less time and result in more iterations making it to market faster, which often makes for a higher-quality end product.
The tech space today seems to be dominated by apps, but it’s helpful to consider where many of the biggest players in that world started out. Facebook began as an entirely web-based platform, and only became a smartphone app in the relatively recent past. The same goes for LinkedIn.
Many entrepreneurs underestimate just how easy and fast it is to translate a responsive web app into a mobile app. If you’re itching to have a mobile-specific product, you can easily release one in months, not years after the release of your initial web app.
Responsive design may not always be the right choice, but the truth is that in most cases it’s a safer bet that offers greater ROI, at least for the first or second iteration. Entrepreneurs should consider their audience before making a decision, but keep in mind the many advantages responsive offers over mobile native for most app ideas.