"We need an app."
Nine times out of ten, when someone says this, they're picturing something in the App Store. A little icon on their phone. Downloads. Maybe even a rating with stars.
And nine times out of ten, that's not actually what they need.
This post explains why I usually steer clients toward web apps instead of native mobile apps, and the specific situations where native genuinely makes sense.
The Assumption Problem
There's a default assumption that "real" apps live in the App Store. If it's not downloadable, it's somehow lesser. A website pretending to be an app.
This assumption is outdated. It comes from the early smartphone era when browser capabilities were genuinely limited. That was fifteen years ago. Things have changed.
Modern web apps can:
- Work offline
- Send push notifications (with some iOS caveats)
- Be "installed" on your home screen with their own icon
- Access your camera, microphone, and location
- Run smoothly on any device, any screen size
- Feel fast and responsive
For most business tools, internal systems, and customer-facing utilities, that's everything you need.
I recently built a document redaction tool for a GDPR consultant. It uses AI to automatically detect and remove sensitive personal information from documents. Compliance work. Serious stuff. It runs in a browser. No App Store required. And for her most sensitive client work, I'm deploying a version that runs entirely on her local machine, so documents never leave her premises.
That's the flexibility web apps offer. Browser-based for convenience, locally deployed for maximum privacy, or both.
The Cost Difference Is Substantial
Building a native app means building for two platforms. iOS and Android have different languages, different design conventions, different testing requirements, different submission processes.
Even with cross-platform frameworks like React Native or Flutter (which let you write code once and deploy to both), native apps cost significantly more than equivalent web apps.
Rough comparison for the same functionality:
- Web app: £X
- Progressive Web App (enhanced web): £X + 20-40%
- Cross-platform native app: £X × 2-3
- Separate iOS and Android apps: £X × 4-5
That multiplier isn't arbitrary complexity for its own sake. It's real work: handling device-specific quirks, navigating app store requirements, testing on multiple devices and OS versions, maintaining two codebases (or one complex cross-platform codebase) instead of one straightforward one.
For a small business, that cost difference often means the choice between building something and building nothing.
The App Store Tax
Beyond development costs, the App Store ecosystem takes its cut.
Apple charges £79 per year just to have a developer account. Google charges a one-time £20, which is more reasonable.
Both take 15-30% of any in-app purchases or subscriptions. If your app sells anything, a significant chunk goes to Apple or Google.
And then there's the approval process.
Google Play is relatively quick. Submit your app, wait a few days, usually you're live.
Apple is Apple. Expect 1-3 weeks minimum. Expect rejections for reasons that seem arbitrary. Expect to resubmit and wait again. I've seen apps rejected for guideline violations that weren't violations, for bugs that weren't bugs, for reasons that were never clearly explained.
This isn't me complaining for the sake of it. It's practical reality. If you need something deployed quickly, or if you need to iterate rapidly based on user feedback, the App Store introduces friction that web apps simply don't have.
Progressive Web Apps: The Middle Ground
A Progressive Web App (PWA) is a web app with some extra capabilities that make it behave more like a native app.
Install it on your home screen and it gets its own icon. Launch it and it runs full-screen, no browser chrome. It can work offline if you've visited it before. It can send notifications (though iOS is still catching up here).
Users who don't want to install it can still use it in their browser. No app store required. No download barrier.
For many use cases, this is the sweet spot. Native-like experience for users who want it. Zero friction for users who just want to try it out.
When Native Actually Makes Sense
I'm not saying native apps are never the right choice. There are situations where they genuinely are.
You need App Store presence for discoverability.
If your users are likely to search the App Store for solutions, being there matters. A fitness app for general consumers, a game, a social platform. These benefit from the App Store as a discovery channel.
Business tools and internal systems rarely need this. Your users know where to find you.
You need background processing.
If your app needs to do things when it's not open, native gives you more options. Fitness trackers that count steps all day. Apps that sync data periodically. Location-tracking apps.
Web apps can do some background work, but native apps have deeper access.
You need specific device features.
Bluetooth connections to external hardware. NFC for contactless interactions. Deep integration with health data or other system features.
These require native. The web can't do them, or can only do them unreliably.
Your users genuinely expect a native experience.
For consumer-facing products in competitive markets, the polish and performance expectations might demand native. If you're competing with apps that have invested millions in their mobile experience, a web app might feel second-rate.
For business tools where function matters more than flash, this rarely applies.
The Questions I Ask
When someone comes to me wanting "an app," I try to understand what's actually needed.
Who will use this?
Your team? Your customers? The general public? Internal tools and customer-specific apps don't need App Store presence.
How will they find it?
If users search the App Store, you need to be there. If you'll give them a link directly, you don't.
What does it need to do with the device?
Camera and photos? Web can do that. Bluetooth peripherals? Probably need native. Background GPS tracking? Definitely native.
Is this even an app-sized problem?
Sometimes the answer is a Chrome extension, not a full app. Extensions are quick to build, cheap, and perfect when you need to do something useful on websites you already use. If the problem lives in your browser, the solution might too.
How quickly do you need to iterate?
If you're still figuring out what works, the web lets you deploy changes instantly. App stores introduce delay.
What's the budget reality?
Sometimes native is ideal but unaffordable. A well-built web app that actually gets built beats a perfect native app that never happens.
The Honest Recommendation
Most of the time, I recommend starting with a web app or PWA.
It costs less. It deploys faster. It works on every device. It avoids app store friction.
If it turns out native features are genuinely necessary, we can always build a native version later, probably sharing significant logic with the web app.
Starting native when you don't need to is expensive and slow. Starting web when native would have been better is... usually fine. The web version still works. You've just missed some features you might have had.
The asymmetry favours starting simple.
Your Situation
If you're considering an app project and aren't sure which approach makes sense, let's have a conversation.
I'll ask about your users, your requirements, your constraints. Usually within 20 minutes we can figure out which path is right.
No commitment. No sales pressure. Just a straightforward assessment.
Want to understand more about how app development works and what affects cost? See my full guide: Custom App Development
Related posts:
- What "Maintenance" Actually Means for a Custom App (coming soon)
- Do You Need an App or Just a Better Spreadsheet? (coming soon)
- The Hidden Costs of App Integrations (coming soon)