# PWA vs native app: which should you build in 2026?

*By Roberto Lazar, founder of Dock30 · Published 2026-07-17 · Updated 2026-07-17 · 7 min read*

A 2026 decision guide to progressive web apps versus native: what a PWA can and cannot do on iOS and Android, the cost gap, and when native actually earns it.

Build a progressive web app when your product is content, commerce, dashboards, or internal tools, and you do not strictly need App Store distribution or deep device hardware. Build native (or React Native) when the app lives or dies on Bluetooth, NFC, reliable background processing, AR, biometrics, or being found in the store. That is the whole decision in one sentence: a PWA is the cheaper right answer for most business apps, and native needs a concrete reason behind it, not the other way around. In 2026 a PWA can install to the home screen, work offline, use the camera and GPS, and send push notifications. What it cannot do is mostly an iOS story, and that story is what this guide is about.

We build both at Dock30, web apps and mobile, so this is not a pitch for one side. It is the same conversation we have with clients most weeks, where the founder has already decided they need a native app and has not yet checked whether they do.

## The decision rule, before the details

Most of this comes down to two questions. What does your app actually need from the phone, and where do your users find you? If the honest answers are "a screen, a camera, and a login" and "we send them a link," a PWA covers it. If the answers involve talking to a hardware device over Bluetooth, running work while the app is closed, or being discovered by people browsing the App Store, you are drifting toward native.

Everything below is detail on where that line sits in 2026. The line moved over the last few years, mostly in the PWA's favor, but it did not move as far on iOS as the headlines suggest.

## What a PWA can do in 2026

A progressive web app is a website that installs. Once it is on the home screen it runs full-screen with no browser chrome, works offline through a service worker, and behaves like an app to the person using it. The capabilities that used to be native-only and now work on the web include camera and microphone access, geolocation, offline storage, and, with the caveats below, push notifications. For a product built around content, forms, dashboards, or commerce, that is the entire feature list.

