Every founder who wants a mobile app should ask one question first: would a really good mobile web app solve the same problem? If the honest answer is yes, you have just saved $40K–100K and 4–6 months.
Most product decisions that favor native iOS are made on instinct (“apps feel more serious”) or habit (“our competitors have an app”), not on a clear-eyed look at what native actually gives you that a web app does not. This guide covers that difference, the decision framework, and the cost table for each option.
What Native iOS Apps Can Do That Web Apps Can't
| Capability | Native iOS | Web App |
|---|---|---|
| Push notifications | Reliable, rich (images, actions, grouping) | Limited; requires home-screen install, iOS support only since 16.4, no lock-screen display |
| Background processing | Full support: location tracking, health data, downloads, Siri integration | None — web apps stop running when the browser is not in the foreground |
| App Store distribution | Discovery, trust signal, built-in payment infrastructure | Not applicable — users find and access via browser or direct URL |
| Hardware access | Full camera API, ARKit, Core Motion, NFC, Bluetooth (BLE + classic) | Limited browser APIs: camera (no low-level control), no NFC, no BLE on iOS Safari |
| Offline-first | SQLite, Core Data, full local DB with sync logic | IndexedDB available but has storage limits, unreliable across Safari versions |
| Performance | 60fps animations, Metal GPU access, optimized memory management | Near-native on modern devices for most UI patterns; complex animations can lag |
The important word is “can”. Most apps do not use most of these capabilities. If your app is primarily forms, lists, content display, and notifications — the vast majority of B2B tools — native iOS gives you meaningful advantages only in push notification reliability and offline storage depth.
What Web Apps Do Better
- No App Store review cycle. Deploy updates instantly. No 1–3 day review, no rejection for UI changes Apple decides are against guidelines, no version approval to change a piece of text.
- Cross-platform by default. The same codebase works on iOS, Android, and desktop. Native iOS means you are building for one platform and explicitly excluding every other one.
- Lower initial cost. 40–60% cheaper to build than native iOS for comparable feature sets. The gap comes from platform-specific APIs, App Store submission complexity, and the Swift skill premium.
- SEO. Web apps are indexable by Google. Native apps are invisible to search engines. If organic discovery matters to your business, this is not a small consideration.
- No Apple 30% commission on payments. In-app purchases in native apps must use Apple’s payment system, which charges 30% (15% for small developers). Web apps with Stripe or any other payment processor bypass this entirely. For a subscription business, this changes the unit economics materially.
The Decision Framework
Five questions that point toward native or web. Answer them honestly before committing to a platform.
1. Does the user need this on their home screen, always available?
Native advantage. Users find apps on the home screen, launch them without opening a browser, and associate them with a distinct brand presence. If your use case involves frequent, quick access throughout the day (task manager, timer, check-in tool), native wins. If users access it once a week through a link, a web app is fine.
2. Do you need hardware access — camera at the API level, GPS background tracking, NFC, or Bluetooth?
Native required. Background GPS for location tracking, NFC scanning, BLE device communication — these are not available in web browsers on iOS. This is not a gap that is closing soon; it is Apple’s deliberate platform boundary.
3. Is your revenue model subscription or one-time purchase?
Web app avoids Apple’s 30% cut. A $10/month subscription through Apple IAP nets you $7 (or $8.50 in year two). Through Stripe on a web app, you net $9.70. Over 1,000 subscribers, that is $3,600/year in platform fees versus $360/year in Stripe fees. The decision compounds with scale.
4. Do you need App Store distribution for discovery?
Native required. App Store search is a real distribution channel, particularly for consumer apps in competitive categories. If your go-to-market relies on users finding you through App Store search or featured placement, you need to be in the App Store.
5. Is your timeline under 3 months?
Web app, significantly. Native iOS development has a baseline of 3–6 months for a reasonably featured product. A web app equivalent ships in 6–14 weeks. App Store submission itself adds 1–3 weeks. If you are trying to validate a product in the market before committing to the full native build, start with the web.
Progressive Web Apps (PWA) — The Middle Ground
A PWA is a web app that can be added to the home screen, work offline, and send push notifications. It is not a native app — it runs in the browser engine — but it narrows the experience gap significantly for many use cases.
- Android: Excellent PWA support. Full push notifications, home-screen install with a native-feeling prompt, offline functionality via service workers.
- iOS (Safari, since 16.4): Push notifications work for users who add the app to their home screen from Safari. Some device APIs unavailable. Offline support functional but has storage limits.
- Cost: 20–30% premium over a standard responsive web app. 40–60% cheaper than native iOS.
- Best for: B2B internal tools, operations dashboards, field-worker apps where home-screen access matters but deep hardware integration does not.
If your target user is primarily on Android, or if you are building a B2B tool where IT deploys the app and individual preference matters less, a PWA delivers most of the native experience at a fraction of the cost.
Hybrid: React Native and Flutter
Hybrid frameworks let you write one codebase that compiles to native iOS and Android apps. They close most of the cross-platform cost gap while maintaining access to native APIs.
React Native uses JavaScript and renders native UI components. Large ecosystem, backed by Meta, 70–80% code sharing between iOS and Android. Mature enough for production at scale. Some native APIs require bridging code written in Swift or Kotlin.
Flutter uses Dart and renders its own UI layer (not native components). Better animation performance, strong Google backing, growing ecosystem. More self-contained: fewer native bridges needed, but more different from platform design conventions.
Cost vs native: 30–40% cheaper than building two separate native apps. The savings come from shared business logic and a single team rather than iOS and Android specialists in parallel.
Trade-offs to know: debugging is harder than pure native (additional abstraction layer), some edge-case native behaviors require platform-specific code anyway, and hiring for React Native or Flutter is a different market than hiring for Swift or Kotlin.
Cost Comparison
| Platform | Typical cost | Timeline |
|---|---|---|
| Web app (React / Next.js, responsive) | $20K–60K | 6–14 weeks |
| PWA (web app + offline + home screen) | $25K–75K | 8–16 weeks |
| Native iOS | $30K–120K | 3–6 months |
| React Native (iOS + Android) | $40K–130K | 3–7 months |
The ranges are wide because they depend heavily on feature count and integration complexity. A native iOS app with three screens and no backend integration is $30K. A native iOS app with real-time sync, Bluetooth device pairing, background location, and a custom onboarding flow is $120K. The same scope variables apply to every platform.
Frequently Asked Questions
Can a web app replace a native iOS app?
For most business use cases, yes. If your app does not need background location tracking, Bluetooth, NFC, ARKit, or offline-first with a local database, a responsive web app with home-screen support covers 80% of what a native app does at 40–60% of the cost. The honest question is not “is web as good as native?” but “which native-specific capabilities does my use case actually require?” For most B2B tools, the answer is none.
Does Apple's 30% commission apply to web apps?
No. Apple’s 30% commission (15% for small developers) only applies to in-app purchases in native iOS apps distributed through the App Store. Web apps with Stripe or other payment processors bypass Apple’s payment system entirely. This is a significant cost difference for subscription businesses. A $15/month plan through Apple IAP nets you $10.50 per subscriber. Through Stripe on a web app, you net $14.55. Over a 1,000-subscriber base, that is $48,000/year difference in gross margin.
What is a Progressive Web App and is it worth building?
A PWA is a web app that can be installed on the home screen, work offline, and send push notifications. On Android, PWA support is excellent. On iOS, it has improved significantly since iOS 16.4 but still has limitations: push notifications require the user to have added the app to their home screen via Safari, and some device APIs remain unavailable. Worth building if you need home-screen presence on both platforms without App Store distribution overhead. Not worth building if you specifically need background processing or hardware access that the browser does not expose.
How much cheaper is a web app than a native iOS app?
Typically 40–60% cheaper for equivalent features. A native iOS app that costs $80K often has a web equivalent at $35K–45K. The gap widens when you target both iOS and Android: a cross-platform web app versus two native apps is often a 50–70% cost saving. The math shifts if your native app uses platform-specific APIs that have no web equivalent — then the comparison is not truly apples-to-apples, because the web version genuinely cannot do the same thing.
