PWA, Native App, React Native or Flutter: Which Fits in 2026?
You have already decided that the business needs something on the phone. Now the proposals disagree: one says a PWA is enough, another insists on native, a third offers one codebase for both stores. Here is what each option can and cannot do as of November 2026, how the stores change the sums, what a second codebase costs to keep alive, and how to decide by the one thing your product cannot do without.
IN SHORT
Which one to choose
Choose by the hardest thing your product has to do on the phone. A PWA fits content, catalogs and occasional orders, as long as iPhone users can be asked to install it before push works. React Native or Flutter fits when you need both stores and the two platforms share most screens. Native Swift and Kotlin fits when the core flow depends on background location, Bluetooth or other deep device work. Then budget for the years after launch, because that is where these options differ most.
Our article When Does a Business Actually Need a Mobile App? deals with the earlier question: whether a business needs an app at all, judged by who uses it and how often. This one starts where that article ends. You have a real reason to be on the phone, and you need to know which technology should carry it.
We build apps in Swift, Kotlin and React Native, and we run a PWA on our own site. Flutter developers are in our pool too, and we use it for an MVP when the product calls for it, but we have no published Flutter case, so what we say about it comes from its documentation.
Choose by the hardest thing the phone has to do.
FOUR OPTIONS
What each one really is
A PWA (progressive web app) is your website with two additions: a manifest file that lets the phone install it with its own icon and window, and usually a service worker, a small script that sits between the page and the network, keeps working without a connection and receives push messages. There is no store and no review, so whatever you deploy is live on the next visit.
A native app is written twice, in Swift for iOS and in Kotlin for Android. Each version gets new system features first, and you keep two codebases and two release tracks in step.
React Native is one codebase in JavaScript or TypeScript. At runtime it creates real Android and iOS views for your components, so a list or a text field is the platform's own (React Native documentation).
Flutter is one codebase in Dart, and it takes the opposite route. It bypasses the system's interface libraries and paints the screen with its own widgets through Impeller, a renderer shipped inside the app (Flutter documentation).
Some proposals also call your website in a thin native shell an "app". We come back to that under the stores.
PWA IN 2026
What a PWA can do now
Push works on iPhones, under conditions. Since iOS and iPadOS 16.4, a web app added to the Home Screen can ask for permission to send notifications. The request has to follow a direct action such as a tap on a subscribe button, and a site open in a normal Safari tab cannot ask at all. The same release added numbers on the app icon. You do not need an Apple Developer membership for this, and delivery runs on the same Apple Push Notification service as native apps (WebKit, February 2023). On Android, Chrome supports the Push API in the browser (Can I use, November 2026), with no install needed.
The real obstacle is the install step. iOS does not support beforeinstallprompt, the event a site uses for its own Install button, so the person has to find Add to Home Screen in the Share menu (MDN). Since iOS 26 every site added this way opens as a web app by default, even without a manifest (WebKit, September 2025). How many of your customers will take those steps is something you can only measure.
So the share of iPhones in your market matters. In the United States iOS held 51.96% of mobile operating system share in October 2026 and Android 48.02% (StatCounter). On about half of American phones, then, a push strategy built on a PWA starts with a manual install. Your own analytics may show a different split, so check them too.
On an iPhone, web push begins only after the install.
Storage is no longer the weak spot. Since Safari 17 a site can use up to 60% of the disk in the browser, and Home Screen web apps get the same quota (WebKit, August 2023). Chrome also allows an origin up to 60%, and Firefox up to 2 GB per site group (web.dev). The risk is deletion. Safari removes script-writable storage, service worker data included, after seven days of Safari use without interaction on the site, while Home Screen web apps keep their own counter of days of use (WebKit, March 2020).
In practice, offline reading and a saved cart hold up well on an installed PWA. We would not keep unsynced warehouse orders on one, because Background Sync, the API that finishes an upload after the page closes, is not supported in Safari on iOS or in Firefox (Can I use, November 2026).
The hard limits as of November 2026:
- Background location. The W3C Geolocation draft of 30 October 2026 says position updates are "exclusively for fully-active visible documents", so tracking stops when the page is hidden.
- Bluetooth and NFC. Web Bluetooth works in Chrome on Android and desktop, Web NFC is marked as supported in Chrome for Android, and neither works in Safari on iOS (Can I use).
- Camera. Taking photos and video through getUserMedia has been widely available since 2017, while the built-in Barcode Detection API is still experimental (MDN), so a scanner usually means a JavaScript library.
Europe stays on the same footing. Apple planned to drop Home Screen web apps in the EU in early 2024, then said in March that it "will continue to offer the existing Home Screen web apps capability in the EU", on WebKit (TechCrunch quoting Apple). We found nothing newer that changes this.
OUR OWN PWA
What running one taught us
Our own site is an installable PWA, so we can describe the mechanics from the inside. Pages always come from the network, so the text is fresh; the last 30 pages a reader opened are kept, and without a connection the reader gets the saved copy or a small offline page.
New articles go out as a weekly push: one notification per device, in the language the person subscribed in, covering what appeared since the last digest. A language with no new articles sends nothing that week. On an installed app the icon shows how many articles are new, the service worker keeps the count, and opening any page clears it.
The subscribe block sits at the end of articles and on the blog, never as a pop-up, and only where the browser supports notifications and has not blocked them. On an iPhone the permission request has to come inside the tap itself, so our button asks first and does everything else afterwards.
One bug is worth retelling. We registered the service worker on page load, the usual way. Then PageSpeed started failing on every page with "Browser tab has unexpectedly crashed". We tested static copies of an article in PageSpeed, cutting parts away until the crash stopped. Our host answers 403 to the HeadlessChrome user agent, and the worker script is requested with the browser's own user agent, so the test browser could not fetch it. Now the worker registers on the visitor's first tap, click or key press, or on load only when a worker already controls the page. Visitors see no difference. More of what speed tests taught us on a heavy page is in 3D on a Live Site.
Ours is a content site with no orders in the PWA. It shows that install, offline reading and push can be added to an existing website without a store or a second codebase, and it says nothing about whether customers would reorder dinner through one.
THE STORES
What the stores add
A store gives you presence and a familiar install, and it brings two companies' rules with it. We checked these figures in November 2026; they change often, so reread them before you budget.
| Rule | Apple App Store | Google Play |
|---|---|---|
| Account | $99 a year | $25 once |
| Digital goods and subscriptions | In-app purchase required; 15% commission in the Small Business Program, for developers new to the store or with up to $1 million in yearly proceeds | US users, since 30 June 2026: 10% plus a 5% billing fee on the first $1 million of yearly earnings. Above that, subscriptions stay at 10% plus 5%, other sales pay 20% or 25% plus 5%, depending on when the user installed |
| Physical goods and services | In-app purchase may not be used: Apple Pay or card entry instead | Play billing may not be used; food delivery and event tickets are named as examples |
| Review time | At least 50% of submissions in under 24 hours, 90% in under 48 | We plan for a few hours to several days |
| Entry hurdle | A company enrolls as a legal entity with a D-U-N-S number | Personal accounts created after 13 November 2023 run a closed test: 12 testers, 14 consecutive days |
| Account deletion | Required inside the app | An in-app path and a web link |
A food order, a table booking or a parcel pays no store commission at all, only your payment provider's fee, so a business selling physical things should not choose a PWA to save on commissions. A digital subscription or paid content is another matter, and there the channel changes your margin. In the US storefront an app may also link out to your own checkout for digital goods; Apple's other storefronts restrict that (Guidelines, 3.1.1).
Apple's guideline 4.2 asks for an app that is more than a "repackaged website", so a Capacitor shell has to bring real device features or useful native screens to pass. On Android the path is officially supported: a Trusted Web Activity opens your PWA full screen in Chrome, ownership is proved with Digital Asset Links, and Bubblewrap generates the Android project for you (Chrome for Developers). Once listed, it follows Play's payment rules.
In the EU, notarized iOS apps can also be installed from alternative marketplaces or a developer's website. Since 1 October 2026 such distribution carries a 5% Core Technology Commission on digital sales (Apple).
ONE CODEBASE
How far one codebase goes
| Question | React Native | Flutter |
|---|---|---|
| Language | JavaScript or TypeScript | Dart |
| What draws the screen | The platform's own views | Flutter's own widgets, through a renderer inside the app |
| Release rhythm | A new minor version about every two months; the latest 3 series are maintained | A stable release about every three months |
| When platform code is needed | APIs that neither React Native nor a library covers: a Turbo Native Module | APIs outside Dart: platform channels to Kotlin or Java and Swift or Objective-C |
| Fits best | Teams working in JavaScript or TypeScript, for example next to a React website | Teams ready to own Dart, and interfaces meant to look the same on both platforms |
| With us | App projects and specialists | MVPs and specialists from our pool |
One codebase removes much of the duplicate work on screens and business logic. It does not remove the platform work: signing and store builds, permissions, push setup and testing on both systems stay double in every case.
React Native 0.88 came out on 15 October 2026, with 0.89 scheduled for December, and only the latest three series are maintained. At that pace a version leaves support roughly six months after release. A project that skips upgrades for a year then faces a jump across several versions.
We recommend React Native when both platforms share the same screens and logic: catalog, ordering, accounts, booking. Our own app projects run on native code or React Native; Flutter we use for MVPs and for apps already written in it. If a proposal includes it, ask who will maintain the code in three years and how easily you can hire Dart developers. When your app already exists and you only need people to work on it, that is a different format: hire mobile app developers, at $45 to $65 an hour, under your lead.
DECISION TABLE
Decide by what the product needs
| The product needs | PWA | React Native or Flutter | Native Swift and Kotlin |
|---|---|---|---|
| Push on iPhones | Only after a manual install | Yes, after permission | Yes, after permission |
| Camera and scanning | Photos and video; scanning through a JavaScript library | Yes, through libraries | Direct access |
| Bluetooth or NFC | Chrome on Android only | Through a library or native module | Direct access |
| Background location | No | Through native code | Direct access |
| Offline reading and a saved cart | Yes, best when installed | Yes | Yes |
| Offline work that syncs later | Weak on iPhone | Yes, with a local database | Yes, with a local database |
| Physical goods | Your payment provider, no store fee | Apple Pay or cards, no store fee | Apple Pay or cards, no store fee |
| Digital goods | Your own checkout, no store fee | In-app purchase and its commission | In-app purchase and its commission |
| Store presence | Google Play through a wrapper; App Store no | Both | Both |
| A fix reaches users | On the next visit | After review and an update | After review and an update |
| Codebases to maintain | One, shared with the site | One, plus platform work | Two |
Read it from the top and stop at the first row your product cannot live without. An employee app that tracks routes in the background rules out the PWA on one line. A catalog with occasional orders rarely has such a line, and a PWA or a good website usually serves it.
One case needs a closer look: Apple Pay inside an installed web app. We found no clear statement in Apple's or WebKit's documentation, so test it on a real iPhone with your payment provider before you promise it.
SECOND CODEBASE
What upkeep really costs
What separates these options over five years is the list of duties that never stops:
| Recurring duty | PWA | React Native or Flutter | Native |
|---|---|---|---|
| Yearly store SDK deadline | None | One project, two stores | Two projects, two stores |
| Framework upgrades | Those of your website | Every few months, on a fixed rhythm | Libraries on each platform |
| Signing keys and store accounts | None | Both stores | Both stores |
| Old versions in the field | None: everyone gets the current one | The API must keep serving them | The API must keep serving them |
| A new feature | Built once | Built once, plus platform work | Built twice and released twice |
The deadlines are concrete. Since 28 April 2026 anything uploaded to App Store Connect must be built with Xcode 26 and an iOS 26 SDK or later, and since 9 September 2026 it must target iOS 13 or later (Apple). Since 31 August 2026 new apps and updates on Google Play must target Android 16, API level 36. Existing apps had to reach API level 35 by the same date, with an extension to 1 November on request, or they stop being discoverable to users on newer Android versions (Google). An app that nobody updates eventually cannot ship even a small fix.
A finished app keeps aging while nobody touches it.
Our clearest example is LavShash. We built a restaurant site, a gastro market and native iOS and Android delivery apps as one system. Then the client's plans changed and the launch was put on hold. Five years on the system would need substantial rework before a relaunch, because platforms, store requirements and customer habits have all moved. The apps were finished; time alone created the work.
We do not quote a universal percentage for upkeep, because we have no reliable source for one and the work differs from product to product. Ask any contractor to write the yearly duties above into the proposal with hours next to them. With an outstaffed mobile developer at $45 to $65 an hour you can price that list yourself. Store accounts, signing credentials and the recovery email also need a named owner, as our digital ownership audit explains; most often the accounts belong to the client, and we publish under them.
HOW WE DECIDE
How we make the call
We write native apps in Swift and Kotlin and cross-platform apps in React Native, and neither is our default. Two of our projects show how differently the choice can go.
At LavShash, delivery got native iOS and Android apps while the restaurant and the market stayed on the web, because the repeated action of ordering dinner again is what earns a place on a phone. The reasoning is laid out in Restaurant, Online Store and Delivery: One System or Three Products?. At MEDPRESSO, a continuing medical education platform, the content, certification logic and accounts already lived in the platform, so the app, built and ready for release, is a more convenient interface for doctors between shifts and has no data of its own.
The order of work we suggest:
- Write down the hardest requirement in one sentence, then find its row in the table above.
- Test the behavior before the platform. If the doubt is whether customers will come back, a PWA or a small first version answers it for less. An MVP is the cost of entry, and install and notification rates from a PWA are real evidence.
- Keep the logic behind an API. The catalog, orders, accounts and admin panel stay on the server, so a PWA can later gain a native app beside it without a second system. A new product of this kind falls under web application development, from $25,000; adding a PWA to an existing site has no separate price line, since it depends on the site.
- Choose in discovery, with the reasons on paper. Our discovery phase takes two to four weeks, costs from $4,000, and gives you a clickable prototype, the choice between native and React Native with its reasons, and an estimate.
- Budget the whole system. Mobile app development starts from $30,000 and a full app usually takes 10 to 20 weeks; platforms, screens, integrations and the back end move the price. We build the design, back end, admin panel and apps ourselves around your business logic, and the code is handed over to you under the contract.
The earliest step is a strategic session: two to three hours with the founder, prepared in advance, for $500, credited toward the project within 30 days.
FAQ
Frequently asked questions
Can a PWA send push notifications on an iPhone?
Yes, since iOS and iPadOS 16.4, but only after the person adds it to the Home Screen, and the permission request must follow a tap. A site open in a normal Safari tab cannot ask. On Android, push works in the browser without an install.
Can a PWA be listed in the App Store or Google Play?
On Google Play, yes, through a Trusted Web Activity, and Play's payment rules then apply. For the App Store a wrapped website has to pass guideline 4.2, which asks for more than a repackaged website, so it needs real native value.
React Native or Flutter: which should a business choose?
Both give one codebase for two platforms. React Native uses the platform's own views and JavaScript or TypeScript; Flutter draws its own widgets and uses Dart. Our app projects use React Native, and we bring Flutter developers to MVPs and existing Flutter apps; either way, ask who will maintain what you choose.
Do the stores take a commission on food orders or physical goods?
No. Apple requires a method other than in-app purchase for physical goods and services used outside the app, and Google Play billing may not be used for them. You pay only your payment provider. Commissions apply to digital goods and subscriptions.
Can we start with a PWA and add a native app later?
Yes, if the business logic sits behind an API from the start. The catalog, accounts, orders and admin panel stay where they are, and the app becomes one more interface. What you redo is the interface layer, and you gain the store duties.
How much does each option cost with Peretz Agency?
Native or React Native apps start from $30,000 and usually take 10 to 20 weeks. A new web application starts from $25,000. A mobile developer inside your team costs $45 to $65 an hour. All our prices are on our pricing page.
Sources
- WebKit: Web Push for Web Apps on iOS and iPadOS (February 2023)
- WebKit: Updates to Storage Policy (August 2023)
- Can I use: Push API, Background Sync, Web Bluetooth, Web NFC
- Apple: App Store Review Guidelines
- Google Play: Service fees
Proposals disagree on PWA, native or cross-platform? Let's look at what your product needs from the phone.
- Share
-
-
-
-
One notification a week with the new PERETZ articles. Nothing else.
