Native, cross-platform, or a PWA? How to choose how your app is built

“Should we build native or cross-platform?” is one of the first questions on any app project, and most of the answers online are the wrong shape for the person asking. They compare frameworks the way developers argue about them — benchmarks, ecosystems, and taste. If you’re commissioning the app rather than writing it, what you actually need is a way to match the build approach to what the app has to do and what it will cost to run for years.

One thing worth saying up front: whichever route you pick, most of an app’s cost is usually the backend nobody sees — the accounts, data, and business logic on a server. The framework decision below moves the number less than people expect, but it moves the reach, the timeline, and the maintenance commitment a great deal. (For the money side, see what a mobile app costs in South Africa.)

The four routes, quickly

Think of them as a spectrum from lightest and cheapest to heaviest and most capable:

• PWA (progressive web app). A web app, built once, that installs to the home screen, works offline, and can send push notifications. No app store, no store commission, instant updates.
• React Native. One JavaScript/TypeScript codebase compiled to real iOS and Android apps. The largest cross-platform community, and a natural fit alongside a React web front-end.
• .NET MAUI. One C# codebase for iOS and Android (and desktop). The evolution of Xamarin, and the strongest option when your backend is already .NET and Azure — one language, end to end.
• Full native. Two codebases — Swift/SwiftUI for iOS, Kotlin for Android. Maximum performance and the deepest access to each platform, at the highest cost.

When a PWA is the smart, cheap answer

Progressive web apps are underrated in South Africa specifically. Where mobile data is expensive and a large share of users are on mid-range Android, a PWA that skips a hundred-megabyte download, works offline, and updates itself silently can beat a native app on the only metric that matters early on: whether people actually install and keep using it. There’s no store approval to wait on, and no 15–30% store commission if you ever charge.

The honest limits: PWAs can now send push notifications on modern Android and iOS, but iOS still restricts some capabilities, and a PWA can’t reach every piece of device hardware or run heavy background work. If you need a store presence for credibility, or deep native features, a PWA is the wrong tool — but for a great many business apps, it is exactly right and by far the cheapest to reach real users with.

When cross-platform is the sweet spot

For most apps that genuinely need to be apps — in the stores, with push notifications, camera and location access, and reliable offline sync — cross-platform is the default worth beating. One codebase serves both iOS and Android, which is faster to build and cheaper to maintain than two native ones, while still producing real, store-shippable apps that feel native to users.

The choice between the two mainstream options is mostly about the rest of your stack:

• React Native if you want the largest ecosystem and community, or you already have a React web front-end and want to share people and patterns across web and mobile.
• .NET MAUI if your backend is C# / .NET on Azure. Sharing one language end to end — and often real code, like models and validation — removes a whole seam from the project. It’s the option we reach for most, because it’s where our stack lives.

When full native earns its cost

Native is the right answer when the app’s reason for existing is something only native can do well: heavy real-time graphics or 3D, augmented reality, games, intensive on-device processing, or a design that deliberately diverges between iOS and Android. Building both platforms natively roughly doubles the interface work compared with a single cross-platform codebase, so it earns that premium only when performance or platform depth is the whole point — not as a default.

The .NET MAUI angle — and what happened to Xamarin

If you’ve researched cross-platform on the .NET side, you’ll have seen Xamarin. It matters that Microsoft ended support for Xamarin on 1 May 2024. Its successor, .NET MAUI, carries the same idea — one C# codebase across platforms — into modern tooling. A new Xamarin build quoted in 2026 is a warning sign; the right .NET choice today is MAUI.

We work in the Microsoft ecosystem — C# and .NET on the backend, Azure for infrastructure — so for us .NET MAUI often means one team, one language, and shared code from the database to the phone. That’s a genuine cost and reliability advantage when the backend is already there. We’re candid about the trade-off, though: React Native has the bigger community and a wider pool of ready-made libraries, and for a JavaScript-first team it can be the more pragmatic pick.

What each route costs

Roughly, cost climbs as you move up the spectrum: a PWA is the cheapest way to reach users, cross-platform sits in the middle, and full native on both platforms is the most expensive because you’re building the interface twice. But remember the backend usually dominates the budget regardless of the front-end choice. We put real rand ranges — by complexity, with what drives each band — in the mobile app cost guide, and the wider software cost primer covers where projects spend time in general.

How we’d choose it with you

In practice the decision takes one honest conversation. We look at what the app must do, who your users are and what devices they’re on, whether you need a store presence, and what your backend already looks like — then we recommend the lightest route that meets the requirement, not the most impressive one. Often that’s a PWA or a cross-platform build; sometimes it’s native; occasionally it’s a PWA now and a native app once demand is proven. The goal is the same either way: spend the budget where it actually changes the outcome.

Frequently asked questions