In short: the decision rule is simple. If you need no hardware the browser cannot provide and you do not have to be in the App Store, choose a PWA: 40 to 60% cheaper, live immediately and indexed by Google. If you need NFC, Bluetooth, background location or deep iOS integration, choose cross-platform or native. If in doubt, start with a PWA and wrap it in Capacitor once the store becomes necessary.
The 3 forms explained
PWA (progressive web app). A web application that behaves like an app: installable on the home screen, works offline, sends push notifications and opens without a browser bar. Technically it is a website with a manifest and a service worker. One codebase for iPhone, Android and desktop, no app store required. On Android, Chrome and Samsung Internet support almost everything; on iPhone, Safari has supported push notifications since iOS 16.4, provided the app is on the home screen.
Cross-platform app. One codebase in Flutter, React Native or Capacitor that compiles to a real iOS and Android app. You are in both stores, have access to almost all hardware through plugins and share 90 to 95% of the code. Capacitor is the bridge from the PWA world: your existing web app gets wrapped in a native shell with access to camera, NFC and biometrics.
Native app. Two separate codebases: Swift or SwiftUI for iOS, Kotlin or Jetpack Compose for Android. Maximum performance, immediate access to every new Apple and Google feature (widgets, Live Activities, Apple Watch, CarPlay, ARKit) and the feel platform users expect. Also the most expensive form, because everything exists twice.
The term 'web app' on its own usually means a web application that runs in the browser, without installation or offline features: a customer portal, a scheduling tool, a dashboard. Add a manifest and a service worker and it is a PWA. The distinction is small, and the path from web app to PWA is the cheapest upgrade there is.
Comparison table
| Criterion | PWA | Cross-platform (Flutter, React Native, Capacitor) | Native (Swift, Kotlin) |
|---|---|---|---|
| Cost of first version | €15,000 – 40,000 | €30,000 – 75,000 | €50,000 – 120,000 |
| Time to market | 4–8 weeks, live immediately | 8–14 weeks plus store review | 12–20 weeks plus store review |
| Offline | Yes, through cache and local storage | Yes, fully | Yes, fully |
| Push notifications | Android fully, iPhone after home screen install | Fully | Fully |
| Camera, location, biometrics | Yes, through browser APIs | Yes, through plugins | Yes |
| NFC, Bluetooth, background location | Limited, not on iPhone | Yes, through plugins | Yes |
| App stores | Optional: Google Play and Microsoft Store, not the App Store | Yes, both | Yes, both |
| Discoverability | Indexed by Google, shareable by URL | Only through the stores | Only through the stores |
| Updates | Instant, no review | Through the stores, 1–3 days review | Through the stores, 1–3 days review |
| Maintenance per year | 10–15% of the build | 15–20% of the build | 20–25% of the build, 2 platforms |
| Performance | Good for forms, content and ordering | Near native | Maximum |
The amounts are guide prices excl. VAT for a first version with accounts, 1 core process and an admin area. What exactly drives the price is covered in what an app costs and what a web application costs.
When a PWA is 40 to 60% cheaper
The price difference is not in the hourly rate but in what you do not have to do. No 2 codebases, no store process, no separate releases per platform and no 'works on Android, not on iPhone' tickets. A PWA is the right choice if your app meets these conditions:
- The core process is ordering, booking, filling in, reading or viewing. Menus, orders, reservations, forms, course material, portals, dashboards.
- The hardware you need is in the browser. Camera (QR scanning, photos), foreground location, biometrics through passkeys, payments through Apple Pay and Google Pay in the browser, sharing, files.
- Visitors must be able to reach you without friction. A QR code on the table, a link in an email, a search result in Google. Installing is an option, not a requirement.
- You want to update often and fast. Every change reaches all users immediately, with no store review.
- You do not want to pay 15 to 30% commission on digital sales in the stores. Note: on physical products and services, such as a meal or an on-site course, Apple charges no commission, not even in a native app.
For education and e-learning the PWA is often the logical form: learners open course material on laptop and phone, work offline on the train and get a notification when a new module is ready. No store account, no installation instructions, no managing 2 apps.
When native is unavoidable
Some functions a browser simply cannot deliver, and on iPhone that list is longer than on Android. Native or cross-platform is required if your app depends on:
- NFC or Bluetooth. Access passes, scanning tags, pairing with sensors or point-of-sale systems.
- Background processes. Tracking location while the app is closed (drivers, delivery), background sync, geofencing.
- Deep platform integration. Widgets, Live Activities on the lock screen, Apple Watch, CarPlay, Android Auto, HealthKit, Siri and Google Assistant.
- Heavy graphics performance. Games, AR, video editing, real-time drawing.
- The App Store as a channel. If customers expect you in the App Store or a tender requires it, you have to be there. Apple rejects apps that merely wrap a website (guideline 4.2), so a shell around a PWA must demonstrably add native value.
- Managed devices. Organizations that roll out apps through MDM (Intune, Jamf) expect a store package.
Also worth knowing: Safari keeps the local data of a PWA that sits on the home screen, but in the regular browser storage can be cleared after 7 days without use. For apps where offline data is sacred, that matters.
Cross-platform as the middle road
For most business apps that have to be in the store, cross-platform is the rational choice. Flutter and React Native deliver apps that users cannot tell apart from native, with 1 team and 1 codebase. Capacitor is the smartest route if you already have a web app or PWA: the same code, wrapped with native plugins, in both stores within 2 to 4 weeks.
What you give up compared to native: sometimes a few weeks of delay before a brand-new iOS feature is available in a plugin, and a fraction of performance under extreme graphics demands. What you gain: 40 to 50% lower build costs, 1 release cycle and 1 party that can maintain everything. At RABZI we build mobile apps cross-platform by default and only go native when a feature forces it.
Example: an ordering app for hospitality
A restaurant group with 3 locations wants guests to order and pay at the table, run a loyalty programme and receive delivery orders without platform commission. The wishes: QR code on the table, menu with photos, ordering and paying with iDEAL, Apple Pay and credit card, a notification when the order is ready, loyalty points and an admin area for the kitchen.
Everything on that list fits in a PWA. The QR code opens the app without installation, the guest orders within 30 seconds, pays through Mollie in the browser and gets a push notification on Android or, after home screen install, on iPhone. Returning guests install the app for the loyalty programme. The kitchen works on a tablet with the same web app in kiosk mode.
Native would cost €60,000 to €90,000 here for 2 platforms and a store process that does nothing for the guest sitting in the restaurant. As a PWA the same app costs €20,000 to €30,000, is live in 6 to 8 weeks and can later go into the stores with Capacitor for €5,000 to €8,000. More on this approach under hospitality.
RABZI estimate: we build a PWA or web app under web applications and platforms from €12,500 excl. VAT (portal or tool with 1 core process). Cross-platform mobile app development starts at €15,000 (MVP with 1 to 2 features), from €35,000 for Growth with accounts, push, payments and admin, and from €75,000 for Flagship with native modules and full offline use. In every case 1 codebase, a fixed price and everything in your name.
Frequently asked questions
Does a PWA work well on iPhone? Yes, with 2 caveats. Push notifications have worked since iOS 16.4 only when the user has added the app to the home screen, and Safari gives no access to NFC, Bluetooth and background location. For ordering, booking, reading and forms an iPhone user notices no difference from a native app.
Can a PWA go into the App Store or Google Play? In Google Play and the Microsoft Store you can publish a PWA almost directly. Apple's App Store does not accept apps that merely wrap a website. If you want to be in it, you wrap the PWA with Capacitor and add native features that demonstrably make the app more than the website.
What does a PWA cost compared to a native app? A PWA costs €15,000 to €40,000 for a first version, a cross-platform app €30,000 to €75,000 and a native app for iOS and Android €50,000 to €120,000. The difference lies in the number of codebases, the store process and maintenance: with native you pay for everything twice.
Can I move from PWA to native later? Yes, and that is exactly why we often start with a PWA. With Capacitor you wrap the existing code in a native shell and add plugins for NFC, Bluetooth or background processes. Only under extreme performance demands is a full rebuild in Swift and Kotlin needed.
Conclusion
The question is not which form is best, but which form fits what your app has to do. Ordering, booking, filling in and reading: PWA, fast and affordable. NFC, Bluetooth, background processes or a store requirement: cross-platform, with native as the last resort. And if you are unsure, start with a PWA and keep the road to the stores open. Want to know which form fits your app? Book an intro call and you will have advice on form, price and planning within 2 business days.