Cross-platform

Cross-platform app development: what it actually costs you

You want one app that works on iPhones and Android phones, and you would rather not pay for it twice. That is cross-platform development. The useful question is not whether it works, because it plainly does. It is what you trade away, and whether that trade is right for the app you have in mind.

What cross-platform actually means

Building natively means two separate apps: one written in Swift for iOS, one in Kotlin for Android. Two codebases, two sets of bugs, two people or teams, and every feature specified, built and tested twice.

Cross-platform means one codebase that produces both. You write a screen once and it appears on both phones. That is the whole idea, and every option further down is a different answer to the same question: how much can you share before the result stops feeling like a real app?

The options differ in how much of the phone they keep. At one end your screens are built from the platform's own interface components and behave exactly as each phone expects. At the other end your screens are a web page. Each step along that line shares a little more work and gives up a little more of the platform, and where you stop is the decision.

What you genuinely gain

• One team instead of two. For a founder this is usually the deciding factor. You are hiring, briefing and paying for one set of people, and they can answer questions about the whole product.
• A bug gets fixed once. The same goes for a feature, a copy change, a price change. Over a year of iterating this compounds more than the initial build saving does.

What you should not expect is half the cost. What does not shrink is review on two stores, permissions and notification behaviour that genuinely differ between the platforms, device testing, and two sets of screenshots and listings. The saving is large. It is not fifty per cent.

What you give up

• New operating system features arrive later. When Apple ships something in September, native apps can use it that week. Cross-platform frameworks have to expose it first, which takes somewhere between weeks and a release cycle.
• Some native code is usually still needed. Most apps eventually want one thing the framework does not cover out of the box. This is normal rather than a failure, and the next section explains why it matters far less than it sounds.
• Graphics-heavy and audio-heavy apps suffer. Not ordinary animation, which is fine everywhere. Real-time 3D, video effects and low-latency audio are where the abstraction starts costing you.

The gap is narrower than it looks

The most common worry about going cross-platform is hitting a wall: some feature the framework cannot do, discovered halfway through, with the whole app now built the wrong way.

That wall mostly does not exist, and it is the single most useful thing to understand here. Every option that produces a real app, which is all of them except the progressive web app, has a way for a developer to drop down and write actual native code, in Swift or Kotlin against the platform's own tools, and expose it to the rest of your app as if the framework had always supported it. React Native calls these native modules, Flutter calls them platform channels, Capacitor calls them plugins, and Kotlin Multiplatform is built around the idea from the start.

So "the framework does not support that" is almost never a hard stop. It is a question of who writes one small native piece and what it costs, usually days rather than a rebuild. Anything the phone can do, your cross-platform app can do.

This gap has also been closing rather than widening. Each of these frameworks has spent recent years making that native bridge faster and easier to write, and the newest platform features tend to arrive as community packages within weeks rather than waiting for the framework itself.

What that changes for you is the question worth asking. It is not "can cross-platform do this", because it almost certainly can. It is how much of this app would end up being native code anyway. If the answer is one screen or one feature, build cross-platform and pay for that piece. If the answer is most of the app, you have lost the saving and you should build native.

When native is still the right answer

Start with the simplest case, and the one that gets over-thought most often: you only need one platform. Cross-platform exists to solve exactly one problem, which is paying twice to be on two phones. If you are shipping to one platform and intend to stay there, that problem does not exist. Adding a framework to solve it buys you nothing and costs you a layer of machinery, a dependency on somebody else's release cycle, and a wait for every new platform feature. Build native, and stop reading.

The only word worth examining there is "intend". Plenty of founders say iOS only and then add Android in year two, and that second app starts from nothing. If you can already see that coming, you have two platforms today whatever your launch plan says.

The remaining cases are about the app itself, and by the test above they are the ones where so much of it would end up native that the saving disappears.

• Games and anything 3D. Use a game engine, not an app framework. This is not a close call.
• Deep or unusual device access. Continuous background location, complex Bluetooth peripherals, health sensors, camera pipelines doing real work rather than taking a photo.
• Apps where the platform's own look is the product. Utilities that need to feel like part of the operating system, or anything leaning on the newest system widgets and integrations.
• You already employ iOS and Android developers. If both skill sets are already on the payroll, the main saving has already been spent.

The six real options

For each one: the language, and therefore who you can hire; who is behind it; what it is genuinely best at; and when to avoid it. They run roughly from the ones that keep the most of the platform to the ones that keep the least.

React Native

JavaScript and TypeScript, built by Meta, which uses it in its own apps. It maps your code onto the platform's real interface components, so the result behaves the way each phone expects.

• Hiring pool: the largest overlap with web development of anything here. JavaScript already runs the web, so the people who build your website can plausibly work on your app, and replacing someone later is easier than with any other option on this list.
• Best at: apps that should feel native on both platforms, teams that already have web skills, and anything needing a wide range of third-party integrations.
• Avoid when: you need heavy real-time graphics, or your existing team is strong in Kotlin or C# and has no JavaScript at all.

Flutter

Dart, built by Google, which uses it in its own products. Rather than using the platform's components it draws every pixel itself, so your app looks identical everywhere, including on older devices.

• Hiring pool: Dart is used almost exclusively for Flutter, so it is a separate hire from a smaller pool than JavaScript.
• Best at: design-led products where your brand's exact look matters more than matching each platform's conventions.
• Avoid when: the hiring pool is your main risk, or you want the app to feel like it belongs to the phone rather than to you.

