“Should we build an app?” is one of the most expensive questions a business can answer badly. The choice is usually presented as website versus app, when there are three options, and the middle one suits more businesses than either extreme.
The three options
A responsive website works in a browser and adapts to screen size. Everyone can reach it via a link, and there is nothing to install.
A progressive web app is a website with additional capabilities. It can be installed to a home screen, works offline, loads almost instantly on repeat visits, and can send push notifications. It is still reached by a URL and requires no app store.
A native app is built specifically for iOS and Android, distributed through the app stores, and has full access to device hardware.
Start with the question that decides most cases
How often will the same person use this?
If the honest answer is once or twice, a website is correct. Nobody installs an app to read your service pages or make a single enquiry, and building one wastes money on an audience that will never return.
If the answer is weekly or daily, installation becomes worth asking for, and a PWA or native app starts to make sense.
This single question resolves a large share of these decisions before any technical discussion begins.
When a responsive website is right
- Most visitors arrive once, get what they need, and leave.
- Discovery matters most, and you want search engines to index everything.
- Your content is primarily informational.
- Budget is limited and should go into content and reach.
Most business websites, including service businesses, professional firms and brochure sites, belong here. Wanting an app is often really wanting a better website.
When a progressive web app is right
- Customers return regularly: ordering, booking, checking status, managing an account.
- You want home screen presence without app store friction.
- Offline or poor-connection use matters, such as staff in the field or customers on transit.
- You want to ship updates instantly to everyone.
- You cannot justify maintaining two separate native codebases.
Common good fits: ordering systems, booking tools, member portals, internal staff tools, dashboards, and content platforms with returning readers.
What you gain
One codebase serving Android, iOS and desktop. No app store review delays or rejection risk. No store commission. Updates that reach every user the moment you publish, rather than waiting for people to update. Discoverable by search engines, unlike a native app. Shareable by link.
What you trade
Some native capabilities remain limited, particularly on iOS. You lose app store presence as a discovery channel, though for most businesses that channel is far weaker than assumed. And you must ask people to install through a browser prompt, which is less familiar than an app store button.
When a native app is right
Native remains the correct answer when you genuinely need:
- Advanced camera control, such as real-time processing or AR.
- Continuous background location tracking.
- Bluetooth or connected hardware peripherals.
- Heavy on-device computation or 3D graphics.
- Deep integration with system features such as health data or contacts.
- App store discovery as a genuine acquisition channel, which is realistic for consumer products and rarely for B2B services.
If none of those describe your product, a native app is likely to cost considerably more and deliver little a PWA would not.
The app store question people get wrong
Businesses often want a native app for app store visibility. It is worth being realistic about this.
The stores contain millions of apps. Being listed does not mean being found. Almost all downloads come from people who already knew the app existed, usually driven by the company’s own marketing. For most small and medium businesses, the app store is a distribution channel rather than a discovery channel.
Meanwhile, a PWA is indexed by search engines. If discovery genuinely matters, that is often the stronger position.
Does a PWA work on iPhone?
Yes. Progressive web apps install and run on iOS through Safari, including home screen installation and offline operation. Support has improved considerably.
Some capabilities remain more limited than on Android, so the honest approach is to confirm your specific requirements before committing rather than assuming parity. If your project depends on a capability that is constrained on iOS, that should surface during scoping, not after build.
A practical way to decide
- How often will the same person use this? Rarely means website.
- Do you need hardware access a browser cannot provide? Yes means native.
- Is offline use genuinely necessary? Yes points to PWA or native.
- Can you fund and maintain two native codebases indefinitely? No points strongly to PWA.
- Is being found by search important? Yes favours web or PWA.
- Is app store presence a real acquisition channel for you? Be honest. Usually not.
A sensible sequence for many businesses: build an excellent responsive website first, add PWA capabilities once you can see returning usage in your analytics, and consider native only when you hit a specific limitation you can name.
What to take away
Choose by usage pattern and technical requirement, not by which sounds most impressive. Rare visits mean a website. Regular return visits without special hardware needs mean a progressive web app, which for most business tools is the sensible middle ground. Genuine hardware dependence or consumer-scale app store distribution means native.
Beware anyone who recommends a native app before asking how often your customers will actually use it.
We build all three and will tell you when the cheaper option is the right one. See our approach to progressive web app development and website development, or describe what you are building and we will give you a straight answer.
