Mobile app: native, cross-platform or PWA?

As soon as a mobile app project starts, one question comes up before the first mockup: should it be built native, cross-platform, or as a PWA? The answer drives the budget, the timeline, the performance and the ability to evolve the tool for years. It is an architecture decision, not a matter of taste.

The classic trap is to pick the trendy approach, or the one you already master, then dress that choice up with good reasons. The right method is the reverse: start from the app's real usage, its performance constraints and its target audience, then let those elements point to the most suitable approach. Here is how to reason, approach by approach, then the criteria that truly decide.

Three families, three logics

There are three broad ways to deliver an app on a phone. Native means writing a dedicated app for each system, with that system's own tools: one base for iOS, another for Android. Cross-platform shares a single codebase that produces both apps, through a framework like React Native or Flutter. A PWA, finally, is a website designed to behave like an app: it installs on the home screen and works even offline, without going through the app stores.

None of these families is superior in absolute terms. Each makes a different trade-off between performance, cost, reach and access to the phone's features. Understanding those trade-offs is the only way to choose knowingly, rather than inheriting a decision made too early.

Native: performance and full system access

A native app is written in the language each platform expects: Swift or Objective-C on Apple's side, Kotlin or Java on Android. It talks directly to the operating system, which gives it the best possible performance and immediate access to every feature of the phone: sensors, camera, fine-grained notifications, very smooth animations, advanced offline behaviour.

That quality has a price. Two platforms mean two codebases to write, test and maintain, often by different profiles. The upfront cost and the upkeep cost are therefore higher. Native makes sense when the mobile experience is the heart of the product, not a mere add-on, and when the slightest lag or limitation would be paid for in abandoned users.

When native is the right choice

• The app heavily uses the hardware: real-time camera, sensors, continuous geolocation, Bluetooth.
• Smoothness and response time are decisive: a game, editing, mapping, animated graphics.
• Mobile is the product itself, not an extension of a service that lives elsewhere.
• You aim for a flawless experience on each platform and accept its maintenance cost.
• Recent system features must be available the day they ship, without waiting for a third-party framework to support them.

Cross-platform: one codebase, two platforms

Cross-platform answers a simple frustration: why write the same app twice? With a framework like React Native or Flutter, you write a single codebase that produces the iOS and Android versions. You share the business logic, the screens and much of the testing. The time and budget saved are real, especially for an app focused on content, forms, lists and standard flows.

The trade-off sits at the edge cases. For features very specific to one platform or very demanding, you sometimes have to drop into native code as a complement, and the dependency on the chosen framework becomes a variable to watch over time. For the vast majority of service apps, this trade-off is strongly favourable: you cover both worlds with one team and one base, without sacrificing a quality the user would notice.

When cross-platform is the right choice

• You need to be present on both iOS and Android with a controlled budget and schedule.
• The app centres on content, flows and exchanges with a server, more than on the phone's hardware.
• You want to evolve both versions in parallel, without doubling the effort on every new feature.
• Expected performance is high but not extreme: most business apps fall into this case.
• A single team has to carry the product over time, without spreading itself across two separate bases.

PWA: the web that installs

A progressive web app, or PWA, is a website that adopts the codes of an app: installation on the home screen, full screen, notifications on some platforms, and offline behaviour thanks to local caching. It is distributed through a simple web address, without going through the app stores or their review processes. A single base serves both web and mobile.

Its limits come from its web nature: access to certain advanced phone features stays partial and varies across systems, and the absence of the stores can weigh when a store presence is part of the expected credibility. In return, the PWA is often the fastest and most economical way to put a useful tool into users' hands, and to evolve it without deployment friction.

When a PWA is the right choice

• You want a mobile presence that is fast, economical and easy to update.
• The same tool must serve on desktop and on phone, with a single base.
• Advanced hardware features are not at the core of the usage.
• Distribution through a simple web address is an advantage: no review wait, no update to get installed.
• You want to validate a usage with real users before investing in a heavier app.

The criteria that really decide

Once the three families are understood, the choice does not hinge on the technology itself, but on what the app has to do and for whom. The same questions come back on every project, and their answers almost always point to one approach rather than another. The mistake would be to decide on the tool first, then bend the need to fit the tool.

Take these questions in order. They start from usage, pass through performance and budget constraints, and end with the expected lifespan of the product. That last one is most often overlooked, yet it weighs heavily: an app lives, gets fixed and evolves well after it goes live.

The questions to ask before deciding

1. What does the app actually do, and which phone features does it truly need?
2. Are your users mostly on iOS, on Android, or evenly on both?
3. Is raw performance a vital criterion, or is a good level more than enough?
4. What budget and timeline are sustainable for the first version, then for maintenance?
5. Is a presence in the app stores essential to your credibility?
6. Who will evolve the app in two years, and with what team size?

The hidden cost: what comes after launch

The architecture choice is never a one-off decision: it commits the whole life of the app. A native base doubles the maintenance work but offers full control. A cross-platform framework saves precious time but ties the product to that framework's evolution. A PWA simplifies deployment but means living with the limits of the web. In every case, the real cost is not the launch, it is the years that follow: systems that change, security fixes, new features, scaling up.

That is why we build every custom app with the support that goes with it. At Horyond, every service includes a support subscription: hosting, a dashboard to follow usage, support, security and improvements over time. We first help you choose the right approach for your project, then we stay to make it last. Our promise fits in one sentence: we design your tools, and we stay. The best way to validate your choice is to talk it through: it all starts with a free discovery call over video.

The right architecture is not the most impressive one, it is the one that best serves your users' real usage over time.

Our mobile design rule