When you want an app for iOS and Android, one of the first questions is “how do we build it?”. The answer affects the cost, the timeline, the app’s speed and how easily you’ll update it two years from now.
There are, broadly, three paths: native apps, a cross-platform app or a hybrid app, which combines a web app with the phone’s native features. None of them is best in every situation.
Native apps: one for each platform
The iOS app is written in Swift, the Android app in Kotlin, each with the platform’s official tools.
What you gain:
- the best performance and the smoothest animations;
- full access to the phone: camera, sensors, Bluetooth, notifications, background work;
- new operating system features, available from day one;
- the look and behavior each platform’s users are used to.
What you pay: two separate apps, so almost double the work in development and in every update.
It’s worth it for apps where the phone experience is the product itself: games, photo and video apps, apps that work offline a lot or interact heavily with hardware.
Cross-platform: a single codebase
With Flutter or React Native, you write the app once and get two apps, for iOS and Android.
What you gain:
- a single codebase, so lower development cost and time;
- near-native performance for most apps;
- the same logic and look on both platforms.
What you should know:
- the phone’s special features are used through intermediate modules; when a module is missing, native code gets written;
- you depend on the chosen framework and its updates;
- for new operating system features, you sometimes wait for the framework to support them.
It’s the right choice for most business apps: accounts, lists, forms, bookings, orders, payments.
The hybrid app: the web plus native features
The third option starts from a simple observation: many businesses already have a good web app, and on the phone they need it, plus a few things only an app can do well.
That’s how we built the apps for inMotion, the management platform for private schools and studios (dance, football, karate and many more). Members and staff see their memberships, classes, payments and documents from their phone, and every session starts with a quick check-in using a QR code.
Specifically, the inMotion app has two parts:
- a native app for iOS and one for Android, which contain a WebView, a window into which the web app’s interface loads, straight from the server;
- a native bridge between the interface and the phone: when the user taps “Scan”, the interface asks the native app to open the camera, and the QR code is scanned natively, with an audible and visual confirmation. Push notifications and PDF downloads are native as well.
What you gain:
- the app is always up to date. The interface loads from the server, so a new feature or a fix reaches every user immediately, without waiting for a new version in the app stores;
- a single codebase for web, iOS and Android. The same screens, the same data, the same rules, wherever the user works;
- the phone’s features are native, so fast and reliable where it matters: the camera, notifications, files;
- lower cost than three separate apps.
What you should know:
- the app needs an internet connection for its interface; it isn’t suited to apps that must work offline a lot;
- for complex animations or very heavy screens, a native interface remains smoother;
- an app that only displays a website isn’t accepted. Apple’s rules explicitly require an app to offer more than “a repackaged website”1. That’s why the native features aren’t a whim but the reason the app exists: the scanner, the notifications and the documents make it a tool, not a browser.
And the option without an app store
For some projects, you don’t even need an app in the App Store or Google Play. An installable web app (PWA) can be added to the phone’s home screen and, since iOS 16.4, can receive notifications on iPhone too2. It does, however, have more limited access to the phone’s features than a native app.
In short
| What we compare | Native | Cross-platform | Hybrid (web + native) |
|---|---|---|---|
| Codebases to maintain | two | one | one (web), plus a small native part |
| Development cost | highest | medium | lowest, if the web app already exists |
| Performance | best | very good | good; native where it matters |
| Access to the phone | full | almost full | whatever the native bridge exposes |
| Updates | through the app stores | through the app stores | the interface, instantly, from the server |
| Offline | full | full | limited |
How we choose
Before the technology, we work out together what the app has to do and for whom:
- Already have a web platform and need it on the phone, plus a few native features? A hybrid app is usually the most efficient.
- A new app with ordinary business logic? Cross-platform, with Flutter or React Native.
- The phone experience is the product itself, you work offline a lot or with hardware? Native.
We build apps in all three ways and publish them on the App Store and Google Play. We recommend the option that gets you the right app at the lowest maintenance cost, not the trendiest one.
Apple, App Store Review Guidelines, guideline 4.2 (Minimum Functionality): the app should include features, content and UI that elevate it beyond a “repackaged website”. ↩
WebKit, Web Push for Web Apps on iOS and iPadOS. ↩
Cover image: Dennis Cortés, Wikimedia Commons (CC0)
.jpg){kind=link}