These two are the most common finalists, and the differences are narrower than most comparisons suggest. That one is written up separately in React Native or Flutter.

Kotlin Multiplatform

Kotlin, built by JetBrains, stable since late 2023 and used in production by Netflix, McDonald's and Cash App. It comes in two modes: share only the business logic and keep a fully native interface on each platform, or share the interface too using Compose Multiplatform, which reached stable support for iOS in May 2025.

• Hiring pool: large, but it is an Android hiring pool. In the shared-logic mode you still need someone who can write the iOS interface, so the two-skill-set problem does not fully go away.
• Best at: companies that already have Android and iOS developers and want to stop writing the same business rules twice.
• Avoid when: you are a founder with no mobile team yet. The mode that saves the most is the one that needs the most existing in-house skill.

.NET MAUI

C#, built by Microsoft, and the successor to Xamarin. If you have been told Xamarin is an option, it is not: support for it ended on 1 May 2024 and existing apps are expected to move to MAUI.

• Hiring pool: C# is large and healthy, but its centre of gravity is corporate rather than startup mobile. Finding C# developers is easy; finding ones who have shipped consumer apps is harder.
• Best at: organisations already running .NET. If your back end is C# and your team is a Microsoft shop, this keeps everything in one language and one set of tools.
• Avoid when: you have no existing .NET investment. Choosing it from scratch means hiring into a pool that rarely overlaps with people who have taken consumer apps through both stores.

Ionic with Capacitor

Ordinary web technology: HTML, CSS and JavaScript. The app you install from the store is a real app, and what it displays is a web page inside an invisible browser window. Capacitor is the piece that lets that web page reach the camera, location and notifications.

• Hiring pool: the largest of any option here, because it is simply web development. It is also the least mobile-specialised, which cuts both ways.
• Best at: getting an existing web application into the stores, and content-led apps that are essentially a good mobile website with some device access. If you already have a web app, this is the shortest path there is.
• Avoid when: the app has to feel genuinely native. Because the interface is a web page, heavy gesture work, complex animation and long lists are where people start describing it as "a bit like a website", usually without knowing why.

Progressive web app

The same web code as the option above, without the shell around it. A website built so it can be installed to the home screen, work offline and behave like an app once opened. It costs a fraction of the others, it updates instantly with no store review, and people can start using it by following a link rather than committing to a download.

It can still reach the stores, which surprises people. Google Play accepts them officially, through a mechanism called a Trusted Web Activity, and Google's own Bubblewrap and Microsoft's PWABuilder will package one for you. The App Store allows them as long as the app does real work rather than being a repackaged website. The Microsoft Store takes them too.

Notifications work, with conditions. Since iOS 16.4 a web app added to the home screen can send push notifications. But the user has to add it to the home screen first, which few people do unprompted, there is no background push, and web push is not available on iOS in the European Union.

• Hiring pool: the same people who build your website, and no mobile specialism required at all.
• Best at: proving that anyone wants this before you spend properly, and anything used occasionally rather than daily: content, forms, bookings, dashboards.
• Avoid when: iOS is a serious market and notifications matter, or your users are in the EU. Likewise if you need home screen and lock screen widgets, camera or sensor access, or in-app purchases through the stores.

This is the option most worth taking seriously before the other five, because it is the only one that changes the size of the budget rather than how the money is spent. Nobody selling app development suggests it, which is precisely why it is worth a moment.

How to actually choose

The option matters less than founders expect. One thing matters more than any of them: who is going to maintain this in two years. Every option above can produce a good app. None of them survives the person who built it leaving with nobody available to pick it up.

1. Rule out the exceptions first. If you are in the native section, stop there. If a web app would do, stop there and save most of your budget.
2. Start from the people, not the technology. If you have a team, their language usually decides this for you. A .NET shop should look hard at MAUI. A company with Android and iOS developers should look hard at Kotlin Multiplatform. A web team should look hard at React Native.
3. If you have no team, optimise for replaceability. The question is not which option is best, it is which one gives you the most people who could take over. That points at the largest hiring pools.
4. Then pick whoever has actually shipped. Someone who has taken an app through both store reviews in your second-choice option will beat someone who has never shipped in your first. What goes wrong is mostly what all of these have in common.

What it costs

What surprises people is not the build, it is the year afterwards: store listings, review rejections, the first month of real users, and the operating system updates that arrive whether or not you planned for them. That is written up properly in what a React Native app costs to build, and most of it applies whichever option you choose.

If you land on React Native

Where I stand: I build React Native apps, and I chose it for my own products before I built anything for anyone else. Wallety and Qurany are both React Native, both mine, both live on the App Store and Google Play, so you can apply the "has this person actually shipped" test to me directly.

That does not make it right for you. If this has pointed you at native, at a web app, or at one of the other options, that is a good outcome and I would rather you got there now than three months in.

But if you have worked through it and React Native is where you land, that is exactly what I do. Send me a paragraph about what you want to build, not a specification, and you will get back what I would build first, what it would cost, and whether I think I am the right person for it.

hello@orbitapps.net, or read more about working with me on React Native.

Related

React Native or Flutter is the head-to-head between the two most common finalists. What a React Native app costs to build covers the money. And how to hire a React Native developer covers the five questions worth asking whoever you choose.