If you are scoping a new product today, you will eventually hit this question: build a progressive web app (PWA) that lives in the browser, or build a native app that lives in the App Store and Play Store. The honest answer is that both options have gotten better, and the gap that used to make this an easy call has narrowed on Android and shrunk (but not closed) on iOS. This article walks through what a PWA can and cannot do in 2026, where native still has a real advantage, and a practical framework for making the call based on your product, not on a vendor's sales pitch.
What a Progressive Web App Actually Is
A PWA is a website built to behave like an app. It uses a web app manifest file to define an icon, a name, and a display mode, and a service worker to cache assets, work offline, and respond to push messages. When a user adds it to their home screen, it opens in its own window without browser chrome, and from the outside it looks indistinguishable from a native app for most everyday tasks.
The appeal is straightforward: one codebase serves every platform, there is no app store review process standing between a bug fix and your users, and updates ship the moment you deploy, not days later after approval. MDN's documentation on progressive web apps covers the full set of capabilities the web platform now exposes, including installability, offline storage, and background sync.
What Changed: Where iOS Stands in 2026
For years, the practical case against PWAs was really a case against PWAs on iPhone. Apple's WebKit team documented the rollout of Web Push for home screen web apps starting in iOS and iPadOS 16.4, and that single change closed one of the biggest gaps between a PWA and a native app: the ability to re-engage a user who is not actively looking at your product. You can read the implementation details directly in Apple's WebKit blog post announcing Web Push for web apps on iOS and iPadOS.
A few conditions still apply and matter for planning:
- Installation is required first. A site open in a normal Safari tab cannot receive push notifications. The user has to add it to the home screen before notification permission even becomes available.
- Permission must follow a direct tap. Safari requires the notification permission prompt to be triggered by a user gesture, such as tapping a clearly labeled button, not fired automatically on page load.
- Biometric login works. WebAuthn support across modern browsers means a PWA can offer Face ID or fingerprint sign-in without a native wrapper, which removes another old objection.
So the notification gap that used to be a hard blocker is now a workflow design problem: you need to earn the install and the permission tap, not assume you have them.
Where Native Apps Still Win
Despite the progress, there are categories where native is still the right call, and no amount of web platform improvement changes that in the near term.
- Deep hardware access. Bluetooth and NFC support in the browser is inconsistent across platforms, and iOS Safari does not expose Web Bluetooth or Web NFC at all. If your product talks to a wearable, a point-of-sale reader, or a medical device over Bluetooth, you need native code.
- Platform-specific frameworks. Apps that rely on HealthKit, ARKit, or similarly deep OS-level frameworks cannot reach those APIs from a web app. There is no browser equivalent.
- Background processing. Native apps can run background tasks, sync data, and process location updates in ways that are still more reliable than what a service worker can guarantee, particularly on iOS where the operating system is aggressive about suspending background web activity.
- Storage durability. Browser storage on iOS can be reclaimed under memory or disk pressure after periods of inactivity, which is a real risk for an offline-first app that needs its local data to survive.
- Store discoverability. A meaningful share of users still discover and choose apps by browsing the App Store or Play Store. A PWA has no listing there (installable web apps are a separate, smaller discovery channel), so if store search is part of your acquisition plan, native or a hybrid approach keeps that channel open.
The Cost and Speed Tradeoff
The build-cost argument for PWAs is real but often overstated. A single web codebase genuinely reduces the engineering surface area compared to maintaining separate iOS and Android native apps, and it removes the app store review cycle from your release process, which matters if you ship frequently. What it does not do is eliminate the need for careful engineering: a PWA that needs to work offline, feel fast, and handle complex state still requires the same service worker caching strategy, data synchronization logic, and performance budget work that any serious web application needs. The architectural decisions that let a web application scale apply just as much to a PWA as to any other web product.
There is also a direct financial variable worth naming: distributing through the App Store means operating under Apple's commission structure. Apple's Small Business Program reduces the standard 30% commission to 15% for developers with under $1 million in annual App Store proceeds, but any paid app, subscription, or in-app purchase sold through a native iOS app still shares revenue with Apple. A PWA selling the same product through the web has no equivalent toll, which is one reason subscription and e-commerce products frequently push users toward the web experience for purchases even when they also maintain a native app.
If you are still scoping budget and timeline for either path, the same factors that drive what actually drives MVP development cost apply here: feature scope, integration complexity, and team structure matter more than the PWA-versus-native label by itself.
A Practical Decision Framework
Rather than treating this as an ideological choice, work through it as a short list of questions specific to your product.
- Does your core value depend on hardware the browser cannot reach? If you need Bluetooth peripherals, NFC payments, or deep health and fitness sensor data, plan for native on at least the platform where that matters most.
- Is your product mostly content, forms, or workflow built on data that is fetched and displayed? Booking systems, internal tools, dashboards, content platforms, and most SaaS products fit this pattern well, and a PWA is usually sufficient.
- How much of your growth depends on app store search? If a meaningful share of new users will find you by browsing the App Store or Play Store rather than through marketing, search, or referral links, native listing matters for acquisition even if the product itself would work fine as a PWA.
- How central are push notifications to retention, and who is your audience? If your users are mostly on Android, this is largely a non-issue. If a large share are on iOS, you need a deliberate install-and-opt-in flow, because you cannot notify anyone who has not added the app to their home screen.
- What is your release cadence? If you plan to ship fixes multiple times a week, the app store review cycle for native becomes real friction. A PWA removes that friction entirely.
The Hybrid Path Most Mature Products End Up On
Many established products do not pick one or the other. They run a PWA (or a responsive web app) for discovery, first-time use, and casual engagement, and reserve a native app for the smaller segment of users who become frequent, high-value customers and want the deeper integration, reliable notifications, and store presence that come with it. This mirrors the broader question of choosing between cross-platform frameworks like Flutter and React Native once you do commit to native: you are rarely choosing a single technology forever, you are sequencing investment based on where the product actually is.
The practical version of this strategy is to launch the PWA first, validate the product and the acquisition channels with lower engineering cost, and only invest in a native app once you have evidence that the features native unlocks (deep notifications, hardware access, store discovery) will move a metric you actually care about.
Common Questions
Can a PWA be submitted to the App Store or Play Store?
Android accepts PWAs packaged through tools like Bubblewrap for Play Store listing with relatively little friction. Apple's App Store review guidelines are stricter about apps that are primarily a wrapped website, so a PWA submitted as-is is often rejected or asked to add native functionality. Most teams treat Play Store packaging as viable and App Store listing as something to plan for separately if store presence on iOS matters.
Do PWAs work offline?
Yes, through a service worker that caches assets and data for offline use, and this is one of the more mature parts of the web platform. The caveat is that iOS can clear that cached storage after extended inactivity, so offline-first apps targeting iPhone users need to design for occasional cache loss rather than assume permanent local storage.
Is a PWA cheaper to maintain long term than two native apps?
Generally yes, because you maintain one codebase instead of separate iOS and Android native apps, and you skip two app store release pipelines. It is not free of maintenance cost: you still need to test across browser engines, manage service worker cache invalidation carefully (a stale cache is a common source of PWA bugs), and monitor performance on real devices.
Will Apple close the push notification gap further?
Apple has expanded web app capabilities steadily since iOS 16.4, partly in response to regulatory pressure including the EU's Digital Markets Act. Treat the current capability set as a floor, not a ceiling, but do not plan a product around a feature that has not shipped yet. Build against what is documented and verified today.
Making the Call
The question is rarely "PWA or native" as an abstract preference. It is "what does this specific product need from the device, how fast do I need to ship and iterate, and how much does store discovery matter to how I plan to acquire users." Answer those three questions honestly and the right starting point usually becomes clear, even if the long-term plan ends up being both.
If you are weighing this decision for a specific product and want a second opinion grounded in the engineering tradeoffs rather than a sales pitch, book a strategy call and walk through your requirements, or look at Sabyrix's mobile app development services and web application development services to see how each path is typically scoped.