Web Apps vs Native Apps
What the differences are, why fast food chains build what they build, and how to decide for your own product.
After this lesson you can explain
- What changes when an app moves from a URL to Google Play or the App Store: deployment, review, updates, and who can take it down.
- Why the 15–30% store cut hits digital goods but not food, and how fast food chains build around that.
- Where the middle ground (PWA, TWA, hybrid wrapper, cross-platform framework) sits between a website and a fully native app.
1. The core distinction
A web app runs in the browser. You host it on a server, users reach it through a URL, and you control everything about how it deploys and updates. This site, endpoint51.com, is exactly this model.
A native app (the kind on Google Play or Apple's App Store) is installed on the user's device. It is packaged, signed, reviewed by the store, and updated on the user's schedule, not yours.
2. Key differences at a glance
| Web app | Google Play / App Store app | |
|---|---|---|
| Deployment | Push to server; everyone gets the new version instantly | Upload to store, pass review (hours to days), users update whenever their device does |
| Gatekeeper | None. Nobody can reject or remove your site | Google/Apple review every release and can remove your app. Play requires a $25 one-time fee; Apple charges $99/year |
| Payments (digital goods) | Stripe or similar, roughly 3% per transaction | Store billing by default, with a 15–30% cut; court and regulator pressure is opening external-payment exceptions (covered in Payments in Apps) |
| Payments (physical goods) | Your own processor, ~3% | Also your own processor, ~3%. The store cut does not apply to physical goods like food |
| Push notifications | Limited and patchy on mobile, historically weak on iOS | Reliable, first-class |
| Device access | Narrow, permission-gated (some location, camera, storage) | Deep: sensors, Bluetooth, background work, file system, offline by default |
| Presence | A tab or bookmark | Home-screen icon; much stronger habit and re-engagement loop |
| Codebase | One codebase (HTML/CSS/JS + backend) for every platform | Kotlin/Java for Android, Swift for iOS, or a cross-platform framework (Flutter, React Native) covering both |
| Discovery | Search engines, links, SEO | Store search and rankings, a separate and very competitive game |
| Versioning | Everyone is always on the latest version | You always have users on old versions you must keep supporting |
Play Store note for solo developers: new personal Google Play accounts must run a closed test with 12+ testers before publishing publicly. This trips up a lot of independent developers, so budget time for it if you ever go that route.
3. The middle ground: PWAs and wrappers
There is a spectrum between the two extremes, and it matters because it lets a web codebase reach the app stores.
Progressive Web App (PWA)
A web app with a manifest and service worker so it can be "installed" to the home screen, work offline, and (on Android) send push notifications. No store involved, no review, no fee. iOS support has improved but still lags Android.
TWA (Trusted Web Activity)
A thin Android shell around your live website, published on Google Play. The store listing is real; the content is your site. Cheapest way to get a web product onto Play. Google's billing rules and quality bars still apply to what is inside.
Hybrid wrappers (Capacitor, Cordova)
Your web code ships inside a native container with plugin access to device features. More capable than a TWA, still one codebase. Good for teams with web skills who need modest native features.
Cross-platform native (Flutter, React Native)
One codebase compiled to genuinely native apps for both Android and iOS. Not web tech at runtime (Flutter uses Dart, React Native renders native widgets). This is what most mid-size and large consumer apps use today.
4. What fast food takeaways use, and why
Big chains (McDonald's, Burger King, Domino's, KFC) almost all run native store-distributed apps, usually built with a cross-platform framework, plus a web ordering site alongside. The reasoning maps directly onto the table above:
- Push notifications are the business model. "20% off today only" and loyalty nudges need reliable native push. This alone justifies the native app.
- Loyalty and habit. The home-screen icon, saved usual order, and points balance drive reorder frequency in a way a browser bookmark never will.
- The store tax does not hit them. Food is a physical good, so the 15–30% store cut on digital purchases does not apply. They process payments with their own provider (Stripe, Adyen) inside a store-distributed app and pay normal card rates. They get store distribution without the store tax.
- Location features. Store finders, geofenced offers, and order-ready timing all benefit from native location access.
- The web version catches everyone else. First-time and low-commitment customers order in the browser with nothing to install; regulars get funnelled into the app where the loyalty flywheel lives.
Small independent takeaways
They typically build nothing themselves. Two common routes:
- Marketplace apps: list on Just Eat, Uber Eats, or Deliveroo. Zero build cost, but commissions run roughly 14–30% per order and the platform owns the customer relationship.
- White-label platforms: services like Flipdish (Irish), Storekit, or Slerp generate a branded app and ordering website for a monthly fee plus a small per-order cut. The takeaway keeps the customer data and pays far less per order than marketplace commission.
Many independents use both: marketplaces for discovery, their own white-label channel for repeat customers, often with a "order direct and save" incentive to shift regulars off the commission-heavy marketplaces.
5. How to decide for your own product
| If your product is… | Build… | Because… |
|---|---|---|
| Content, courses, or paid digital access (like an online book) | Web only | Instant deploys, Stripe's ~3% instead of the store's 15–30%, full SEO, and no gatekeeper who can remove you |
| Forms-and-data / dashboard style SaaS | Web first, PWA if mobile use grows | One codebase, always current, and desktop is usually the main surface anyway |
| Something driven by notifications, habit, or loyalty | Native (cross-platform), web alongside | Push and home-screen presence are the levers, and they need native |
| Something needing hardware: sensors, Bluetooth, heavy offline | Native | The browser sandbox simply does not reach far enough |
| Selling physical goods with a mobile-heavy audience | Web first; add native when repeat-purchase volume justifies it | The store cut does not apply to physical goods, so the native app is a retention tool, not a requirement |
Rule of thumb: the web is the default. Go native when one of the native-only capabilities (push, hardware, offline, home-screen habit) is central to how the product wins, not merely nice to have. This lesson explains what separates the two; when you are weighing the call for a specific product, the decision guide Which Should You Build First? walks you through making the choice. And if you sell digital content, remember the store tax: moving a €35 sale from Stripe to Play billing turns a ~€1 fee into a ~€5–10 one.
6. Quick glossary
| Term | Meaning |
|---|---|
| Native app | An app installed from a store, built for a specific platform (or compiled to one via Flutter/React Native) |
| PWA | Progressive Web App: an installable, offline-capable web app, no store needed |
| TWA | Trusted Web Activity: an Android shell that publishes your live website on Google Play |
| Hybrid app | Web code shipped inside a native container (Capacitor, Cordova) |
| Cross-platform framework | One codebase producing native apps for both Android and iOS (Flutter, React Native) |
| Store billing | Google/Apple's mandatory payment system for digital goods sold inside store apps, with a 15–30% cut |
| White-label platform | A service that generates a branded app/site for a business (e.g. Flipdish for takeaways) |
| Marketplace app | A shared platform aggregating many vendors (Just Eat, Uber Eats, Deliveroo) |
Check your understanding
- What can a store do to a native app that nobody can do to your website?
- Why does a fast food chain pay ~3% on an in-app order while a €35 digital book sold through store billing would lose 15–30%?
- Where does a TWA sit on the spectrum between a plain web app and a fully native app?
Sources and further reading
Reviewed 4 August 2026.