PWA vs Native Apps: Which Does Your Business Need in 2026?

Key takeaways

• The honest answer is "it depends on goals, audience, budget, and feature needs." Choose a PWA when reach, search discoverability, fast iteration, and a tight budget matter and you do not need deep device hardware. Choose native (or cross-platform) when you need top performance, deep hardware access, strong app store presence, reliable rich notifications, or app store monetization.

• The technology gap has narrowed: since iOS 16.4 (March 2023) Home Screen web apps on iPhone can send web push notifications, and in iOS 26 (2025) every site added to the Home Screen opens as a web app by default. iOS still blocks Web Bluetooth, NFC, USB, and background sync, so PWAs remain second-class on iPhone compared to Android.

• For most businesses the real choice is PWA vs cross-platform (React Native or Flutter), not PWA vs two fully native apps. A "PWA first to validate, native later to scale" sequence is often the cheapest path to certainty.

PWA installable web icon next to iOS and Android native app icons with feature comparison badges

The spectrum, in plain English

A Progressive Web App (PWA) is, per MDN, "an app that's built using web platform technologies, but that provides a user experience like that of a platform-specific app." It runs from one codebase across devices, can be installed on the device, can work offline, and can integrate with the operating system. MDN states the technical minimum bluntly: "all PWAs require at minimum a manifest and a service worker." The term was coined in 2015 by Google engineer Alex Russell and designer Frances Berriman.

A service worker is, per web.dev, a script that "acts as middleware between your PWA and the servers it interacts with, intercepts the request and acts as a network proxy, even if the user is offline." It enables offline caching, background tasks, and push handling. The web app manifest is a JSON file that lets the browser install the app to the home screen. PWAs also require HTTPS.

A native app is built specifically for one OS using that platform's SDK and languages (Swift or Objective-C for iOS, Kotlin or Java for Android), distributed via the App Store or Google Play, with full access to device hardware and APIs.

The middle ground is where many real decisions land:

• Cross-platform native (React Native, Flutter): one codebase compiled to near-native apps that ship through the app stores. Flutter uses Dart and its own rendering engine (Skia, transitioning to Impeller). React Native uses JavaScript or TypeScript and renders via real native components.

• Hybrid (Capacitor or Ionic, Cordova): a web app wrapped in a native WebView shell with a bridge to native APIs. Per Ionic, Capacitor "runs modern Web Apps natively on iOS, Android, Electron, and Web, while providing a powerful and easy-to-use interface for accessing native SDKs."

So PWA vs cross-platform vs fully native is a spectrum of tradeoffs, not a binary. The right answer is rarely "the best one" in the abstract. It is the one that matches what your app actually has to do and who has to maintain it. Our team builds across that spectrum through website development and app design and development, which is why we approach this comparison as a decision tool, not a sales pitch for one side.

How PWAs work, and the big iOS shift

PWAs rest on three pillars: service workers (offline caching, background sync, push handling), the web app manifest (installability), and HTTPS (required for service workers to register).

The biggest recent shift is on iOS. With iOS and iPadOS 16.4 in March 2023, Apple added Web Push for Home Screen web apps. From Apple's WebKit blog: "with iOS and iPadOS 16.4, we are adding support for Web Push to Home Screen web apps. The notifications from web apps work exactly like notifications from other apps. They show on the Lock Screen, in Notification Center, and on a paired Apple Watch." iOS 16.4 also added the Badging API. Two caveats: on iOS, web push only works when the site is added to the Home Screen (not in a Safari tab), and the permission prompt must follow a direct user interaction.

The second milestone came in iOS 26 (2025). Per Apple's WebKit blog: "By default, every website added to the Home Screen opens as a web app. There are now zero requirements for installability in Safari." Users can opt out per site. Safari 18.4 (2025) added Declarative Web Push and Screen Wake Lock.

The brief 2024 EU controversy is worth knowing about, because it shows the platform politics are not settled. In February 2024, Apple confirmed it had removed Home Screen web app support in the EU in the iOS 17.4 beta, citing the Digital Markets Act's requirement to allow alternative browser engines. After developer backlash, an open letter from Open Web Advocacy to Tim Cook, and the European Commission signalling an investigation, Apple reversed course. Per TechCrunch reporting Apple's March 1, 2024 statement: "We have received requests to continue to offer support for Home Screen web apps in iOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU."

Current state: iOS PWA support exists and is improving, but lags Android. Android treats PWAs as first-class citizens with broad API support. iOS treats them as a limited subset of what the web can do. If your audience skews heavily iPhone and your feature list reaches into deep hardware, that gap is the single most important variable in this decision.

