An Article

Native Apps vs. PWAs: Cost & Complexity Realities

Nathaniel Bibler By Nathaniel Bibler // 8.26.2019

All projects have limited resources.

This is especially true and most difficult to fully realize at the beginning of a new project effort. When a project is just kicking off, all of the grand ideas, must-haves, nice-to-haves, and wouldn’t-it-be-neats are being described, designed, and planned to come to fruition. The combination of all of these things can very quickly blow out time and money limitations.

One common requirement we hear is that a project must be launched as a web app, an iOS app in the App Store, and an Android app in the Google Play Store.

Launching with a web application makes complete sense: When well crafted, a web app supports consumers using desktops, laptops, and mobile devices equally well. Web apps will often function similarly well on old devices as on new. As consumers switch back-and-forth between their devices, a web app will seamlessly follow them along. And, while the web itself and its standards are always-evolving, it’s not leaving us anytime soon and presents a solid, long-term, stable platform on which to build something valuable.

There are certainly situations where delivering a native app is a requirement. A native app will be necessary when it must access sensor information, live cameras, and contacts; use augmented reality; or run in the background, for example. An intense, fast-paced game is also going to require going native. Otherwise, most all of the perceived value of native apps can be harnessed in web apps and even augmented by making good use of progressive web applications (PWAs).

PWAs are web app experiences that are fast, reliable, and engaging. On many mobile and desktop devices, they can be installed like native apps and launched from homescreens and desktops. They load instantly when launched, gracefully handle all network conditions, and feel like a native app to consumers. Google Maps, Uber, Starbucks, and Tinder currently deliver PWAs, just to name a few.

But ultimately, PWAs are traditional web apps that have made extra considerations for user experiences and provided additional instructions for devices about how they load and launch.

With that in mind, when budgets or timelines are tight, we often push back against and provide alternatives to the perceived need to launch a new project with native applications. The rationale behind our reticence varies, as there are many different reasons why stakeholders believe native applications are a requirement, including:

  1. When I push my new app into the App Store, consumers will easily find it, install it, and the app will be an immediate success.
  2. Everyone has apps in the app stores and therefore consumers expect to find my new app there as well.
  3. Once consumers install my app on their device, they will interact with it more regularly than they will if it were only on the web.

The largest item not often recognized is that to concurrently build three different applications (web, iOS, and Android), with teams that must actively interact with each other regularly, doesn’t just triple the cost: it’s exponentially more. 

A Common App Mistake: If You Build, Will They Will Come?

It’s difficult to get exact numbers, but most analysts report that both Apple’s App Store and the Google Play Store have around 2.5 million unique apps available as of early 2019. That’s a lot of choices for consumers and a lot of competition for you.


The act of putting your app into a store does not, by itself, bring customers. The chance that a new consumer having never seen your brand before will even be presented with your app in a store is incredibly low. It’s simply not the store’s job to promote or even suggest your new app, at all. The stores’ job is to promote only those apps that are already proven to be successful. Why? Because their goal is to create a snowball effect to make all of their other customers that much happier with their store and their offerings.

To do that, these stores sift, sort, and filter millions of apps to try to present exactly the right apps to their customers at exactly the right times. This is done by looking at the longevity of the app, the ratings on the app, the number of installations vs. deletions of an app, consumer search history and usage patterns, and more. A lot goes into what you see when you search. Simply put, fresh new apps just don’t score highly on any of those metrics.

All that to say, if you are not actively marketing and promoting your app to your customers, no one else will do it for you.

Everyone Offers An App

There are millions of apps in the app stores. That does then mean there are a lot of companies putting their apps onto those stores. In practice, the reasoning for and value of their presence varies – not all of them are well-crafted apps. Some apps are added purely for brand awareness, and others provide such little or broken functionality that they become detrimental to the brand they represent.

Many of the apps and companies that come to mind when thinking about what’s on the app stores are those which have already proven to be successful. They are brands and products that have either existed for years and come later to the platforms, brought something unique or special to the platforms, or have marketed and advertised themselves enough to be top-of-mind. Again, it gets back to awareness.

Offering an app, by itself, isn’t valuable. Finding customers and driving them to your project is what’s valuable.

