Have a Mobile App Built: Native, Cross-Platform or Web App?

The question almost always arrives as a wish for an app. The right answer rarely hangs on the favorite technology and almost always on a number nobody likes to say out loud: the maintenance cost over five years.

Native, cross-platform or web is not a matter of taste but a cost and need decision.

The real cost driver is not the build

Two native code bases (iOS and Android) plus a backend are not double but permanently multiple effort: two languages, two release cycles, every change twice, every bug twice. The build is one-time, the maintenance is forever. Exactly here the price is decided, not in the first sprint.

The three options classified honestly

1. Native (Swift / Kotlin)

Best performance, full device functions, best store integration — and the highest running cost. Sensible when deep device functions or maximum performance are the real requirement, not the wish.

2. Cross-platform (e.g. React Native)

One code base for both stores, good performance for most business apps, significantly lower maintenance. The pragmatic middle path when store presence is needed but two native teams cannot be justified. React experience often carries directly here (see Web app with Next.js).

3. Web app / PWA

No store hurdle, one code base, fastest live and cheapest to operate — as long as offline and deep device functions are not a hard requirement. For many internal B2B processes the honest default choice (see PWA or native app?).

The question before technology: where is the user?

A field team without a stable network, a warehouse with scanners, a customer who submits something once a quarter — those are three completely different requirements. The platform follows from the usage context, not from the org chart. Apple and Google additionally set store rules that are part of the project risk, not a formality at the end.

Who maintains this in two years?

The most uncomfortable, most important question. A native dual app nobody can maintain durably is more expensive than a slightly slower web app an existing team can carry. Technology you cannot maintain is not a solution but deferred debt.

Checklist before the mobile decision

Is the usage context clear (network, device, frequency)?
Is maintenance cost over five years counted, not just the build?
Is store presence a real requirement or a habit?
Are deep device functions really needed?
Is it clarified who maintains the app in two years?
Was web/PWA checked as default before deciding native?
Is the first step small and measurable, not the whole system?

Frequently asked questions

Isn't native always best? Technically often, economically rarely. The best technology you cannot maintain durably is the most expensive.

Is cross-platform enough for business apps? For the vast majority yes. Native peak performance is only needed where device or performance requirements truly force it.

What is the most common expensive mistake? Starting with two native code bases without having planned the maintenance effort over years.

Can we start with web and go native later? Often yes — if logic and data are cleanly separated from the frontend. That is exactly why the architecture question pays off at the start.

Conclusion

Native, cross-platform or web is not a technology question but a calculation: usage context, device need, store necessity, maintenance cost over years. Whoever first clarifies where the user is and who maintains it chooses the cheapest viable option instead of the most prestigious.

Next step

You want a mobile solution but not expensive dual maintenance? Start with a short assessment of your requirements. We clarify usage context and maintenance model — and pick the cheapest viable platform.

Sources

Apple Developer, App Store Review Guidelines — developer.apple.com
Android Developers, Guide to app architecture — developer.android.com
React, React 19 Release — react.dev