The question arrives as a feature request and lands as a budget decision. Somebody asks, in a demo or a support email, whether there is an app, and saying yes commits you to a second codebase, an annual fee, and a release process you no longer control.
Web app versus native app comes down to one trade. A native rebuild buys an App Store submission path and deep device access, and it costs a second codebase plus $99 a year to Apple. Android also lets a packaged PWA reach Google Play through a Trusted Web Activity. Purchase methods on iPhone depend on the storefront, app category, and current Apple rule. Most working web apps do not need a rebuild.
There are four honest ways to get a web app onto phones, and this page does not cover how to take any of them. It covers whether the extra work buys you anything. Every ranking page for web based app vs native is written for someone choosing a stack on day zero. You already have a product and users.
Two notes on method. Every rule quoted below comes from Apple’s or Google’s own published pages, read on 15 August 2026; where a page carries no date, that absence is stated rather than papered over. And the vocabulary here is deliberate. AxonBuild’s record of public posts by people building on AI builders held 1,283 rows carrying a quoted post on 15 August 2026, counted that day with a case-insensitive search across each row’s quote and its two annotation fields, why_relevant and next_action. The App Store, Play Store, TestFlight or App Store Connect are named in 50 rows. “PWA” or “progressive web app” appears in 1. “Hybrid” appears in 0. Founders talk about the store, not the taxonomy, so this page leads with consequences.
What going native actually buys you
Native is easier to judge as a set of purchases than as a set of properties. It gives you a direct submission path to both stores. A PWA has no direct App Store route, while Android can package one inside an app using a Trusted Web Activity. Native also provides deep device access, including background location, Bluetooth peripherals, and health and fitness APIs. It provides Apple’s in-app purchase plumbing where the applicable storefront and app category require it. It can also create the perception of a real product, which is why the question gets asked at all.
Now the bill. You take on a second codebase that has to stay in step with the first. You pay Apple $99 a year and Google $25 once. Somebody has to produce and sign a build, a different job from deploying a website. And every release goes into a review queue run by a stranger.
That last cost is the one founders underestimate. One row in AxonBuild’s corpus of founder posts describes a React Native MVP that took 4 hours to build and 3 weeks to get approved on Apple’s and Google’s stores. The building was never the slow part.
Speed is not on the list of things native buys you either. A web app that feels slow on a phone is usually a web app whose loading and interaction numbers need work, which is a different job from a rebuild and a much cheaper one.
If the toolchain is the blocker rather than the queue, the two practical follow-ups are getting an iOS build to testers without a Mac and the two bills a native launch carries. Both fees are sourced in the store-rules section below.
What is a native app, exactly?
A native app is software written against one platform’s own toolkit and compiled into a package that platform installs. On iPhone that means Swift or Objective-C on Apple’s frameworks; native app iOS work and native Android app work are two separate builds in two separate languages. Three already on your phone: the Camera app, Maps, and Phone.
“Native” in software means built for one platform rather than translated onto it. Worth saying plainly, because the word has been borrowed: in those same 1,283 rows, “native” as a whole word (the search was the regular expression \bnative\b) appears in 15, and 7 of those say “AI-native”, a marketing adjective about software architecture with nothing to do with phones.
Android development native usually means Kotlin or Java against the Android SDK. Both platforms give a native mobile app the fullest access to the device and a direct route to the platform’s store listing and install experience. Android also supports a separate route that packages a verified PWA in an Android app through a Trusted Web Activity. The downside of fully native development is that you now maintain two of everything, or pick a cross-platform framework, which is the hybrid section below.
Progressive web app vs native: what the cheap middle already does
MDN defines a progressive web app as “an app that’s built using web platform technologies, but that provides a user experience like that of a platform-specific app”. It is your existing web app, with a manifest and a service worker, installed onto the home screen. The codebase is the one you already have.
What an installable web app gives you today:
- A home-screen icon that opens without browser furniture.
- Offline behaviour for the parts you cache.
- Push notifications on iPhone. WebKit’s announcement that shipped this said Apple was “adding support for Web Push to Home Screen web apps” in iOS and iPadOS 16.4. Two conditions attach: the web app has to be on the Home Screen, and the permission request has to follow a direct user action such as tapping a subscribe button.
What it does not give you:
- A listing in the App Store. There is no route. That is the whole asymmetry, and it has its own section below.
- An automatic install prompt in Safari. The event browsers use to offer installation on Android is marked by MDN as non-standard and experimental, and “not Baseline because it does not work in some of the most widely-used browsers”. On iPhone the user installs it themselves; Apple documents the path in its own iPhone User Guide under turning a website into an app in Safari.
The advantages of a progressive web app are real and boring: one codebase, no review queue, no annual fee, and a deploy that takes as long as your normal deploy. The benefits of a progressive web app stop where a store listing starts.
Founders do build this way. From the same 1,283 rows, one builder described their product in a single breath: “I built a full production SaaS app, GPS time tracking, Stripe billing, AI chat, automated emails, PWA install, security hardening, using nothing but Bolt.new.” PWA install sits between automated emails and security hardening, one more thing shipped rather than a strategy.
Is a PWA still relevant in 2026?
Yes, and Apple settled the argument itself. It planned to remove Home Screen web apps in the EU, then reversed after being asked to keep them.
Apple’s page on the Digital Markets Act, still live on 15 August 2026, says: “We have received requests to continue to offer support for Home Screen web apps in iOS and iPadOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU.” The page ties the return of the functionality to iOS and iPadOS 17.4. A capability the platform owner tried to drop and then kept under pressure is not one on its way out.
Hybrid mobile apps: one codebase, two store listings
Microsoft’s .NET MAUI documentation gives the cleanest vendor-neutral definition of hybrid app development: hybrid apps are “a blend of both native and web solutions” where “the core UI of the app is written using web technologies such as HTML, CSS, and JavaScript,” then wrapped in a lightweight native container that reaches the camera, calendar, and push notifications a web app cannot. That page was last updated 14 February 2025.
Founders meet two very different things under that one word.
The first is a shell around the web app you already have. Your site runs inside a native container, you submit the container, and the code you maintain does not change. Cheap, fast, and the shape most at risk from the store rules below.
The second is a cross-platform framework such as React Native or Flutter, where you write one codebase that compiles to real native UI on both platforms. More work than a shell, less than two native rebuilds, and the thing tools like Expo actually emit.
One warning, and it is the one the wrapper vendors leave off the pricing page. A thin shell over a website is precisely what Apple’s minimum functionality rule rejects, and Google conditions on whether you own the site being wrapped. MobiLoud, Median, Progressier, CatDoes, Despia, Code2Native and a rotating cast of others all offer to turn your URL into a store listing for a monthly fee. The tools work. The submission is where it goes wrong, and what a guideline 4.2 rejection actually says is worth reading before you pay anyone.
The store rules that decide this for you
Every option, against what each store operator has published. Apple’s text comes from the App Store Review Guidelines and Google’s from the Play Console policy pages, all rechecked on 17 August 2026. Apple’s guidelines show Last Updated: June 8, 2026. Android’s Trusted Web Activity page shows 26 February 2026. The Google Play policy pages cited in the table do not show a visible update date.
| Option | What Apple’s published rules do to it | What Google Play’s published rules do to it |
|---|---|---|
| Stay a web app | Out of the App Store by definition. No review, no fee, no listing. | A web URL by itself has no Play Store listing. The packaged Trusted Web Activity route is in the next row. |
| Installable PWA | No route to a listing. Apple documents Home Screen web apps as a Safari capability, not a submission path. | A documented route. Android’s docs describe a Trusted Web Activity as a way to open “your Progressive Web App (PWA) from your Android app”, verified with Digital Asset Links. |
| Hybrid shell over your web code | Guideline 4.2: an app “should include features, content, and UI that elevate it beyond a repackaged website”. Guideline 4.2.2: apps “shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links”. | Allowed if the site is yours. The Webviews and Affiliate Spam policy: “We don’t allow apps whose primary purpose is to drive affiliate traffic to a website or provide a webview of a website without permission from the website owner or administrator.” |
| Native rebuild | Accepted on its merits. The applicable purchase rule depends on what is sold, the storefront, the app category, and any entitlement. | Accepted on its merits, against the Functionality policy: “Apps should provide a stable, responsive, and engaging user experience.” |
Google publishes a supported route for putting a progressive web app in the Play Store. Apple publishes the opposite rule.
That asymmetry decides more of this question than performance, cost, or offline support combined. Google’s Android developer documentation on Trusted Web Activities, last updated 26 February 2026, describes a Trusted Web Activity as a way to open your own Progressive Web App from your own Android app, with the relationship between app and site “verified using Digital Asset Links”. The web.dev article on using a PWA in your Android app, last updated 19 March 2020, adds the two conditions: the web content “must meet the PWA installability criteria”, and the pairing is proved by serving an assetlinks.json file from your own domain. Apple’s guidelines run the other way. Guideline 4.2 asks for features that “elevate it beyond a repackaged website”, which is a direct instruction not to submit the website. So the same progressive web app can become a real Play Store listing and cannot become an App Store listing without becoming something more than the site.
Two more clauses matter before you sign anything.
Guideline 4.2.6 catches founders who pay someone else to submit. Apple’s text: apps “created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients …” If a conversion vendor offers to publish under their developer account, that offer is the rejection.
Guideline 3.1.1 gives the base rule for digital features and content: “If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality …” The next clauses qualify that rule. Guideline 3.1.1(a) says United States storefront apps do not need an entitlement to include buttons or links to other purchase methods, and it describes external-purchase entitlements for specific regions. Guideline 3.1.3 lists category exceptions including reader apps, enterprise services, person-to-person services, physical goods or services, and free companion apps. Your Stripe checkout works fine on the web. Inside an iPhone app, the permitted path depends on the current storefront, entitlement, and app category.
The money, in full: $0 to stay a web app, a “US$25 one-time registration fee” to open a Google Play developer account, “99 USD (or in local currency where available) per membership year” for the Apple Developer Program, and whatever a second codebase costs you in time. Prices checked 15 August 2026.
Which one fits you?
Five questions decide it, not a feature comparison. Answer no to all five and you already have the right thing: a web app. Deep device access can justify a rebuild. Charging inside an iPhone app first requires checking the current storefront, entitlement, and app-category rules.
Native or web app turns on consequences you can check today. Only one of the five is about how the app feels.
- 01 Do you need to charge for digital access inside the app? If yes and the app is on iPhone, check the current storefront, app category, and applicable entitlement before choosing in-app purchase or an external purchase link. Staying on the web keeps your existing payment setup intact.
- 02 Do you need push on iPhone? A Home Screen web app can do it since iOS 16.4, with the two conditions above, so this is no longer a reason to go native on its own.
- 03 Do you need a listing people find by searching the store? A web URL alone cannot give you one. On Android a PWA can reach Google Play through an Android app using a Trusted Web Activity. On iOS you need a native or hybrid submission.
- 04 Do you need the camera in the background, Bluetooth peripherals, background location, or health data? If yes, you are past what the web platform reaches, and the shell options get thin here too.
- 05 Who signs the release next year? A store release needs an account somebody owns, a signing identity somebody holds, and a person who can answer a reviewer. If that person does not exist, a second codebase buys a maintenance problem.
The verdicts:
| Your answers | What fits |
|---|---|
| No to all five | Stay a web app. Nothing here is worth a second codebase. |
| Yes to 2 only | Install a PWA. Your codebase plus a manifest and a service worker. |
| Yes to 3, Android matters most | PWA plus a Trusted Web Activity. A real Play Store listing, no second codebase. |
| Yes to 3, iOS matters most | A hybrid build with genuine native behaviour, not a wrapper around the URL. |
| Yes to 4, or yes to 1 after the current purchase rules require an in-app flow | A native or cross-platform rebuild. The only answer that earns the bill. |
If the web app came out of an AI builder, one more thing sits between you and the bottom two rows: what Lovable, Base44 or Replit specifically ships is each its own question, and the answer decides whether a rebuild starts from exported code or from nothing.
Web based app vs native app has never been a question about quality. It is whether an App Store listing, a packaged Google Play route, deep device access, or the purchase flow allowed for your storefront is worth a second thing to maintain. For a founder whose web app already has users, the answer is usually no. When it is yes, what it costs to hire someone to build the native version is the next number to get.
One thing this page cannot tell you: whether your users asking “is there an app?” actually mean “I want a store listing” or just “I want an icon on my home screen.” Those are very different bills, and the only way to find out is to ask three of them.
Common questions before you build a second version
Can I publish a PWA to the App Store?
Not as a PWA. Apple publishes no submission route for a progressive web app, and guideline 4.2 asks for “features, content, and UI that elevate it beyond a repackaged website”, a direct instruction against submitting the site itself. What can go to the App Store is a native or hybrid app that reuses your web code and adds real app behaviour on top of it.
How do I convert my PWA to an iOS app?
You wrap it in a native container and add enough genuine app behaviour to clear guideline 4.2, or you rebuild the parts that matter in a cross-platform framework. The step-by-step for each route, including what the conversion tools charge and which ones get rejected, is a separate subject; this page is only about whether to bother.
Can I put a PWA on Google Play?
Yes, through a Trusted Web Activity. Google’s Android developer documentation, last updated 26 February 2026, describes it as a way to open your own Progressive Web App from your own Android app, with the relationship verified using Digital Asset Links. The web content has to meet the PWA installability criteria, and you prove ownership by serving an assetlinks.json file from your domain.
Do I need a Mac to ship a native app?
Not always. Hosted build services compile and sign an iOS binary in the cloud, which covers the founder with no Mac and no Xcode. The Apple Developer Program membership is still required at $99 a year, and someone still has to own the account and answer App Review.
Is a hybrid app worse than a native app?
Not inherently. A hybrid app built on a cross-platform framework produces real native UI and passes review on its merits. A thin shell around your existing website is a different thing wearing the same word, and that one runs straight into Apple’s minimum functionality rule and Google’s requirement that you own the site.
Will Apple reject my app just because it is a website in a wrapper?
Apple’s published rule does not say “wrapper”, it asks for features, content and UI beyond a repackaged website. A shell that adds nothing meets that description, while one that adds offline behaviour, native navigation, notifications and device features the site cannot reach is arguing a different case. Which wrapper routes exist, what each costs, and whose developer account submits them belongs on the page about getting a web app onto phones, which is where the guideline-by-guideline version lives.
Your builder got the app working. Can it keep working?
When more people rely on it, AxonBuild fixes broken workflows, finishes stuck features, and keeps releases moving without replacing what already works.