PWA advantages, honestly

PWA install prompt on a phone screen with offline cache and push notification icons

• Lower cost and one codebase. Agency benchmarks put PWAs at a fraction of dual-native cost. Figures vary widely and should be treated as estimates, not quotes. Use our USA custom development cost guide for ranges by scope.

• No app store approval, fees, or review delays. No 15 to 30% store commission and no resubmission for each release.

• Instant updates. Changes deploy like a website. No store review per release.

• Discoverable and linkable. Indexed by search engines, shareable via URL. This is exactly the discoverability advantage we cover in our Next.js vs WordPress SEO guide, and it carries straight through to PWAs.

• No install friction. No download required. Users land via a link and can install if they want to.

• Cross-platform by default and a much smaller storage footprint than native apps.

Classic case studies are useful as proof of concept, but they are old. Treat them as historical proof points, not current benchmarks:

• AliExpress (web.dev case study, last updated 2016): "AliExpress increases conversion rate for new users by 104%, 74% increase in time spent per session across all browsers." A 2016-era result.

• Pinterest (Addy Osmani via Google Dev Channel, late 2017): "Time spent is up by 40%, user-generated ad revenue is up 44%, and core engagements are up 60%." Separately, Pinterest Engineering's July 2018 retrospective: "new signups increased by 843 percent year-over-year" and "weekly active users on mobile web have increased 103 percent year-over-year." Do not conflate the two; the figures come from different documents and time points.

• Twitter Lite (web.dev): after adding the Add to Homescreen prompt, "Twitter has seen 250,000 unique daily users launch Twitter Lite from the homescreen 4 times a day, over 10M push notifications a day." The PWA "requires less than 3% of the device storage space compared to Twitter for Android."

• Starbucks (built by the agency Formidable, now Nearform): the PWA "ended up being 233KB, 99.84% smaller than the 148MB size of the original iOS mobile app." At Google I/O 2018 Starbucks said the PWA roughly doubled daily active web users. The 233KB/148MB figure is from the build agency, not Google.

• Tinder (Addy Osmani case study, 2017): the PWA MVP "took 3 months to implement" and delivered the core experience "in 10% of the data investment cost" of the native app.

PWA limitations, honestly (the iOS list)

• Limited device features on iOS. Apple's WebKit team, as reported by ZDNet on June 28, 2020, "declined to implement 16 new web technologies (Web APIs) in Safari because they posed a threat to user privacy by opening new avenues for user fingerprinting." The blocked list includes Web Bluetooth, Web MIDI, Web NFC, WebUSB, Web Serial, and the Battery Status API. PWAs on iPhone therefore cannot reach Bluetooth peripherals, NFC tags, or USB accessories.

• iOS background limits. No reliable background sync. A PWA cannot update content in the background, so users see what was cached when they last opened it.

• iOS storage caps and eviction. Per WebKit documentation, "the current Cache API quota is set to a fixed value of 50 MB per partition" on iOS mobile devices, and Safari may evict data after a period of disuse (a 7-day script-writable storage cap also applies).

• Manual install on iOS. No automatic install prompt. Users must use Share > Add to Home Screen, which most users do not know how to do without explicit guidance in your UI.

• No App Store presence. Cuts off the primary discovery channel for app-store searchers and makes app store monetization harder.

• Performance ceiling for graphics-heavy or compute-heavy apps.

• Push on iOS is more limited than Android. Home Screen install is required, opt-in rates are lower, and the API surface is narrower.

Native app advantages

• Best performance and responsiveness.

• Full device hardware and API access: camera, GPS, Bluetooth, NFC, biometrics, sensors, AR, background services.

• Best platform-native UX patterns (gestures, navigation, system integrations).

• App store presence: discoverability, credibility, and ratings or reviews as a trust signal.

• Reliable, rich push notifications across both platforms.

• Strong offline-first capability without storage caps.

• Best fit for graphics-heavy and compute-heavy apps: games, AR or VR, video editing.

• Built-in app store monetization: billing, subscriptions, refunds.

Native app disadvantages

• Higher cost. Two native codebases or a cross-platform build. Two fully separate native apps is the most expensive route.

• Longer time to market. Two builds, two QA passes, two store submissions.

• App store approval, rejections, and update friction. Each release goes through review. Users must update.

