In this article
Almost every app project we scope starts with the same question, usually asked in the first ten minutes: should we build separate iPhone and Android apps, one app that runs on both, or skip the app stores entirely and build something in the browser? There is no universally right answer. There is usually a right answer for your project, though, and it tends to become obvious once you look at what the app actually has to do.
The three options in plain English
Native apps
A native app is written specifically for one platform: Swift for iPhone and iPad, Kotlin for Android. You end up with two codebases, built by people who know each platform well. In return you get full access to everything the device can do on the day Apple or Google releases it, and an app that looks and behaves exactly the way users of that platform expect.
Cross-platform apps
Frameworks such as Flutter, React Native and Kotlin Multiplatform let one team write most of the code once and ship it to both stores. How much is shared varies. Flutter and React Native usually share the interface as well as the logic, while Kotlin Multiplatform is often used to share the business logic and keep each platform's interface native. Either way, you maintain one main codebase instead of two.
Progressive web apps
A progressive web app (PWA) is a website built to behave like an app. Customers can add it to their home screen, it can work offline for some tasks, and it can send notifications. There is nothing to submit to an app store and updates go live the moment you deploy them. The trade-off is that browsers still expose less of the phone than native code does, and some customers simply look for you in the App Store first.
How they compare
| Consideration | Native | Cross-platform | PWA |
|---|---|---|---|
| Codebases to maintain | Two | One (mostly) | One |
| Access to new OS features | Immediate | Usually quick, sometimes needs native code | Limited and slower |
| App store presence | Yes | Yes | No (or via wrappers) |
| Typical relative build cost | Highest | Middle | Lowest |
| Best suited to | Hardware-heavy, flagship consumer apps | Most business and customer apps | Simple tools, portals, early validation |
When native is worth the extra cost
Native earns its keep when the app leans hard on the device. Think continuous Bluetooth connections to equipment, heavy camera or augmented reality work, background location tracking that has to be reliable, or deep integration with things like Apple Watch, widgets and Siri. It also makes sense when the app is the product and you are competing on polish with well-funded rivals.
If none of that describes your project, two native teams can mean paying twice for the same feature, twice a year, for the life of the app. That cost is easy to underestimate at the start.
A useful test: list the five features your app cannot launch without. If every one of them could be built as a good website, start by asking whether you need an app at all. If two or more need deep device access, you are probably looking at native or cross-platform.
Why cross-platform is now the default for most businesses
A few years ago cross-platform apps had a reputation for feeling slightly off: scrolling that stuttered, buttons that looked like neither iOS nor Android. That reputation is mostly out of date. Flutter and React Native are mature, and JetBrains declared Compose Multiplatform for iOS stable in May 2025, which made Kotlin a realistic option for sharing interface code too.
For booking apps, customer portals, field service tools, loyalty apps and internal business apps, a well-built cross-platform app is indistinguishable from native to the people using it. One team, one codebase. Bugs get fixed once.
The caveat is that "cross-platform" does not mean "no platform knowledge". Someone on the team still needs to understand Apple and Google's review rules, push notification setup, signing certificates and the yearly OS updates.
When a progressive web app is the smarter first step
PWAs are underrated. If you are not yet sure customers will use an app regularly, a PWA lets you find out without paying for two store listings, review cycles and native builds. They also suit internal tools where you control which devices staff use, and customer portals that people visit occasionally rather than daily.
Where PWAs struggle is discoverability and trust. A customer who searches the App Store for your brand and finds nothing may assume you do not have an app. Some device features remain awkward or unavailable in the browser, particularly on iPhone.
Questions to answer before you choose
- Who are the users? Customers on their own phones behave differently from staff on company devices.
- How often will they open it? Daily use favours an installed app. Monthly use often does not justify one.
- Which device features are essential? Be strict here; "nice to have" features should not drive the architecture.
- How will it be maintained? Budget for at least one round of updates a year when Apple and Google release new operating systems.
- What does success look like after six months? If you cannot answer this yet, a smaller first release is usually wiser than a bigger one.
Our view
For most of the UK businesses we speak to, a cross-platform app is the sensible default, a PWA is the sensible experiment, and native is the right call for a smaller number of projects with genuinely demanding device requirements. Starting with the wrong one is not fatal, but switching later costs real money, so it is worth an honest conversation up front.
At Clickshow, we build iOS, Android and cross-platform apps for businesses across Birmingham and the UK, and we are just as happy to tell you when a web app will do the job. If you would like a second opinion on your plans, our web and mobile app development page sets out the options and typical starting prices.
