Flutter or React Native for a Nepal-Market App

Pick the one your team can maintain in two years. That is the honest answer, and everything below is detail supporting it.

Both Flutter and React Native produce apps good enough for the vast majority of business software. The question of which is technically superior has been argued to a standstill, and the answer changes with each release. The question of which one you can still hire for, in Kathmandu, in 2028, is the one with consequences.

What actually differs

Flutter draws its own widgets, so an app looks identical on every device and version. That consistency is useful, and the cost is app size and a UI that can feel slightly unlike the platform around it.

React Native maps to platform components, so it inherits native behaviour and native quirks. If your team already writes React for the web, the mental model transfers, and that is a real advantage that has nothing to do with the framework's merits.

Flutter uses Dart, which almost nobody knows before they start and most people find pleasant within a week. React Native uses TypeScript, which your web developers already write. In a small team, that is often the deciding factor.

The Nepali constraints that matter more

Two things about this market change the calculus more than the framework does.

The first is device reality. A large share of Nepali users are on mid-range Android phones with limited storage. App size is not a vanity metric here: a 40MB download on a metered connection is a real barrier to installation. Both frameworks can produce large binaries, and both can be trimmed. Whichever you pick, measure the release build early rather than at the end.

The second is payment and identity SDKs. Local gateways ship native SDKs on their own schedule, and cross-platform support lags. Before you commit, check what exists today for the gateway you need. If there is no SDK for your framework, you will either use the web checkout inside a webview or write a bridge, and both are ordinary work as long as you planned for them.

What does not matter as much as people think

Startup time benchmarks. Frame rate on a flagship device. The number of GitHub stars. These get quoted in comparison posts because they are easy to measure, and they rarely change the outcome of a business app.

What changes the outcome is whether the app handles a dropped connection, whether it works on a small screen, and whether someone can add a feature to it next year without a rewrite.

How we decide

If the client has an in-house web team, we lean React Native, because the same people can eventually own the app. If the app is UI-heavy with a custom design system and no existing team, Flutter's consistency saves time. If the app is mostly forms over an API, either is fine and we pick the one with better SDK coverage for the integrations in the spec.

A cross-platform app starts from NPR 150,000 with us, one codebase covering both stores. The framework choice does not move that number much. Scope does.

The question to ask a vendor

Not "which framework do you prefer". Ask: "if we part ways, who else in Kathmandu can pick this up?" A vendor who answers that clearly is thinking about your position rather than their preference.