This choice gets made in a single meeting and then lives with you for years. It decides how much the app costs, how fast you ship it, who can work on it afterward, and how well it sits in the user’s hand. And because it’s technical, it often gets settled before you’ve even worked out what you’re building. That’s a shame, because the answer almost always follows from what the app needs to do, not from what’s currently in fashion.

There are essentially three options: native development separately for each platform, cross-platform with one shared codebase, and the cheap third path of a web app. Let’s take each one honestly.

What native development is and when it pays off

Native means you write the iOS app in Apple’s own language and tools (Swift, these days usually with SwiftUI) and the Android app separately in Kotlin with Jetpack Compose. Two apps, two codebases, often two different people too, because someone who knows Swift usually isn’t great at Kotlin and vice versa.

What you get for it is the best a phone can do:

Performance. Nothing between your code and the system. Smooth animations, demanding graphics, games, live video or audio processing. This is where native wins hands down.
New system features. When Apple unveils something new in the fall, a native app can have it on day one. Cross-platform usually has to wait a while.
The feel of it. The app behaves exactly like the rest of the system, because it comes straight out of it. Gestures, transitions, the little things people don’t see but do feel.

Two codebases mean roughly double the work, both to build and on every change afterward. Fix a bug on iOS and you have to fix the same one on Android. For a small team on a tight budget, it’s the most expensive path you can pick.

Cross-platform: one codebase for both platforms

Cross-platform tools (React Native, Flutter, and Expo on top of React Native) solve exactly that two-codebase pain. You write the app once and it runs on both iOS and Android. One team works on it, you fix bugs once, you add features once.

Cost and speed. Significantly cheaper and faster out the door than two native codebases. For the vast majority of ordinary apps (orders, bookings, loyalty programs, internal tools, content, a simple community) it’s more than enough.
One team. You don’t need to hire separate iOS and Android people. For a smaller company, that’s a fundamental difference.
A look that fits. Modern tools can produce an app the average user can’t tell apart from a native one. Expo also simplifies development a lot and gets you off the ground faster.

The catch is in the edge cases. When you need something very specific from the system that the framework doesn’t support yet, someone has to write you a so-called bridge into native code. That’s extra work, and occasionally it takes a while before the tool catches up with a new version of the system. And you’re relying on the team behind the framework to keep developing it. With React Native (Meta), Flutter (Google), and Expo, that’s a good night’s sleep today, not a risk.

PWA as a cheap third path

We met the PWA back in the first lesson as a category in its own right. It belongs here too as a technology choice that often gets overlooked in this discussion: it’s the cheapest option of all, one codebase for absolutely everything including desktop, and no app-store approvals.

The limits are real, though. On an iPhone a web app still has its options clipped (limited notifications, no access to a range of phone features), and people won’t find you in the App Store or Google Play, because you simply aren’t there. For a tool that’s used mainly from a link or a QR code (a restaurant menu, a simple booking, an internal helper), a PWA is smart and saves money. As a route to “an app in the store that people search for,” it isn’t enough.

iOS or Android: where to start and why

Across most of Europe, Android leads on sheer number of phones, with iPhones a clear minority. But the number of devices isn’t the same as money. iOS users tend, on average, to be more willing to pay, whether for the app itself, a subscription, or in-app purchases. That’s why apps meant to earn money often launch on iOS, even though there are fewer phones.

A practical guide, with no magic numbers:

The app needs to earn from day one (subscriptions, purchases). Consider starting on iOS, where money gets spent more readily.
You’re aiming for the widest possible reach, or a specific group that’s on Android. Start with Android, or go straight to both via cross-platform.
You don’t know, or you want both. That’s exactly why cross-platform exists. You ship to both platforms at once without paying twice.

Plenty of teams start on one platform mainly so they can learn fast, on a smaller audience, what bothers people about the app, and only then polish the second one. Less work in hand, faster feedback.

Choose based on where you are

A game, demanding graphics, live video or audio, or an app built on the newest system features? Native. Here it pays off even at the higher price.
An ordinary app for a business or service, and you want it on both iOS and Android without paying twice? Cross-platform, typically React Native or Flutter.
A simple tool people reach from a link or QR code, and you don’t need to be in the store? Consider a PWA, you’ll save the most.
Not sure, and the budget’s tight? Cross-platform, and start on one platform.

At FRGTN we go with React Native and Expo for most projects. Not out of fashion, but because it keeps the budget under control and gets the app onto both platforms from a single codebase. We reach for native development when a project genuinely needs it, not on principle. And as with websites, the rule holds: the most expensive choice isn’t the one with the highest number on the invoice, it’s the one you rebuild from scratch a year later because you picked it on trend instead of on what the app needs to do.