Progressive Web App vs Native App: Does Your Business Need an App Store Presence?

Many businesses assume that "having an app" means building for the App Store and Google Play. That assumption commits you to two store accounts, review processes, release cycles and usually a second or third codebase before anyone has checked whether customers would install the app at all.

A progressive web app (PWA) is the main alternative. This guide explains what a PWA is, what it can and cannot do on iPhone and Android as of October 2026, where native apps are still the better choice, and how to stage the decision so you only pay for a store presence when it is justified.

Quick answer

A progressive web app is a website built so that it can be installed, work offline and send notifications, using one codebase for every device. A native app is built for a specific operating system and distributed through an app store.

• Choose a PWA first if your product is mostly content, forms, accounts, bookings, catalogs, dashboards or checkout, and customers reach you through search, links, email or QR codes.
• Choose native if the product depends on Bluetooth or NFC hardware on iPhone, reliable background work, deep operating system integration, or if customers expect to find you by searching an app store.
• You do not need an app store presence simply to have an icon on the home screen, offline access or push notifications. Both platforms now support those for web apps, with more friction on iPhone than on Android.

What a progressive web app actually is

MDN defines a PWA as "an app that's built using web platform technologies, but that provides a user experience like that of a platform-specific app" (MDN: What is a progressive web app?). It is not a separate product type or a framework. It is a website with a few specific additions:

• A web app manifest. A small file that tells the device the app's name, icons, start page and whether it should open in its own window without browser controls.
• A service worker. A script that sits between the app and the network. It can answer requests from a local cache, which is what makes offline use and fast repeat loads possible (web.dev: Service workers).
• HTTPS. Installable web apps must be served over a secure connection (MDN: Making PWAs installable).
• Push and notifications. With the user's permission, the server can send messages that appear even when the app is closed.

Because it is still a website, a PWA keeps the properties of the web: one codebase across operating systems, pages that search engines can index, and access through an ordinary link.

What PWAs can and cannot do today

The honest answer differs by platform, so it is worth separating Android from iPhone and iPad.

On Android

Android is the friendlier platform for web apps. Chrome will offer installation when a site is served over HTTPS, has a manifest with a name, icons, start URL and display mode, and the visitor has interacted with the page (web.dev: install criteria). A site can also show its own "Install" button.

In Chrome on devices with Google Mobile Services, and in Samsung Internet on Samsung devices, the installed PWA is packaged as a WebAPK, so it behaves much like any other installed app. Other Android browsers fall back to a home screen shortcut (web.dev: Installation). Push notifications, background sync, Web Bluetooth and Web NFC are all available in Chrome on Android, although MDN still marks the last two as experimental.

On iPhone and iPad

Apple's support is real but narrower, and the details matter.

• Installation is manual. There is no install prompt a website can trigger on iOS. The user opens the Share menu and chooses Add to Home Screen. Since iOS 16.4 this works from Safari, Chrome, Edge and Firefox (MDN).
• iOS 26 made the result more app-like. Apple's WebKit team states that "by default, every website added to the Home Screen opens as a web app", and the user can turn that off when adding (WebKit: Safari 26.0). The step of finding Add to Home Screen is unchanged.
• Push works only after installation. Web Push arrived in iOS and iPadOS 16.4 for Home Screen web apps. The app can ask for permission only "in response to direct user interaction", such as tapping a button. The same release added icon badges (WebKit: Web Push for Web Apps on iOS and iPadOS). A visitor who has not added the site to the Home Screen cannot receive push from it.
• Offline works. Service workers have been supported since iOS 11.3 (WebKit). Home Screen web apps get the same storage quota as the browser, and WebKit may still evict data from sites that have not been used recently unless storage has been granted persistent mode (WebKit: Updates to Storage Policy). Treat local storage as a cache, not as the only copy of anything important.
• Some hardware and background features are missing. According to MDN's compatibility data, Safari does not support the Background Synchronization API, the Web Bluetooth API or the Web NFC API.

