Every founder we talk to wants a mobile app. Most of them don’t need one. They need a fast, well-designed mobile web experience and the discipline to say no to features that don’t move the metric they actually care about.
This post is the conversation we have with clients before we take their money. If you walk away convinced you don’t need an app, that’s a win. If you walk away knowing exactly why you do — that’s also a win.
The Honest Question: App or Mobile Web?
Before we discuss frameworks, ask one question: what does an app let you do that mobile web cannot?
There are exactly four good answers: deep hardware access (camera with low latency, ARKit, Bluetooth LE, background location), reliable offline mode, push notifications with high open rates, and a home-screen icon that drives habitual return visits. If your use case doesn’t depend on at least two of these, you’re probably building an app for ego, not engineering reasons.
Twitter spent years pushing Twitter Lite, a PWA that’s now installed by over 75 million users — mostly in markets where data and storage are expensive. The PWA loads in under 3 seconds on 2G, takes 1-3MB of storage versus 200MB+ for the native app, and converts users at rates Twitter publicly called “comparable to native.” For a read-heavy content product, the PWA was the right answer.
Instagram is the opposite case. The native app uses the camera pipeline, gyroscope, ML Core / Core ML for filters, and aggressive caching that browsers simply can’t match. A PWA Instagram would be a worse Instagram. Choose your tools based on what you actually need to ship, not what’s fashionable.
If your “app” is mostly a list of items with a checkout button, you’re building an expensive bookmark. Ship a PWA, see if anyone installs it, then decide.
PWA vs Native: When Each Wins
PWAs win when reach matters more than depth. You get one codebase, no app store review, instant updates, and indexable URLs that show up in Google. The cost of building a serious PWA sits around $20k–$60k, and you can iterate weekly without waiting on Apple’s reviewers.
Native wins when the experience itself is the product. Games, social apps with heavy media, fitness apps that need background sensors, financial apps with biometric auth, and anything requiring the App Store’s discovery surface. Native cost reality: $80k–$300k for a properly built iOS + Android app with backend, infrastructure, analytics, and a year of post-launch iteration. Most “$30k mobile app” quotes you’ll see online are for a thin wrapper around a website. That’s not what we mean by native.
A useful rule: if you can describe your product without using the words “camera,” “offline,” “notification,” or “background,” start with a PWA. You can always go native later. The reverse migration — native app to PWA — happens more often than founders admit.
For a deeper view on cross-platform web frameworks that often power the underlying logic, see our comparison of React, Vue, and Angular.
Native vs Cross-Platform: React Native vs Flutter
Once you’ve committed to native, the next fork is platform-specific Swift/Kotlin or cross-platform with React Native or Flutter. Here’s the honest split:
React Native wins when your team already writes React and you need to share logic between web and mobile. Shopify, Discord, and Microsoft Office mobile all ship React Native at scale. Performance is good enough for 95% of apps. The pain points: native module integration is fiddly, animations sometimes drop frames on Android, and you’ll write platform-specific code more often than the marketing promises.
Flutter wins when you want pixel-perfect identical UI on both platforms and you’re willing to learn Dart. Google’s BMW, Alibaba, and Reflectly apps are Flutter. The rendering engine (Skia, now Impeller) draws every pixel, which means consistent design and great animation performance — but also a UI that can feel slightly foreign on iOS unless you work to match Cupertino conventions.
Cost reality for cross-platform: $50k–$180k for a serious app. You save roughly 30-40% versus dual-native, not 50%. The savings show up in maintenance more than initial build. One bug fix, two app stores.
When does cross-platform fail? Heavy graphics (games — use Unity), apps where iOS and Android UX should genuinely diverge (banking apps with different regional compliance), and anything that lives or dies by integrating with the latest OS features the day they ship.
The App Store Tax: 30%, Reviews, and IAP
App stores are not free distribution. Apple takes 30% on most digital transactions (15% for small businesses under $1M and for subscriptions after year one). Google takes the same. If you sell digital goods through your app, that cut comes off the top, and you’re forbidden from telling users they could pay less on your website — at least in jurisdictions where the Digital Markets Act and the Epic ruling don’t yet apply.
Then there’s review. A standard App Store submission takes 24-48 hours, but rejection for ambiguous reasons happens often enough that you should budget a week per major release. Google Play is faster and more lenient, which is both a blessing (ship today) and a curse (your competitors ship malware-adjacent clones tomorrow).
If your business model is subscriptions, calculate carefully. A $9.99/month app earning 30% to Apple makes the same gross as a $7/month web subscription. Many SaaS companies have moved primary signup to web and offer the mobile app as a companion to existing accounts — exactly to avoid the IAP requirement. Read Apple’s developer guidelines carefully before you architect billing.
Push Notifications: The Real Numbers
Push notification open rates are the most misquoted statistic in mobile. The honest range:
- iOS push open rate: 4-8% for opt-in users (median around 5%)
- Android push open rate: 8-12% (Android auto-opts users in)
- Web push open rate: 5-10% but with far higher opt-in friction
- Email open rate (for comparison): 20-25% across industries
Where push wins is immediacy and re-engagement. A well-timed push at the right moment — order delivered, friend posted, price dropped on a watched item — converts at rates email never touches. Where push loses is volume. Send three marketing pushes per week and users uninstall. The opt-out is one tap on iOS 16+.
The opt-in psychology matters too. iOS asks users to authorize notifications, and asking too early kills your rate. Best-in-class apps wait until the user understands the value — typically session 2 or 3 — and ask in context (right after the user did something notification-worthy). Apps that ask on launch get 30-40% opt-in. Apps that ask in context get 60-70%.
Offline: When It Actually Matters
“Works offline” is a feature founders demand and users rarely notice — unless you operate in a context where offline is the default.
Real offline use cases:
- Logistics and delivery: Drivers in basement parking, rural routes, warehouses with metal roofs. Apps like Onfleet and Bringg are built offline-first.
- Field service: Technicians in mechanical rooms, on rooftops, inside elevators.
- Travel: Boarding passes, transit maps, downloaded media for flights.
- Healthcare in low-connectivity regions: EHR apps that sync when uplink returns.
If your app is “social network for X” or “marketplace for Y,” offline is vanity. Build a great loading state and a clear error message. You’ll spend $40k engineering offline-first sync and your retention metrics will move zero percent.
Install Rate and Retention: The Brutal Math
Industry-wide retention numbers from the last Statista and AppsFlyer reports are sobering. See Statista’s mobile app benchmarks for current breakdowns.
Average day-1 retention: ~25% across categories Average day-30 retention: ~5-8% Best-in-class day-30: 25-35% (social, fitness, finance)
Translation: out of every 1,000 people who install your app, 920 will not be using it a month later. Your CAC needs to assume an 8% survivor pool. If you’re paying $5 per install, your true CAC against retained users is $62.
This is why the install is not the goal. The behavior that follows the install is the goal. Build for the second session, not the first download. If you can’t articulate what makes someone open your app on day 3, you’re not ready to build it.
A mobile commerce app, for instance, lives or dies on the second purchase. We covered the broader pattern in our mobile commerce piece. Mobile-first checkout, one-tap reorder, and address autofill matter more than the home screen carousel.
Security: The Boring Stuff That Wrecks Launches
Mobile apps fail App Store review more often for privacy violations than for crashes. iOS 17+ requires explicit declaration of every API used to access user data, and Google Play’s data safety section is increasingly enforced. Common mistakes we see:
- Logging user data to third-party crash reporters without disclosure
- Sending IDFA / Advertising ID without ATT prompt
- Bundling SDKs that phone home (looking at you, Facebook SDK in 2020-2022)
- Storing tokens in plain UserDefaults / SharedPreferences instead of Keychain / Keystore
We wrote about the broader threat model in our secure web applications guide, and most of it transfers — mobile just adds a layer of OS-level capability gates you have to negotiate.
Should You Build an App?
Run this short test:
- Can your core use case be a great mobile web experience? If yes, start there.
- Do you have a real reason to need camera, offline, or push at high rates? If no, you’re paying $150k for an icon on a home screen.
- Can you commit to two years of native maintenance — iOS releases, Android updates, store policy changes? If no, choose cross-platform or PWA.
- Is your retention model strong enough to survive an 8% day-30 baseline? If no, fix retention before you build the app.
If you answered yes to most of these, you have a real case for native. If you answered no, you have a great case for a PWA that costs a third as much and ships in a quarter of the time.
We’ve built both. We’ll tell you honestly which one fits your business. Talk to us about your mobile strategy — we’ll either save you $100k or build you something users actually open on day 30.
