PWAs vs Native Mobile Apps: What You Need to Know

Everyone knows and uses mobile apps—of course—but few realize that there are two primary types of mobile apps: Native and PWAs. Each approach has pros and cons, and it is critical to choose the right model for your app and your business needs. This blog breaks down the differences to help you choose what’s best for you.

What Are Native Mobile Apps?

Native mobile apps are applications designed for specific platforms like Android or iOS. These days, native mobile apps are typically developed using tools like React Native, Flutter, Xamarin, etc., that create apps for various mobile platforms from a single codebase. Depending upon users granting permission, native apps can leverage a broad spectrum of features in the phone, including communicating with other native apps as well as accessing services like Near Field Communications (NFC) for wallet payment. More on this later. Users download and install native apps from app stores like Google Play or the Apple App Store.

Examples of Native Mobile Apps: Facebook, WhatsApp, Waze, and banking apps.

What Are Progressive Web Apps (PWAs)?

PWAs are applications developed using web technologies, and they operate in a browser. From a user experience, very little changes because the browser fades into the background once you are in the PWA, so users may not realize they are using a PWA. They can run on any platform that supports a web browser and load directly without going to the app store and downloading it. PWAs can also be added to your phone’s home screen, just like a native app.

A cool feature of PWAs is that they can run not only on your mobile device but also on your tablet and PC… and it’s the same app… although formatting must be tuned for the screen size! This makes for a smoother experience transitioning between the two since everything—data, registration, sign-on, etc.—is shared. It also makes building an app for multiple platforms cheaper and faster.

PWAs are different from Progressive Websites…I know it is confusing. Progressive websites adjust to different screen sizes, making them “progressive.” An example of this is Facebook.com. You can tell that Facebook.com is just a progressive website because when you turn off your internet—phone network and Wi-Fi—the buttons on the website stop working. Yes, Facebook also has a native mobile app. A PWA uses browser technologies but also includes service workers who provide access to certain features of the phone and enable disconnected or offline operation. This makes PWAs work just like a native app whether connected to the internet or not.

While you may hear that PWAs cannot be distributed through app stores, it’s not that black-and-white. Native apps are distributed through app stores, while PWAs can be distributed through app stores if the developer uses Bubblewrap (Google Play only) or PWA builder, but they don’t have to go through the stores; you can simply scan a QR code, and start using it.

Examples of PWAs: Zoom, Pinterest, Tinder, Uber, Lyft, Spotify, X

Native vs. PWA - Pros & Cons

** Using PWABuilder or Bubblewrap, but then you lose the other business advantages of a PWA

As you can see above, the technology differences are a bit of a mixed bag, while the business differences heavily favor the PWA model. Because of the business advantages, big companies and open-source tools have been reducing the PWA technology gap. The fact that big brand companies are increasingly going with the PWA model indicates that it has a strong future. In fact, you probably didn’t even know that the PWA examples listed above aren’t native because they look and function just like native apps.

Apple is very protective of its app store control and revenue, so it restricted access to certain phone features inside of Safari specifically and, to a lesser degree, other browsers. Look into the current iOS/iPhone features available at the time and match those against your requirements. I also expect the app store tax on in-app purchases will decline because of pressure from PWAs. If your business sells in-app digital goods purchases, and you don’t need the ultimate performance (e.g., some games), you might lean towards a PWA. This only applies to digital goods, like music, NFTs, images, etc. not to real-world goods like a t-shirt or home services.

If your business requires exposure to app store users, you can use Bubblewrap or PWABuilder, but then you lose the other business advantages of a PWA because you are subject to the app stores’ constraints. The PWA model has the advantage that the search engines crawl it, so you get better SEO “juice,” providing the search channel for customer acquisition instead of the app store channel. The app discovery question comes down to how your customers will find you via the app store or search engine.

If you are building a banking app or you prioritize superior security or accessing the NFC-enabled wallet, you want to go with a native app. If your solution depends on sharing data with other apps, like Contacts, you may have to build a native app, but this constraint can also be mitigated by technologies like contact loaders.

The centralized model of the app stores enables de-platforming for several reasons: politics (e.g., Gettr), regulatory reasons, misinformation (e.g., Covid-19), etc. Some might consider this a feature, while others consider it a bug. If you are building an app for crypto, alternative medicine, gambling, or want to give a voice to things that might be considered unacceptable or misinformation, the PWA is clearly your best bet.

If you’re on a tight budget or a tight time schedule, the PWA is going to be faster and cheaper. The fact that the same app can operate on a laptop, tablet, and all mobile phones with some minor design modifications is a big plus in terms of cost to build and maintain. Since your customers are all using the latest version of the app and fixes are instantaneous, support is also more cost-effective with a PWA.

If users want to quickly download and start using the app, the PWA model has advantages. With a native app, you scan a QR code, choose your app store, download a large file, and start using it in maybe a few minutes on a decent connection. With a PWA, it is a quick scan-and-use model; you scan a QR code, and you are using it in seconds. The PWA user also doesn’t have that heavy native app-consuming space on their device. Based on these characteristics, temporary apps like those for a tradeshow, hotel stay, tourist travel, etc., should consider the PWA model.

Future-proofing your app is also a consideration. Because certain features are only available to native apps, you need to know whether you’ll need those features in the future. For example, a PWA can only share GPS coordinates when it is the focus; running on the screen viewed by the user. This may seem acceptable at first, but then your users may demand it also work in the background. This could require a rewrite as a native app. This may not be a big concern, because you may choose to use the PWA model—for time-to-market and cost reasons—and see if your app hits, with the plan that 18-24 months down the road you may rewrite it as a native app if it succeeds.

Conclusion

The choice between PWA and native apps depends on a variety of factors. We’ve built both, and I cannot recommend one over the other without first understanding the business requirements. The PWA model has some advantages, especially on the business side, and the technology gap is decreasing, so time favors the PWA. On the other hand, certain features like the NFC wallet and advanced security are only available to native app. When someone asks whether they should go with a PWA or native app, I recommend that they read through this blog post, consider all issues, and make their own decision. As with many things, selecting the right tool for the job requires that you understand that job first.