"We need an app for iOS and Android" is one of the most common first sentences we hear. It's also one of the most expensive to take literally.
There are three ways to put your business on someone's phone, and they differ in far more than the build price. They differ in how fast you can change things, how many people you need to maintain them, and how many of your customers will ever actually use them.
This guide explains the three options without jargon, and ends with a simple test you can run before you talk to any studio, including us.
The three options in one sentence each
Web app. A website that behaves like an app: it runs in the browser, works on every phone and computer, and can be saved to the home screen.
Cross-platform app. One codebase that produces real apps for both the App Store and Google Play. The most common tools are React Native and Flutter.
Native app. Two separate apps, one written specifically for iPhone and one for Android, each built with that platform's own tools.
1. Web app
A modern web app is not the slow mobile website you remember. It can work offline for simple tasks, send notifications on most devices, and sit on the home screen with its own icon. This type is often called a PWA (progressive web app).
What it's good at
One version for every device, including desktop
Updates go live instantly, with no App Store review
Nobody has to download anything, so there's no barrier on the first visit
Usually the lowest build and maintenance cost of the three
Where it falls short
Weaker access to phone hardware: advanced camera work, Bluetooth devices, background tasks
Some capabilities on iPhone have historically arrived later or work in a more limited way than on Android
It isn't listed in the app stores, so you lose that channel of discovery and that badge of legitimacy
Few people add a website to their home screen, even when they could
Best for: booking, client portals, order tracking, internal tools, anything a customer uses occasionally.
2. Cross-platform app
A cross-platform app is a real app in both stores, built from a single shared codebase. For the large majority of business apps (bookings, accounts, catalogues, payments, messaging, loyalty) users can't tell it apart from a native one.
What it's good at
One team, one codebase, two stores
Most features are built once rather than twice
Full presence in the App Store and Google Play
Push notifications, payments, maps and camera all work well
Where it falls short
Heavy graphics, games and very performance-sensitive features are harder
Brand-new iOS and Android features sometimes take a while to become available
You still go through two store review processes and maintain two store listings
Best for: most business apps. If you're unsure, this is usually the right default.
3. Native app
Native means two separate products: one for iPhone, one for Android. Each uses its platform's own language and tools, so each gets the best possible performance and full access to the device.
What it's good at
The smoothest performance and animations
Full, immediate access to every device capability
New platform features are available on day one
Where it falls short
Every feature is built twice, tested twice and fixed twice
It usually needs specialists for each platform, which means a bigger team over time
The two versions tend to drift apart unless someone actively keeps them in sync
Best for: apps where the app itself is the product, heavy use of the camera, AR or connected hardware, and cases where performance directly drives revenue.
The short version
A web app has one codebase, isn't in the stores, costs the least to build and run, updates instantly, and asks nothing of the customer. Its weak spot is limited access to the phone itself.
A cross-platform app also has one codebase, but lives in both stores and gets good access to the phone. It costs more than a web app and every update goes through store review.
A native app has two codebases, full access to the phone and the best performance. It is the most expensive to build and to keep running, because everything happens twice.
The test that decides most cases: how often will your customer open it?
This one question settles more decisions than any technical comparison.
About once a month or less (a cleaning booking, a car service, a haircut): build a great web app. Nobody keeps an app on their phone for something they do ten times a year, and every extra step between "I need this" and "booked" loses customers.
Every week or more (ordering, a loyalty programme, a fitness routine, anything with a daily habit): an app starts to pay off. People keep it on the home screen, notifications bring them back, and repeat use is where the value is.
Every day, as part of someone's job (a courier, a technician, a field sales rep): an app is almost always worth it, because it's a work tool used hundreds of times.
After that, three more questions refine the answer:
Do you need phone hardware beyond the basics? Bluetooth devices, advanced camera features or background location all push you towards an app, and in the most demanding cases towards native.
Do notifications matter to the business model? If bringing people back is central, an app gives you the most reliable way to do it.
Does being in the App Store matter to your customers? In some industries a store listing works as proof that you're a real, serious business.
Costs people forget
The build is only the first invoice. Plan for these from the start:
Store accounts. Apple's developer programme costs $99 a year. Google Play charges a one-time $25 registration fee.
Yearly OS updates. Every autumn new versions of iOS and Android arrive, and apps usually need some adjustments to keep working properly. This is not optional work.
Store reviews. Every app update waits for approval. Usually that takes a day or two, and occasionally longer, including when you're trying to ship an urgent fix.
Maintenance for two platforms. With native, every bug can exist twice, and every fix is paid for twice.
A web app avoids most of this, and that's a real part of its value, not just a technical detail.
Three mistakes we see often
Building native because it feels premium. Customers judge an app by whether it's fast and easy to use, not by the language it was written in. Most of the "premium feel" comes from design decisions, and all three options can deliver those.
Building an app before the website works. Most new customers find you through search first. If the website can't take a booking, an app won't fix that, because most people will never get as far as downloading it.
Assuming people will download it. Every install costs the customer effort. An app has to earn a place on the home screen, and for services people use occasionally it rarely does.
What we did for Pachaca
For Pachaca, an on-demand cleaning service in Kyiv, we built iOS and Android apps, a web booking service and the internal system the operations team runs on.
The apps are cross-platform, built with React Native. The client needed to be live on both stores quickly, and one shared codebase got them there without building every feature twice. We made the same call on the rest of the stack: NestJS on the backend for fast delivery, and MongoDB for the database, which comfortably covers what the service needs. We picked each tool for the job in front of us, not for the most impressive-sounding architecture.
The web booking service matters as much as the apps. Many customers book once and don't come back for a month, and for them the fastest route is a browser, not an install.
Before you talk to a studio
Answer these five questions in writing. They'll make any quote more accurate and any conversation shorter:
How often will a typical customer use it?
What's the one action they must be able to do in under a minute?
Do you need anything from the phone beyond the screen, notifications and payments?
Who will update the content: you or a developer?
What budget do you have for the first year after launch, not only for the build?
If a studio recommends native or an app for both stores without asking you something like question 1, ask them why.
We build websites, web apps and mobile apps for iOS and Android. On the first call we'll tell you which option fits your business, including when the answer is the cheapest one. The call is free.