Native or Cross-Platform: How to Decide

The decision that costs the most is made first

Before a line of code is written, somebody decides whether the app will be native, meaning SwiftUI on iOS and Kotlin on Android, or cross-platform, meaning one codebase packaged for both stores. That decision sets the budget, the timeline and the ceiling on how good the app can feel, and it is usually made for the wrong reason.

The wrong reason is staffing. An agency with four Swift developers will explain why your app needs native. An agency built on React will explain why cross-platform is the modern approach. Both explanations are fluent, both are internally consistent, and neither is about your app.

Here is the honest version, including the part where the answer means less revenue for whoever is telling you.

What native actually buys you

Native means writing the app twice, in the language and toolkit each platform provides. It buys four things:

• Interaction quality. Gestures, scrolling, transitions and haptics behave exactly as the platform behaves, because they are the platform. This is felt rather than seen, and it is the difference people describe as an app feeling cheap without being able to say why.
• Access to everything, immediately. Camera pipelines, background processing, widgets, watch apps, biometric APIs, and whatever the platform shipped last month. No waiting for a bridge.
• Performance where it is doing real work. Anything continuous: video, live drawing, heavy lists, on-device processing.
• Long-term maintainability under platform change. When the platform changes, you are changing against the platform directly rather than waiting for a layer in between to catch up.

What it costs is the obvious thing. Two codebases, two sets of platform knowledge, two release cycles.

What cross-platform actually buys you

Cross-platform in our work usually means Capacitor, which packages an existing web application for both stores. It buys:

• One codebase for three surfaces. Web, iOS and Android from the same source. A fix ships everywhere at once.
• Dramatically less money for a first version. If you already have a working web application, a large part of the app already exists.
• Faster iteration. Most changes do not require a store review at all.

What it costs is the interaction quality above. On a content, forms and dashboards app, most users will never notice. On a gesture-driven app, they will notice within ten seconds and will not be able to tell you why they disliked it.

A test you can apply to your own app

Write down what a user does in the app in the first thirty seconds of a typical session. Then ask three questions about that.

Does it involve continuous input? Dragging, drawing, swiping between things, panning a map, scrubbing video. Continuous input is where a web layer is exposed, because every frame has to keep up. If your answer is yes, lean native.

Does it need to work with the device rather than on it? Camera pipeline, background location, offline sync, biometrics, widgets, notifications that do something more than open the app. The more of these, the more native earns its price.

Would a user be annoyed if it were a well-made website? This is the blunt version and it is the most useful. If the honest answer is that a fast, well-built web page would serve them nearly as well, then a native app is being commissioned for reasons that are not about the user.

Two examples from our own work. KeyNesta is a two factor authenticator, and it is native on both platforms. An authenticator lives in a moment where somebody is already irritated: mid-login, one hand, thirty seconds on a clock. The interaction is the product, so there was nothing to debate. A dashboard where a manager checks yesterday's numbers is the opposite case, and we would say so.

The second platform does not cost double

This is worth knowing before you receive a quote, because the assumption it corrects is expensive.

Going from one native platform to two is not twice the work. The backend is shared, the design is shared, the product decisions are already made, and the specification exists. In practice the second platform lands well below the first. If a quote treats iOS and Android as two full projects side by side, ask what exactly is being built twice.

The reverse is also true and less comfortable. A cross-platform build is not one third the cost of native just because there is one codebase. Store submission, device testing, notifications and offline behaviour all still have to be done per platform.

The parts everyone underestimates

Whichever way the decision goes, three things reliably take longer than the plan says:

Store submission. Certificates, signing, provisioning, listing copy, screenshots at the sizes each store insists on, and a review cycle that can reject you for a permission string. Most rejections are metadata problems that are entirely preventable, but only if somebody knows which ones to prevent.

Screens you did not design for. Android in particular spans a wide range of physical sizes and pixel densities. Working out what a layout does at the extremes is real work. The PPI calculator and the aspect ratio calculator are useful when you are sizing assets for that spread, and image compression matters more in an app bundle than on the web, because the user pays for it once at download time and again in storage.

Notifications. Everyone specifies push notifications in one line. Delivered properly, with per-platform behaviour, deep links into the right screen and a preference system, it is a feature in its own right.

Questions to ask whoever is quoting

Four questions will tell you more about a development partner than any portfolio:

1. Under what circumstances would you tell me not to build native? If there is no answer, the recommendation was made before they heard your requirements.
2. Whose developer accounts will the app publish under? The answer should be yours. Leaving an agency must never cost you your listing, your reviews or your users.
3. What happens at store rejection? Review responses and resubmission should be part of the engagement until the app is live, not a change request.
4. What does the second platform cost, separately? The gap between that number and the first platform tells you how much is genuinely shared.

Those answers are only comparable if every studio quoted the same project. A one-page brief that separates the must-haves from the later features does most of that work, and writing a software brief that gets an accurate quote walks through what to put on it.

If you want to talk it through against your actual requirements, that is what mobile app development covers, and where there is a web product alongside the app it usually starts as SaaS product development. The first conversation is free and sometimes ends with us recommending the smaller engagement.