Native Apps vs. PWAs: Cost & Complexity Realities

All projects have limited resources.

This is especially true (and most difficult to identify) at the beginning of a project. When an effort 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 limits.

One common requirement we address is the multi-platform launch: a web-based application, an iOS app, and an Android app all hitting their respective homes at the same time.

It sounds like a sound strategy — let’s hit every audience at once — but overextending puts those two most valuable resources (time and money) in the wrong place. Let’s take a look at each, the usual arguments for a cross-platform build, and the key downsides.

Web & Native & PWA, Oh My!

We’ll start with a glance at a few of the directions a project can follow.

The Ubiquity of Web Applications

Launching with a web application makes complete sense: When well crafted, a web app supports consumers using desktops, laptops, and mobile devices equally well.

They’ll typically work as 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.

Getting Close to the Metal With Native

There are certainly situations where delivering a native app is a requirement. A native app will be necessary when it must access some sensor information, native components, and contacts; use certain augmented reality features; or run in the background, for example. An intense, fast-paced game is also going to require going native.

Otherwise, most 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).

Bridging Needs With 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 home screens 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.

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

Native Isn’t as Necessary as You Think

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 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 would 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 — doesn’t just triple the cost. It’s exponentially more. 

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

It’s difficult to get exact numbers, but analysts report that the Apple App Store and the Google Play store both have millions of entries. 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 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. The store’s 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.

“But Everyone Has an App”

There are millions of apps in the app stores, so it stands to reason that there are a lot of companies putting their apps onto those stores. In practice, the thinking behind 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 all stems from 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, take Craigslist. (Granted, Craigslist is often a counter example to everything: good design, usability, efficient navigation, and more.) Specifically, though, 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. 

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). Now, you’ve introduced up to three teams of developers.

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. 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 we 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 many 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 at launch — or ever.