As a counter example to everyone having an app, there is Craigslist as an exception (granted, Craigslist is often a counter example to everything: good design, usability, efficient navigation, and more). But specifically, Craigslist does not have an official native app on any app store. They expect consumers to use their web app only, and consumers do.

Having a native app available is not a requirement to having a successful project. 

Habituation Through App Installation

Stakeholders sometimes believe that if they can just get an app installed onto a consumer’s device, then that consumer will interact longer and more often. There’s a correlation versus causation problem with this belief.

If you’ve already convinced a consumer to install your application onto their device, then that consumer is already more likely to both trust and interact with you. Further, if that same consumer already wants to interact with you, then they’re equally likely to do it through a native app as a web app as long as they’re equally accessible. The consumer has already found value in the effort in using your app. And web apps can be presented on device homescreens by using “save to homescreen” for any web app. Or if a PWA is available, Google devices will prompt users to install automatically when browsing your site.

If a consumer wants to use your app, they’ll do it regardless of where it lives.

Multiplying Apps Multiplies Costs

Building a complex application is hard. It’s even harder when trying to simultaneously build three different applications for three different platforms (web, iOS, and Android). There are now up to three teams of developers involved. Those teams represent three times as many individuals making decisions and assumptions that need to remain clear and consistent between all of the applications. With three delivery platforms, there are now three different deployment processes to follow. This multi-team complexity quickly explodes the opportunities for misunderstandings and new inconsistencies. It also drastically slows overall development pacing by introducing exponentially more communication necessary to reach the conclusion.

A new project carries a lot of unknowns for everyone: developers and stakeholders, alike. There will be realizations that initial assumptions were wrong, pivots to manage complexities, and unexpectedly difficult (or expensive) integrations with outside systems, just to identify a few problems that may unexpectedly arise. Addressing all of these issues is hard enough when you’re creating just one application.

It’s better for everyone involved to validate the project with customers as quickly and efficiently as possible. Once customers see and interact with an app for the first time, there will inevitably be pivots, shifts, and new understandings that affect the direction and approach taken to address them by the app. As this new information is gained, it can be more quickly adapted, applied, and revalidated by changing one app rather than all three.

PWAs as a Native App Alternative

As was briefly mentioned, many of the benefits of developing a native app can be easily addressed with a well-built web app using PWA enhancements. PWAs are built by the same team that builds the web app and are really just an extension to it. The PWA definitions instruct devices about brand colors and logos, how to present the web app when launched, splash screen details while loading or updating the app, which parts of the app to cache locally to the device for fast launching and offline support, and more.

On Android devices, for example, a web app with PWA support will prompt the consumer to install the app onto their home screen during normal website browsing (iOS doesn’t yet automatically prompt). Once installed on either platform, a PWA looks and behaves identically to a native app. There’s a branded icon on the home screen, one tap to launch, and an immediate splash screen and app presentation. PWAs also gain the benefit of being able to update automatically, at your discretion, without needing to interact with an app store gatekeeper. And, because the PWA is your web app, you have one team, one development flow, one deployment process, and no cross-team communication bottlenecks.

The Google Play Store and Microsoft Store now index and list PWAs in their stores, allowing consumers in the stores to find, install, and use PWAs alongside the native alternatives. Further, as of Chrome 73, PWAs can now be installed to desktops as if they were a native desktop application.

PWAs provide nearly all of the benefits of a native app with far fewer of the complexities and costs.

Decide Early: Native App or Not?

The most challenging effort at the start of a project is finding the proper balance of desires and the realities of resource limitations.

In the end, spending money on sales, research, and marketing in an effort to validate the project early is always best. Find your market, identify and reach your customers, gather customer feedback, then rapidly apply what you learned to your project development and direction. At that point, you’re armed with enough information to determine whether or not focusing more resources on native applications makes sense for your project.

You may find that a native app isn’t necessary to launch or maybe even necessary to ever offer.

Next Up

Budget Creep: How Change Impacts Custom Software Development Cost

Nick Walsh By Nick Walsh // 8.19.2019

Avoid your software budget estimate being riddled with expensive surprises by focusing on build quality, the bigger picture, and longevity.