Native or cross-platform: how we decide
Both approaches ship good apps. The right one depends on the product, the team and what happens after launch.
One of the first technical questions on a new app is whether to build it twice, once for each platform, or once with a cross-platform framework. Opinions run strong on both sides. We don’t start with a favorite. We start with a few questions about the product and the people who will look after it.
The options
Native means building the iOS app in Swift and the Android app in Kotlin, each with its platform’s own tools and interface frameworks. Cross-platform frameworks such as React Native and Flutter let one codebase run on both. Kotlin Multiplatform sits in between: shared business logic, with interfaces that can be shared or written natively on each side.
When native earns its cost
Native makes sense when the app leans heavily on the platform: advanced camera or audio work, widgets and watch apps, deep links into system features, or demanding graphics. It also helps when the app should feel completely at home on each platform and use new platform features as soon as they arrive. The cost is two codebases, which usually means more people, more time, or both.
When cross-platform earns its place
Cross-platform makes sense when most of the app is screens, forms, lists and network calls, which describes a lot of business apps. One codebase means one set of features to build and test, and both platforms ship together. If the team already writes TypeScript for the web, React Native lets them reuse those skills and some of that code.
Look at the team, not just the app
The best technology is the one your team can maintain after launch. If the app will be handed to an in-house team, build with what they know or can hire for. A framework nobody on the team understands becomes a risk the first time something breaks in a way the documentation doesn’t cover.
Count the native work anyway
Cross-platform rarely means no platform code at all. Push notifications, in-app purchases, background tasks and some device features still need native setup, and each store still has its own release process. Budget for some native work on every cross-platform project, and make sure someone on the team can do it.
Keep the business logic portable
Whichever route you take, keep the rules of the product, like pricing, permissions and calculations, separate from the screens, and on the server where that makes sense. It makes the app easier to test, keeps the platforms consistent, and makes a later change of approach far less painful.
The short version
Choose native when the app depends on the platform, and cross-platform when it depends mostly on screens and data. Either way, pick something the team can look after for years. The choice matters less than building it well.