Mobile

Native, cross-platform or web: choosing the first version of your app

The right technology for a first version follows from a few constraints — distribution, purchases, device features and the team that will maintain it.

Published
Reading time
2 min
Written by
Tensly Solutions
Paper wireframes of a mobile application next to a smartphone

“Should we build a native app?” is usually the wrong first question. The right one is: what does the first version have to do, for whom, and through which channel? The technology follows from the answers.

Start from the constraints

Distribution. Do your users expect to find you in the App Store and Google Play, or will they come from a link, an email or your website? Store distribution brings visibility and trust, and also review cycles and rules.

Purchases. If you sell digital content or subscriptions inside a mobile app, the stores’ payment rules apply, and they vary by region and by category. Settle in-app purchases, subscriptions and purchase restoration before development, not after a review rejection.

Device features. Camera, Bluetooth, background tasks, notifications, offline use: list what the first version truly needs. Each item narrows the options.

The team after launch. Someone will maintain the app through every operating system release. One codebase is easier to keep current than two; a platform-specific feature may still justify native code in places.

Three options, honestly compared

A web application. The fastest to ship and to update: no store review, one codebase, discoverable by search. Device access and offline use are more limited, and some users simply expect an app in the store.

A cross-platform app. One codebase — for example React Native — for iOS and Android, with native interface components and store distribution. For most business and consumer applications, it is the sensible default for a first version.

A native app per platform. The deepest integration with each platform, at the cost of two codebases to build and to maintain. Worth it when the product depends on platform capabilities that the other options handle poorly.

Decide during scoping, write it down

None of these choices is permanent: a web application can come first and an app later; a cross-platform app can host native modules where needed. What matters is to make the decision deliberately, in the open, and to write down why — so that the next decision starts from facts.

That is how we scope mobile projects. If you are weighing these options, describe your project and we will give you our view.

Have something worth building?

Tell us what you’re building. We reply within two working days with an honest first view on feasibility, scope and order of magnitude.