• App store commissions. Standard rate is 30%, with 15% available to small developers (under $1M per year) via Apple's App Store Small Business Program and Google Play's reduced tier. Google charges 15% on auto-renewing subscriptions from day one. Epic v. Apple forced Apple to allow US external payment links in 2025. A December 11, 2025 Ninth Circuit ruling (Epic v. Apple, No. 25-2935) held that "the district court used blunt force to ban all commissions, abusing its discretion," allowing Apple to charge a fee "based on the costs that are genuinely and reasonably necessary for its coordination of external links." Apple sought Supreme Court review in 2026. Verify current rates before counting on them.

• Install friction. comScore's 2017 US Mobile App Report (via TechCrunch, August 2017) found that "a majority of users (51%) still don't download any apps in a month." The figure is older and has been disputed by other measurement firms; treat it as directional.

• High uninstall and churn. Per AppsFlyer's App Uninstall Benchmarks Report (2025 edition), "more than 1 in every 2 apps that are installed are uninstalled within 30 days of being downloaded," with rates of 46.9% in 2023 and 46.1% in 2024 (Android only; iOS tracking is limited after iOS 15).

• Ongoing maintenance across OS versions and device fragmentation.

Cross-platform: the middle path most businesses should consider

For many businesses the real decision is PWA vs cross-platform, not PWA vs two native apps. React Native and Flutter give a near-native experience and app store presence from one codebase at materially lower cost than dual native (industry estimates often cite 30 to 50% savings vs separate native builds; treat as ranges). The split between them is honest:

• Flutter leads on UI consistency and animation performance via its own rendering engine. Best when the design language is custom, animation-heavy, or must look identical on both platforms.

• React Native wins on JavaScript and React talent availability and code sharing with web. Best when your team already runs React and you want one team across web, iOS, and Android.

Tradeoffs apply. Cross-platform can lag for graphics-heavy or deeply hardware-integrated apps, and you still ship through the app stores with their review and commission rules. If your roadmap leans on cutting-edge AR, low-level Bluetooth, or hardware accessory integrations, fully native is still safer. For most consumer apps that need store presence, cross-platform is the default we recommend through our app design and development team.

Head-to-head at a glance

Cost and time figures are estimates that vary widely by scope, region, and team. Use this as a decision starter, not a quote.

A decision framework that actually works

Choose a PWA when: you run a content, commerce, or service site; reach and discoverability matter; budget is limited; you need fast iteration; you want to cut install friction; and your features do not require deep native hardware. Many of the merchants we work with through our ecommerce industry team ship a PWA storefront as the primary mobile experience.

Choose native or cross-platform when: you need deep device features (Bluetooth, NFC, AR, biometrics); top performance (games, AR); strong app store presence and brand; reliable rich push; offline-heavy use; or app store in-app purchases as the core monetization model.

Run both deliberately, not by accident. Shipping a PWA first to validate demand cheaply, then building native to scale, is a coherent sequence. So is running a native app for engaged power users plus a PWA for reach and SEO. What is not coherent is shipping two fully separate native apps when a single cross-platform build or a PWA would have served. That is the most expensive avoidable mistake we see.

Checklist before you commit:

• Do you need Bluetooth, NFC, biometrics, or AR? If yes on iOS, PWA is a non-starter.

• Is your audience iPhone-heavy, and do you depend on background updates?

• Do you depend on app store discovery and ratings as the primary acquisition channel?

• How often do you need to iterate and ship changes?

• What is your realistic budget and timeline? Pair this with our SaaS validation playbook if you are pre-product-market-fit.

• Do you need in-app purchases or subscriptions as a billing path?

• Will the same team maintain it in a year? Two? Five?

The validation logic we walk through in our MVP vs full product strategy guide applies cleanly here: cheaper to ship a PWA MVP than to commit to two native codebases before you know the demand is real.

Common myths, corrected

• "PWAs can't do push on iOS." Outdated. They can since iOS 16.4 (March 2023), with the Home Screen install caveat.

• "Native is always better and faster." Not always worth the cost for content, commerce, and service apps. A well-built PWA can outperform a poorly built native app on the metrics that matter for those use cases.

• "You must be in the app store." It depends entirely on where your audience finds new apps. Web-discovery dominant businesses often do not need it.

• "PWAs are just websites." Undersells installable, offline-capable, push-capable apps that ship updates instantly and ignore the store commission.

• "Cross-platform always means worse performance." Modern React Native (with the new architecture) and Flutter (with Impeller) close most of the gap for typical consumer apps. The gap is real for games and AR, not for most commerce or content apps.

How Brandrums recommends choosing