One point applies equally in the US and the UK: switching browsers on an iPhone does not change these limits. Apple's rules require apps that browse the web to use WebKit, with an alternative-engine entitlement offered only for the EU and Japan (App Review Guidelines, 2.5.6). Chrome on an iPhone in New York or London has the same web capabilities as Safari.

Capability comparison

Camera, microphone and location support is described in web.dev: Capabilities. Browser support changes with each release, so recheck the linked compatibility tables before committing to a feature.

Where native apps still win

A PWA is the wrong starting point when the core of the product sits in one of these areas.

• Hardware on iPhone. If the product pairs with a Bluetooth device, reads NFC tags or talks to accessories, the web cannot do it on iOS today.
• Work that must happen in the background. Uploading field data after the app is closed, tracking a route, or keeping a large offline dataset in sync is far more dependable in a native app.
• Operating system integration. Home screen widgets, watch apps, health data, and similar platform frameworks are built for native apps.
• Demanding interfaces. Games, heavy animation, real-time video processing and augmented reality benefit from direct access to platform graphics and sensors.
• Re-engagement on iPhone. If push notifications to iPhone users are central to the business model, remember that web push only reaches people who completed the manual Add to Home Screen step. A native app can ask for notification permission as soon as it is installed from the store.
• Store-led discovery and trust. Some audiences look for an app in the store first, and some enterprise buyers expect a store listing they can deploy through device management.

If native is the right answer, the next question is whether to build separately for each platform or use a cross-platform framework. That choice is covered in our comparison of native vs Flutter vs React Native.

Distribution and discovery: store versus web

The two channels work in different ways, and this is often more decisive than any feature list.

How people find and install each

A PWA is reached by URL. It can rank in search results, be linked from an email or advert, and be opened from a QR code on packaging or a counter. There is nothing to download before the first use, and installation is an optional later step. A native app is found through store search, store features and links to its store page, and it must be installed before first use. Ranking inside the stores is its own discipline, known as app store optimization.

Review, release and fees

Updates to a PWA go live when you deploy them to your server. Native releases go through store review and reach users as they update. Stores also charge for membership: the Apple Developer Program is 99 USD per membership year (Apple) and Google Play has a 25 USD one-time registration fee (Google). Both stores have rules about how digital goods and subscriptions sold inside an app are paid for, and those rules vary by country and have been changing. Read the current guidelines for your market and take legal advice if payments are central to your model; this article is not legal advice. A PWA takes payment through your own web checkout.

A PWA can also be listed in a store

The choice is not strictly either/or. MDN notes that an installable PWA can be packaged for the Google Play Store, the Microsoft Store and the Apple App Store. On Android this is done with a Trusted Web Activity, which shows your web app full screen inside a thin Android app and verifies that the app and the site belong to the same owner. Microsoft documents a similar route for the Microsoft Store.

Apple is stricter. Its guidelines say an app "should include features, content, and UI that elevate it beyond a repackaged website" (App Review Guidelines, 4.2). A website placed in a wrapper with nothing added risks rejection, so plan for genuine app functionality if an App Store listing matters.

Cost and maintenance drivers

We do not quote figures here because they depend on scope, but the factors that move cost are consistent.

• Number of codebases. A PWA is one codebase that also serves as your website. Fully native means one for iOS and one for Android, plus the website you will still need. Cross-platform frameworks reduce this to one mobile codebase plus the website.
• The backend is the same either way. Accounts, payments, admin tools, APIs and integrations cost roughly the same whichever front end you choose. If most of your scope is here, the PWA versus native decision changes the total less than people expect.
• Offline depth. Showing cached pages offline is modest work. Letting users create and edit data offline, then resolving conflicts when they reconnect, is substantial work on any platform.
• Release overhead. Native apps carry store submissions, review cycles, signing certificates, screenshots and listing upkeep for every release.
• Platform upkeep. Native apps need updating as new operating system versions and store requirements arrive. PWAs need testing against new browser versions, especially Safari, where web app behavior has changed in several recent releases.
• Testing surface. Each additional platform, screen size and operating system version adds test effort.

