Mobile App vs Web App: When to Build Which (and What It Costs)
Should you build a native mobile app, a progressive web app, or a web application? We break down the real trade-offs — cost, capability, distribution, and maintenance — and give our honest recommendation for different product types.
One of the most consequential decisions you'll make when building a digital product isn't which colour to use on your call-to-action button, or even which database to put behind it. It's whether to build a mobile app, a web app, or something in between — and most teams make that call too quickly, too emotionally, or too heavily influenced by what competitors appear to be doing.
We've seen this mistake more times than we can count. A founder comes to us convinced they need an iOS app on day one because "that's what customers expect." Six months and $80,000 later, the app is in the store, getting two downloads a week, and the business has no marketing budget left to drive acquisition. We've also seen the opposite — a B2B SaaS company that delayed launching because they were waiting to complete native Android coverage, while their web app sat finished and untested in a staging environment.
The choice between mobile and web isn't a question of ambition or technical sophistication. It's a question of where your users actually are, what they need to do, and what you can sustain. Get it right and you'll ship faster, spend less, and reach more people. Get it wrong and you'll spend years maintaining two codebases for a product that would have worked perfectly as a website.
This guide is our honest attempt to give you the framework we use internally when advising clients. We'll define the options clearly, walk through the trade-offs, share real cost numbers, and give you a decision framework you can apply to your own product — today.
The Options Defined
Before we can compare anything, we need to agree on what we're comparing. These terms get used loosely, and that imprecision costs people money.
Native Mobile App (iOS and/or Android)
A native mobile app is built specifically for one operating system using its preferred tools and languages. iOS apps are built in Swift or Objective-C using Xcode and Apple's UIKit or SwiftUI frameworks. Android apps are built in Kotlin or Java using Android Studio and Google's Jetpack Compose or View system. A native app runs directly on the device's operating system, has full access to all hardware APIs, and is distributed through the App Store or Google Play.
Native apps deliver the best performance, the most complete access to device hardware, and the most polished platform-specific user experience. They also cost the most to build, require the most expertise, and result in two entirely separate codebases if you want to be on both platforms.
Cross-Platform Mobile App (React Native / Flutter)
A cross-platform app is written in a single shared codebase but compiled or rendered into something that runs on both iOS and Android. The two dominant frameworks are React Native (maintained by Meta, written in JavaScript/TypeScript) and Flutter (maintained by Google, written in Dart). Both produce apps that are distributed through the app stores and can access most — but not all — native device features.
Cross-platform development is positioned as "write once, run everywhere," though as we'll discuss, that promise requires serious qualification. The main appeal is cost: one team, one codebase, two platforms.
Progressive Web App (PWA)
A Progressive Web App is a website built with modern web standards that can behave, in many respects, like a native mobile app. PWAs can be added to a user's home screen, work offline, receive push notifications (on Android and — with significant limitations — iOS), and access certain hardware features like the camera and GPS through browser APIs. They are delivered through the browser, not the app stores, and they update automatically without user action.
PWAs occupy a genuine middle ground. They are cheaper to build than native apps and require no app store presence or approval process, but they have real capability gaps, particularly on Apple devices, that we'll detail below.
Responsive Web Application
A responsive web application is a browser-based application that adapts its layout to different screen sizes — desktop, tablet, and mobile — but makes no attempt to mimic a native app experience. It lives at a URL, requires an internet connection to function, and is accessed through a browser. This is the standard for the vast majority of B2B tools, SaaS dashboards, admin panels, and internal business systems.
Responsive web apps are the default choice for most products. They are the least expensive to build, the fastest to iterate on, require no approval from platform gatekeepers, and reach every device with a browser without any additional code.
When Native Mobile Always Wins
There are clear categories of product where native mobile is not a preference — it is a requirement. If your product falls into one of these, we will tell you to build native without hesitation.
Hardware access is central to your product. If your app needs continuous GPS tracking, background location services, real-time camera processing, NFC payments or tag reading, Bluetooth Low Energy connections, biometric authentication beyond basic Face ID prompts, or access to health sensors like heart rate from Apple Watch or Android Wear — you need native. The web platform has made meaningful progress on device access over the last few years, but native APIs are still significantly more capable, more reliable, and better supported. A delivery tracking app, a medical device companion app, a contactless payments tool — these aren't optional native applications. They're native because they have to be.
Offline-first is a core requirement, not a nice-to-have. If your users are regularly working in low or no connectivity environments — field workers, logistics operatives, remote area surveyors, pilots — and your app needs to process data, store complex state, and sync reliably when connectivity returns, native gives you substantially more robust tools for that job. Service workers in PWAs handle offline functionality for many use cases, but native SQLite, Core Data, Room, and background sync primitives are more powerful and more battle-tested at scale.
Push notifications are a primary engagement mechanism. Yes, web push notifications exist. Yes, PWAs support them on Android. But if your entire product engagement model depends on timely, reliable push notifications — a messaging app, a real-time collaboration tool, a live trading platform — native push via APNs and FCM is still the most reliable delivery path. iOS web push, introduced in iOS 16.4, has improved but carries restrictions that don't exist in native.
You are building a game, an AR/VR experience, or anything compute-intensive. WebGL and WebAssembly have extended the browser's graphical capabilities significantly, but for latency-sensitive, GPU-intensive experiences, native still has the performance headroom, the access to Metal and Vulkan, and the toolchain maturity you need.
Your primary acquisition channel is the App Store. If "App Store Optimisation" is genuinely how you expect to grow — if organic store discovery is part of your go-to-market — then you need to be in the store. A PWA installed from the browser doesn't rank in App Store search. If your business model requires distribution through Apple's or Google's storefronts, native or cross-platform is your only real option.
When a Web App Is Sufficient
For a surprisingly large number of products, a web application does everything needed — often better than a native app, because it removes distribution friction entirely.
Most B2B tools and internal software. If your users are employees, contractors, or professional customers who access your product primarily from a desk — even if they occasionally use it on a phone — a responsive web application is almost always sufficient. Procurement tools, HR platforms, project management software, CRM dashboards, financial reporting systems: these live in browser tabs. A native app for a B2B tool creates a second maintenance surface without a clear user benefit.
Dashboards, admin panels, and reporting tools. These are fundamentally data-heavy, interaction-light interfaces. They often need large screens to be genuinely usable, which makes mobile a secondary platform at best. Build the web app well. Make it responsive. Don't build a native app for a dashboard that no one will use on their phone anyway.
Booking, scheduling, and reservation systems. Users access these via a link — from an email, an SMS, a QR code, a search result. The booking flow is short, the session is infrequent, and there's no compelling reason to ask a user to install an app for a workflow they complete in three minutes. A fast, mobile-optimised web page outperforms an app in this context simply because it removes the installation barrier.
Early-stage products. If you are validating a business idea, testing demand, or building an MVP that you plan to iterate on rapidly, start with a web application. You will move faster, spend less, and have more flexibility. You can always add a native app later when you know what the product actually needs to be. We'll discuss the sequencing question in the FAQ at the end.
Any product where users arrive via link, email, or search. If discovery and access happen through the browser — if your traffic is primarily referral, email, or organic search — a web app meets users exactly where they are. Asking them to detour through the App Store before they can use your product is a conversion killer.
Progressive Web Apps — The Middle Ground
PWAs have matured significantly since Google first championed the concept in 2015. When we describe them to clients, we're careful to be specific about both what they can do and where they still fall short, because the gap between "what a PWA can do in theory" and "what it can do reliably on an iPhone" remains real.
What a PWA can genuinely do
- Offline functionality — using service workers and the Cache API, a PWA can cache assets, store data in IndexedDB, and present a working interface when the network is unavailable
- Home screen installation — on Android via a browser prompt, and on iOS via the "Add to Home Screen" option in Safari, a PWA can be installed as an icon on the home screen and launched in a standalone window
- Push notifications — on Android, PWA push notifications work reliably via the browser's push service. On iOS (Safari 16.4+), web push is now supported but with caveats around background delivery and notification grouping
- Camera and microphone access — via the MediaDevices API, PWAs can access the camera and microphone. This is sufficient for photo capture, QR code scanning, and basic video chat
- Geolocation — works in PWAs across all major browsers, suitable for location-aware features
- Automatic updates — no user action required. When you ship a new version, users get it on their next visit
What a PWA still cannot do
- Background sync on iOS is limited. Service worker background sync is not fully supported on iOS Safari, which means reliable background data sync — the kind a messaging app or task manager needs — is not achievable without native
- No App Store presence. PWAs cannot be submitted to Apple's App Store or Google Play. This means no organic store discovery, no app store reviews, and no ability to reach users who only acquire apps through those channels
- No access to NFC, Bluetooth (meaningfully), or advanced health APIs
- Limited background processing. Tasks that need to run when the app is not in the foreground — location tracking, audio playback metadata controls, sensor polling — are restricted in web contexts
When a PWA is the right call
A PWA is the right choice when you need offline support, home screen install, or basic push notifications, but do not need App Store presence and your hardware requirements are limited to camera and GPS. A food ordering app for a specific restaurant group, a field data collection tool for internal staff, a customer portal for a service business — these are strong PWA candidates. You get 80% of the native app feel at 40–50% of the cost.
Cross-Platform vs Native — The Real Trade-Offs
The pitch for React Native and Flutter is straightforward: write one codebase, ship to both iOS and Android, save money. In practice, the reality is more textured.
React Native
React Native lets JavaScript/TypeScript developers build mobile apps using React-style component thinking, with a bridge to native platform APIs. The developer experience has improved dramatically since its early days — the Hermes engine, the new architecture (Fabric), and the ecosystem of third-party libraries make it a credible choice for a wide range of apps.
React Native works well for: apps with standard UI patterns, teams with existing JavaScript/React expertise, products where speed to market matters more than pixel-perfect platform-specific feel.
React Native struggles with: complex custom animations, deep hardware integration, apps that need to feel genuinely native on both platforms simultaneously, and large teams working on the same codebase without strong discipline.
Flutter
Flutter takes a different approach — it renders its own UI entirely, bypassing native platform widgets. This makes it extremely consistent across platforms and highly performant for UI rendering, but it means your app will not look or feel exactly like a native iOS or Android app. Google has invested heavily in Flutter, and it now compiles to iOS, Android, web, desktop, and embedded targets from one codebase.
Flutter works well for: teams comfortable with Dart, apps where visual consistency across platforms matters more than platform-specific conventions, and products that also need a desktop or web version.
Flutter struggles with: apps where users expect native platform conventions (like iOS-specific navigation gestures), deep integration with native iOS or Android SDKs, and the smaller — though growing — library ecosystem compared to React Native.
The 70–80% Code Sharing Myth
Both React Native and Flutter teams regularly cite 70–80% code sharing between platforms as a headline benefit. This is technically accurate and practically misleading. The 20–30% that is platform-specific tends to be the hardest 20–30% — camera pipelines, push notification handling, deep linking, background modes, and app store integration code. The shared 70% is largely UI components and business logic, which is genuinely valuable, but you should not plan a budget assuming two native apps for the price of one. A realistic cross-platform project costs roughly 60–70% of two separate native apps, not 50%.
Cost Comparison
These are realistic ranges based on our own project delivery experience and current market rates. "MVP" here means a complete, shippable first version — not a polished, feature-complete product.
| Platform | MVP Build Cost (USD) | Timeline | Ongoing Maintenance (Annual) |
|---|---|---|---|
| Responsive Web App | $15,000 – $60,000 | 8–20 weeks | $5,000 – $20,000 |
| Progressive Web App | $20,000 – $70,000 | 10–22 weeks | $6,000 – $22,000 |
| React Native (iOS + Android) | $55,000 – $150,000 | 18–36 weeks | $18,000 – $45,000 |
| Flutter (iOS + Android) | $50,000 – $140,000 | 16–34 weeks | $16,000 – $40,000 |
| Native iOS + Android (separate) | $100,000 – $280,000+ | 28–52 weeks | $30,000 – $80,000 |
A few notes on these numbers. The web app range is wide because complexity varies enormously — a simple booking system at $15,000 is a very different product from a multi-tenant SaaS platform at $60,000. The React Native and Flutter ranges assume a team of two to three developers plus design and QA. The native iOS + Android range assumes two separate development streams running in parallel; doing them sequentially adds time but can reduce cost by 15–20% through shared design assets and API work.
Maintenance costs include OS compatibility updates, dependency updates, bug fixes, and minor feature additions. They do not include major feature development.
App Store Costs and Constraints
If you're planning to distribute through Apple's App Store or Google Play, you need to understand the platform costs beyond the development investment — because they affect your business model in ways that can be decisive.
Apple charges 30% commission on in-app purchases and subscriptions. If your app has any paid functionality sold within the app — subscriptions, credits, digital content — Apple takes 30% (or 15% for small developers and year-two subscriptions). For a SaaS product with a $50/month subscription, that's $15 per user per month gone before you pay a single operational cost. Many B2B products deliberately avoid in-app purchases for this reason, directing users to a web checkout instead. Apple's guidelines are increasingly strict about this — the DMA in the EU has changed some rules for European users, but globally, the commission structure remains for most categories.
App review delays are real and unpredictable. Apple's review process averages two to four days but can run longer, and a rejection can set your release schedule back by a week or more. If your product requires rapid iteration — hotfixes, A/B tests, feature flags — the App Store review cycle creates friction that a web app simply doesn't have. We've had clients lose significant revenue during a critical sales period because a bug fix was sitting in App Store review. That risk doesn't exist on the web.
Guideline restrictions can force architectural decisions. Apple has explicit rules about what apps can and cannot do — how they must handle user data deletion, how they must present subscription terms, which categories of content are allowed, and increasingly, which payment methods are permissible. If your product is adjacent to any regulated or sensitive category, you may find the App Store guidelines shaping your product roadmap in ways you didn't anticipate.
For some products — particularly marketplaces, media platforms, and products with complex pricing models — the App Store constraints are a strong argument for making the web app the primary product, with a mobile app as a supporting channel rather than the primary one.
The Maintenance Reality
When teams compare build costs, they often forget that the cost of shipping is not the cost of owning. A native mobile app on both platforms creates ongoing obligations that a web application does not.
OS version updates are mandatory, not optional. Apple and Google deprecate older APIs, change their UI conventions, and introduce new system requirements with every major OS release. Each autumn brings a new iOS version, and your app will need to be tested, updated, and re-submitted to remain functional and compliant with the latest guidelines. Ignore these updates and your app will stop working on new devices, be removed from the store for non-compliance, or develop visual and behavioural regressions that damage user trust. This is not a one-time cost — it is a permanent, recurring commitment.
Two native apps mean two maintenance streams. iOS and Android update on independent cycles. A change that works on one platform sometimes requires a separate fix on the other. Third-party libraries that your app depends on may be maintained on different timelines for each platform. Over a three-to-five year product lifecycle, the cumulative maintenance cost of two native apps can equal or exceed the original build cost.
Web apps update instantly and silently. When you deploy a fix or a new feature to a web application, every user gets it the next time they load the page. No review process, no version fragmentation, no users running a version of your product from two years ago because they haven't updated their phone. For teams running iterative development cycles, this is a significant operational advantage.
Our Recommendation Framework
Use these questions in order. Answer honestly based on your product as it exists today, not as you imagine it might eventually become.
1. Do your core features require hardware access that is only available natively? (Continuous background GPS, NFC, Bluetooth LE, advanced camera APIs, health sensors) — If yes, build native or cross-platform. If no, continue.
2. Is offline-first functionality a core requirement, not a nice-to-have? (Users regularly work in no-connectivity environments and need full app functionality) — If yes, consider native or cross-platform. If no, continue.
3. Is the App Store your primary user acquisition channel? (Your growth model depends on organic store discovery) — If yes, you need to be in the store. If no, continue.
4. Are your users primarily on mobile, and do they interact with your product multiple times per day? (Your product is a daily-use consumer app, not an occasional tool) — If yes, consider a PWA or cross-platform app. If no, continue.
5. Do you need push notifications as a core engagement mechanism? — If yes and you're targeting iOS, you'll need to decide between a cross-platform app or accepting the limitations of web push. If no, continue.
If you've reached this point: a responsive web application is almost certainly your best starting point. Build it well, make it fast on mobile, and revisit the mobile app question when your user data tells you what they actually need.
How We Approach This Decision at Cyberbeak
Our default recommendation is to start with a web application. Not because we prefer them, and not because they're cheaper to build (though they often are) — but because they eliminate an enormous amount of risk in the early stages of a product.
A web app can be built in half the time of a native app. It can be updated without a gatekeeper's approval. It reaches users on every device without asking them to install anything. And when the time comes to add a mobile app — because you have real users telling you they need one, because your data shows that 80% of sessions are on mobile and engagement would genuinely improve with native features — you'll be adding it with product knowledge that a team starting with native day one simply doesn't have.
In practice, the products where we've recommended starting with native mobile from day one fall into a small number of categories: consumer apps where App Store discoverability is central to growth, products that genuinely need hardware access from day one, and apps where the "feel" of the product is so central to the value proposition that anything less than native would undermine it.
For everything else — B2B tools, SaaS platforms, booking and scheduling systems, marketplaces, internal tools, and early-stage consumer products — we start with web, make it excellent, and build the mobile layer when the evidence says it's needed.
When cross-platform does make sense, we lean towards React Native for teams that already work in JavaScript, and Flutter when the product spans multiple platforms (web, mobile, and desktop) or when visual consistency is a primary requirement.
FAQ
Can I add a mobile app later if I start with a web app?
Yes, and this is usually the right sequence. Starting with a web app doesn't close off any options — it gives you the user data and product clarity to make the mobile app decision well. The API layer you build for your web app is the same API layer your mobile app will consume. The only thing you'll need to build from scratch is the mobile front end, and by the time you do that, you'll know exactly what it needs to do.
What about React Native — isn't it basically as good as native now?
React Native has improved significantly and is a genuinely capable framework for a wide range of apps. For products with standard UI patterns and no deep hardware requirements, it produces results that are indistinguishable from native for most users. Where it still falls short is in complex animations, custom navigation gestures that feel platform-native, and apps that need to push the limits of what the platform can do. If your app's value proposition is substantially about the interaction quality of the experience, the gap between React Native and native may matter. For most business applications, it won't.
Should I build both a web app and a mobile app at the same time?
Almost never, at the start. Building both simultaneously doubles your front-end cost, doubles your QA surface, divides your team's attention, and forces you to make design decisions about both platforms before you have user feedback. The exception is when there is a clear, validated case for both — where you know from existing research that you have two distinct user groups, one firmly on desktop and one firmly on mobile, each needing the product in a different context. That scenario exists, but it's the minority. Start with one, learn, then extend.
How does the mobile vs web choice affect my timeline to launch?
A native iOS app adds roughly eight to sixteen weeks to a typical product timeline compared to the equivalent web app, depending on complexity. Cross-platform adds four to ten weeks. A PWA adds two to four weeks over a standard responsive web app. If you're on a deadline — a specific launch event, a funding milestone, a seasonal window — this difference can be decisive. We've seen products miss their entire market window because the team insisted on a native app for a launch where a web app would have been adequate.
What about desktop apps — is that a separate conversation?
Largely yes, though it's related. Most "desktop apps" built today are either web apps running in Electron (essentially a bundled browser), or genuinely native desktop applications for Windows and macOS. For most business software, Electron or a web app is sufficient. Tools like Notion, Figma, VS Code, and Slack are all Electron apps — the performance limitations are real but acceptable for most use cases. Genuinely native desktop development (Swift for macOS, WinUI for Windows) is warranted for compute-intensive tools, creative software, or products where OS integration is essential. Flutter is also a credible choice for cross-platform desktop, particularly if you're already using it for mobile.
If you're working through this decision for a product and want a perspective grounded in what we've actually built and deployed, we're happy to talk. We don't push a particular platform — we push the one that makes the most sense for what you're trying to do. Get in touch and tell us about your product.
Sprechen Sie mit unserem Team über Ihr Projekt
Wir arbeiten mit Unternehmen in Großbritannien, den USA, den VAE, Saudi-Arabien, Kanada, Australien und Deutschland zusammen, um maßgeschneiderte Software, SaaS-Plattformen und Marketplace-Systeme zu entwickeln.