The business case is not theoretical. Starbucks built a PWA that is [99.84% smaller than its native iOS app](https://www.mobiloud.com/blog/progressive-web-app-examples), 233KB against 148MB, and doubled its daily active web users, with web orders reaching near parity with the mobile app. Tinder's PWA came in at 2.8MB against 30MB or more for the native app, which put it within reach of users in markets where a large download is a real barrier. Twitter Lite ran on under 3% of the data of the native app and still saw more pages per session and a lower bounce rate. None of those companies lacked the budget for native. They chose the web app because for their job it worked, and it reached people the native app could not.

## What a PWA cannot do, and why iOS is the catch

This is the part that decides most projects, so it gets the most space.

On Android, PWAs are close to a full citizen. Chrome shows an install prompt, push notifications work without ceremony, storage is generous, and you can wrap the app and ship it to Google Play through a Trusted Web Activity. If Android were the whole market, the PWA-versus-native debate would be nearly over.

iOS is where it gets specific. Safari added push notification support in [iOS 16.4](https://www.magicbell.com/blog/pwa-ios-limitations-safari-support-complete-guide) back in March 2023, which closed the single biggest gap, but with conditions. Notifications only work after the user installs the app to the home screen, and there is no automatic install prompt to nudge them there. Apple does not support the `beforeinstallprompt` event, so the user has to know to tap Share, scroll to "Add to Home Screen," and confirm. Most people do not know that menu exists. And for users in the EU, Apple disabled home-screen web app push entirely on iOS 17.4 and later, part of its response to the Digital Markets Act.

The hardware and storage limits on iOS are firmer. A home-screen PWA on iOS has no access to Web Bluetooth, Web NFC, or Web USB, no reliable background sync, a storage cap around 50MB, and a cache that iOS can clear after roughly a week of the app going unopened. Camera, microphone, and location are fine. Talking to a Bluetooth scale, reading an NFC tag, or syncing data while the app is closed are not.

| Capability | Android PWA | iOS PWA (2026) | Native |
|---|---|---|---|
| Install to home screen | Yes, with prompt | Yes, manual only | Yes, via store |
| Push notifications | Yes | Yes, installed apps only, not in EU | Yes |
| Camera, mic, GPS | Yes | Yes | Yes |
| Bluetooth, NFC, USB | Partial | No | Yes |
| Reliable background work | Partial | No | Yes |
| App Store or Play listing | Yes, via Play | No store listing | Yes |
| Offline storage | Generous | ~50MB, cache can expire | Full |

The last row is easy to skip and often matters most. Apple has no equivalent to Android's Trusted Web Activity, so an iOS PWA never gets an App Store listing. No store search, no ratings, no category rankings, no appearing when someone browses for apps like yours. If a meaningful share of your users would find you by searching the store, a PWA cannot serve them, and no amount of engineering changes that.

## Native and React Native: what the extra money buys

Going native, or cross-platform with React Native, buys you the things the list above says no to: full hardware access on both platforms, dependable background processing, biometric login, AR, and a place in both stores. If your app's core value is one of those, the decision is made for you and the cost is just the price of doing the thing.

The nuance is that "native" rarely means writing Swift and Kotlin twice anymore. For most teams the practical native path is React Native, one TypeScript codebase for both stores, which gets you store distribution and hardware access without doubling the build. We wrote the full case for it in [React Native in 2026](/blog/react-native-2026). So the real spectrum is not PWA versus native, it is PWA, then cross-platform, then dual native, each step buying more device reach for more money. You want the leftmost option that still does the job.

## The cost gap, in plain numbers

The money is the reason this decision exists. A PWA typically runs [30 to 50% less than a single native app](https://www.instinctools.com/blog/pwa-vs-native-app/), and 60 to 70% less than building separate iOS and Android apps plus a web version, because it is one codebase doing the work of three. Maintenance follows the same logic: one codebase to patch when the OS changes, not two or three.

Put a shape on it. If a dual-platform native build lands somewhere north of EUR 70,000 at Western agency rates, the equivalent PWA often sits at a third to a half of that for the same user-facing features. The savings evaporate the moment you genuinely need Bluetooth or store presence, because then you are building native regardless and the comparison is moot. That is the trap to avoid: paying the native premium for an app that never uses anything native, which is more common than it should be. If you want the full breakdown of what drives an app's price either way, we did the math in [how much a mobile app costs in 2026](/blog/mobile-app-cost-2026).

## How we think about it at Dock30

The web app and the mobile app are often the same team's problem at Dock30, which is why we are relaxed about pointing people to the cheaper build. A PWA lives right at the overlap between our [websites and ecommerce work](/services/websites-ecommerce) and our [mobile app work](/services/mobile-apps), and half the time the installable web app is a better first version than the native app the client walked in asking for.

We built one called Caged as an installable web app rather than a native build. It installs to the home screen, runs full-screen, works offline, and does everything its users need without a single App Store review, which is exactly the profile where a PWA beats native: the value is in the content and the flow, not in the phone's radios. It shipped faster and cost less than the native equivalent would have, and if it ever earns a native app, the web codebase does not go to waste.

Pricing works the same as the rest of our work, and I would rather put it in writing than leave it vague. Fixed-scope projects start at **EUR 350**, and you get the exact price and the delivery date in writing before any work begins. We build from Romania, so Eastern European engineering rates land us well under US and Western European agency numbers for the same scope. For products that keep growing after launch there are monthly partnerships from EUR 1,000, and every launch includes 30 days of free support.

If you are staring at a native quote and quietly wondering whether you need all of it, that is the exact question worth 15 minutes. Book a [free call](https://calendly.com/dock30/15min) or reach us through the [contact page](/contact), tell us what the app has to do and where your users come from, and we will tell you honestly whether a PWA gets you there for less. If the answer is that you genuinely need native, you will hear that too, and we build that as well.

## Frequently asked questions

**Should I build a PWA or a native app in 2026?**

Build a progressive web app when your product is content, commerce, dashboards, or tools, and you do not strictly need App Store distribution or deep device hardware. Go native or cross-platform when the app depends on Bluetooth, NFC, reliable background processing, AR, or being found in the store. For most business apps the PWA is the cheaper right answer, and native needs a concrete reason behind it.

**Can a PWA send push notifications on iPhone?**

Yes, since iOS 16.4 in March 2023, but only after the user installs the app to the home screen through Safari's Share menu, and not at all for users in the EU on iOS 17.4 and later. On Android push notifications work without those caveats. If reliable notifications to every user are core to your product, that iOS gap is a real reason to consider native.

**How much cheaper is a PWA than a native app?**

A progressive web app usually costs 30 to 50% less than a single native app, and 60 to 70% less than building separate iOS and Android apps plus a web version, because it is one codebase serving all of them. Maintenance is cheaper for the same reason. The savings shrink the moment you need native-only hardware, because then you are building native anyway.

**What can a PWA not do compared to a native app?**

On iOS a PWA cannot use Bluetooth, NFC, USB, or reliable background sync, it is capped at roughly 50MB of storage, and its cache can be cleared after about a week of not being opened. It also never appears in the App Store, so you lose store search, ratings, and category rankings. Camera, microphone, and location all work fine.

**Do PWAs still appear in the App Store?**

On iOS, no. Apple has no equivalent to Android's Trusted Web Activity, so an iOS PWA installs only from the browser and never gets an App Store listing, rating, or search placement. On Android you can wrap a PWA and publish it to Google Play. If store discovery is a main acquisition channel for you, that is a point for native.

---

Written by Roberto Lazar, founder of Dock30. Book a call: https://dock30.com/contact