Decision table

A staged approach

For most businesses the lowest-risk route is to earn each step with evidence from the previous one.

1. Start with a fast, responsive web application. Build the backend and APIs properly, because every later stage reuses them. Measure how many people return and how often.
2. Add PWA features. Add the manifest and service worker, cache the parts people revisit, and offer installation and notifications at a moment when they are useful, such as after an order is placed. On iPhone, show brief instructions for Add to Home Screen. Watch install and opt-in rates by platform.
3. Go native when a specific limit is costing you. Examples: iPhone users are not opting in to notifications, a feature needs hardware the web cannot reach, or customers keep asking for a store listing. At that point the native app is a new front end on an existing, proven backend.

Illustrative scenario, not a client case study: a regional equipment-hire company launches a booking PWA. Android customers install it readily and iPhone customers mostly keep using it in the browser. A year later the company adds Bluetooth smart locks to its lockers. That single requirement justifies a native app, which is built against the same booking API while the PWA continues to serve new and occasional customers.

For technical readers

• Chrome's install criteria no longer list a service worker, but you need one for offline behavior and for standard Web Push. Safari 18.4 added Declarative Web Push, which can display notifications without a service worker, still limited to Home Screen web apps on iOS (WebKit: Safari 18.4).
• Choose caching strategies per resource type: cache-first for versioned static assets, network-first or stale-while-revalidate for API data. Plan how a new service worker version takes over from the old one.
• On iOS, request notification permission from a tap handler inside the installed web app, and feature-detect rather than assume support.
• Without Background Sync on Safari, queue writes in IndexedDB and flush them when the app is next opened. Call the Storage API to request persistence, and keep the server as the source of truth.
• For Google Play, generate the Trusted Web Activity with Bubblewrap and publish the Digital Asset Links file at /.well-known/assetlinks.json using the fingerprint of the key that Play actually signs with.
• Test on physical iPhones across the iOS versions your users run. Home Screen web app behavior differs between iOS 16.4, 18.4 and 26.

FAQ

Can a progressive web app send push notifications on iPhone?

Yes, on iOS and iPadOS 16.4 or later, but only after the user has added the web app to the Home Screen and then granted permission by tapping a control inside it. A site that is only open in a browser tab cannot send push notifications on iPhone.

Can a PWA be published in the App Store or Google Play?

On Google Play, yes: a PWA can be packaged as a Trusted Web Activity. On the App Store, a web app in a wrapper must satisfy Apple's minimum functionality guideline, which asks for more than a repackaged website, so approval is not assured.

Do PWAs work offline?

Yes, if they are built to. A service worker stores the files and data you choose so the app opens without a connection. How much works offline is a design decision, and on iOS stored data can be removed if the app goes unused, so important data should always be saved to your server.

Is a PWA cheaper than a native app?

Usually the front end is, because one codebase serves every device and doubles as your website, and there is no store release process. The backend costs the same in both cases. The saving disappears if you later need native features and have to build a native app anyway, which is why checking the capability limits first matters.

Does a PWA help with SEO?

A PWA is a website, so its pages can be indexed and ranked like any other site, provided the content is accessible to search engine crawlers. A native app's content is not part of web search unless you also publish it on a website.

Can we move from a PWA to a native app later?

Yes. If the PWA talks to a well-designed API, a native app can use the same API, accounts and data. The user interface is rebuilt, but the backend, business rules and much of the product thinking carry over.

Conclusion

An app store presence is a distribution choice, not a prerequisite for an app-like product. A PWA now covers installation, offline use and notifications on both major platforms, with clear gaps on iPhone around installation friction, background work and hardware access. Native remains the right call when your product sits in those gaps or when your customers look in the store first.

A practical next step is to list the five features your product cannot live without and check each one against the capability table above for iPhone specifically. If none of them falls in a gap, start on the web and let usage data tell you whether a native app is worth adding. Entrant Technologies builds web applications and mobile apps, and if you would like a second opinion on that feature list you can share your requirements with us.