Kotlin, Flutter or React Native: how I pick for a new app

Crypton Studio ships native Kotlin (ScanCrypt), Flutter (CovertX) and takes on React Native client work, so this is not a tribal take. The stack question is usually settled by four questions, not by benchmarks.

1. Does the app live close to the platform?

Camera pipelines, file systems, background services, biometrics, widgets — the deeper you go, the more a cross-platform layer becomes a tax. ScanCrypt is native Kotlin precisely because scanning, OCR and encryption sit on top of platform APIs that are painful through a bridge. If your app is mostly screens over data, this question doesn’t disqualify anything.

2. How many platforms, how soon, how big is the team?

One developer, two platforms, one deadline → Flutter or React Native is the honest default. A single codebase halves the surface area a solo builder maintains. The follow-up question is your team’s existing fluency: React Native rewards a web/React team; Flutter rewards starting fresh with strong tooling and a consistent widget system.

3. What does the UI want to be?

Pixel-perfect custom design systems travel well in Flutter — it paints everything itself. Apps that should feel exactly like the platform (share sheets, navigation transitions, system typography) are easiest native, and second-easiest in React Native, which uses real platform widgets more often.

4. What is the ten-year story?

Kotlin and Swift will outlive every bridge. That doesn’t make bridges wrong — it means cross-platform is a velocity decision you revisit, not an identity. Plan module boundaries so that dropping to native later (for the camera screen, the widget, the watch app) is a refactor, not a rewrite.

The cheat sheet

• Deep platform integration, performance-critical, Android-first → Kotlin.
• Two platforms, small team, custom UI system → Flutter.
• React-fluent team, web + mobile sharing logic → React Native.
• Still unsure → prototype the riskiest screen in each, one day per stack. The friction tells you.