A practical comparison of cross platform and native app development, and which suits which kind of project.
Every app project starts with this decision, and it is usually made on the developer's preference rather than the project's needs. Here is a framing based on what each approach genuinely costs you.
The options
| Approach | Strengths | Costs |
|---|---|---|
| Native (Swift, Kotlin) | Best performance, immediate access to new OS features, most polished feel | Two codebases, so roughly double the work and two sets of bugs |
| Flutter | One codebase, excellent performance, consistent look across platforms | Larger app size, and the UI does not automatically match each platform's conventions |
| React Native | One codebase, uses existing React skills, large ecosystem | Performance ceiling on animation heavy work, and dependency churn |
When native is worth the double cost
- The app is performance critical: heavy graphics, real time video, complex animation
- You need new OS features the moment they ship
- The app is your entire business and the polish difference matters commercially
When cross platform is the obvious answer
- You need both platforms and the budget for one
- The app is mostly forms, lists, and network calls, which is most business apps
- Time to market matters more than the last five percent of polish
The question that matters more than the framework
Who maintains this in two years? A cross platform app in a framework your future developers know is worth more than a technically superior native pair that nobody available can work on. In New Zealand's smaller talent pool, this consideration carries more weight than it does in larger markets.