Step 1: classify your app on the spectrum first. If it is content, commerce, booking, or a service portal with no exotic hardware needs, default to a PWA. If it needs Bluetooth, NFC, AR, biometrics, or must be a top-tier game, default to native or cross-platform.

Step 2: if unsure, ship a PWA MVP. It is the cheapest, fastest way to validate demand and capture web discoverability. Set a threshold up front: if the PWA hits your engagement and conversion targets but you run into a hard iOS limitation (you genuinely need NFC, reliable background sync, or deep AR), that is your signal to invest in native. The discipline is in writing that threshold down before you ship, not after.

Step 3: if you need app stores but not bleeding-edge hardware, pick cross-platform. React Native or Flutter buys you both stores from one codebase. Choose Flutter for graphics- and animation-heavy UI. Choose React Native if you have JavaScript or React talent or want to share code with web.

Step 4: plan for "both" deliberately. A native app for power users plus a PWA for reach and SEO is a coherent strategy. Maintaining two separate native apps when one cross-platform build would do is waste. Our WordPress vs custom build guide walks through the same "split the audience by job-to-be-done" logic on the web side.

Step 5: re-evaluate annually. iOS PWA capabilities and app store economics are still moving fast. iOS 16.4 push, iOS 26 default behaviour, and Epic v. Apple are all under three years old. Revisit the decision as the platform gap narrows.

A development partner who builds across the whole spectrum can keep this honest rather than steering you toward whatever they happen to build. For a longer look at how this overlaps with AI-assisted product work, see our AI agents in mobile apps 2026 guide and the cost framing in our GitHub Copilot token billing piece.

Key takeaways

• Treat PWA vs cross-platform vs native as a spectrum of tradeoffs. The right answer depends on hardware needs, audience platform mix, discovery channel, budget, and iteration speed.

• iOS PWAs got real in March 2023 (push) and got default treatment in iOS 26 (2025). They still lack Bluetooth, NFC, USB, and reliable background sync.

• For most businesses the real choice is PWA vs cross-platform. Two fully separate native apps is the most expensive avoidable mistake.

• Ship a PWA MVP if you are unsure. Set the threshold that would push you to native before you ship, not after.

• App store commission rules and Epic v. Apple are still in motion. Verify the current rate before basing a business model on it.

FAQ

Can PWAs send push notifications on iOS?

Yes, since iOS 16.4 in March 2023, but only when the site is added to the Home Screen and the permission prompt follows a direct user interaction. Web push does not work for sites left in a Safari tab.

Are PWAs as fast as native apps?

For content, commerce, and service apps, a well-built PWA can match or beat a poorly built native app on the metrics users actually feel (load, interaction, smoothness). For graphics-heavy or compute-heavy apps (games, AR, video editing), native still wins. The 2025 Core Web Vitals Technology Report we cite in our Next.js vs WordPress SEO guide is a useful starting point for measuring this honestly.

Should I build a PWA or a React Native app?

Default to a PWA if you do not need app store presence, do not need deep device hardware, and want fast iteration and SEO. Default to React Native (or Flutter) if you need to be in the App Store and Google Play, want native-feeling UX, and can absorb the higher build and review cost. If you are unsure, ship the PWA first.

Do PWAs work offline on iOS?

Yes, within limits. PWAs use service workers to cache assets and respond when the network is unavailable. On iOS, the Cache API quota is capped at 50 MB per partition and Safari may evict data after a period of disuse (a 7-day script-writable storage cap also applies). Plan your offline strategy around those limits.

How much cheaper is a PWA than two native apps?

Materially cheaper, but the exact number depends on scope, region, and team. Industry estimates often put PWAs at a fraction of dual-native cost. Treat published figures as ranges, not quotes, and benchmark against our USA custom development cost guide.

Will Apple eventually close the gap with Android on PWAs?

The trajectory says yes, slowly. iOS 16.4 added push, iOS 26 made web apps the default for Home Screen installs, Safari 18.4 added Declarative Web Push and Screen Wake Lock. The big API gaps (Web Bluetooth, NFC, USB, Web Serial) remain, mostly cited as privacy concerns. Re-evaluate annually rather than betting on a specific Apple roadmap.

Ready to scope the right path?

Most teams reach for native because that is what "a real app" means in their head, when a PWA or a cross-platform build would do the job for a fraction of the cost. We help clients figure out which path fits the actual roadmap before any code ships, through website development, app design and development, and digital marketing sequenced together. Tell us what your app has to do and we will recommend the lightest stack that fully does it. Or check our pricing options if you are sizing up an engagement.