React Native vs Flutter: Choosing a Stack, and Living With It

Both frameworks are good enough that the framework is rarely why an app succeeds or fails. Pick on team skills and hiring reality, then spend the argument you saved on the three things users actually notice: whether it is fast, whether it works when the connection drops, and whether the notifications are worth keeping switched on.

Start from your team's skills

If your team writes React and TypeScript already, React Native lets them ship a mobile app without learning a new language, and lets you share validation, types and business logic with a web front end. If you have no JavaScript investment to protect, Flutter's Dart toolchain is coherent, the widget system is consistent, and the rendering is its own so the app looks identical on both platforms without chasing platform quirks.

In Nepal specifically, hiring is the deciding factor more often than architecture. There are far more React developers here than Dart developers, so a React Native codebase is easier to staff, hand over and maintain locally. If you are hiring a team rather than an individual, ask which stack they have shipped to both stores and kept alive for a year, and weigh that answer above any feature comparison.

Match the framework to the product

• Heavy custom animation and a strong visual identity: Flutter, because it draws every pixel itself and behaves the same on both platforms.
• Deep platform integration, native SDKs, background services, unusual hardware: React Native, where dropping into native code is a well-worn path, or native itself if you are doing a lot of it.
• Shared logic with an existing web app: React Native, which is often the whole argument on its own.
• A team of two shipping in ten weeks: whichever one they already know. This dominates every other consideration.
• Something that is mostly content and forms: consider not building an app at all. A progressive web app may serve you better, and that trade-off is covered in Core Web Vitals.

Performance: where mobile apps actually get slow

The device your users hold is not the device you develop on. Test on a mid-range Android phone that is three years old, on mobile data, with a nearly full storage volume, because that is the median Nepali user and it exposes everything a flagship hides.

• Startup time is the first impression and the most neglected number. Defer everything not needed for the first screen: analytics, remote config, feature flags, crash reporting initialisation.
• Lists are where most apps stutter. Virtualise them, keep row components cheap, avoid re-rendering the whole list on every state change, and never do layout work inside a scroll handler.
• Images dominate memory. Resize server-side to the size actually displayed, cache aggressively on disk, and do not ship a 3MB JPEG to a 360-point-wide card.
• Move heavy work off the UI thread. Parsing a large response or doing crypto on the main thread is a dropped frame the user feels as cheapness.
• Measure frame timing and startup on a real device in CI, not on a simulator on a laptop with sixteen cores.

Offline is a requirement here, not a feature

Connectivity in Nepal is intermittent by default: a lift, a stairwell, a bus between Kathmandu and Pokhara, a village with one bar of coverage. An app that shows a spinner and an error whenever the signal drops is treated as broken, and correctly so. Design for the network being absent as the normal case rather than the exception.

• Write to a local database first, then sync. The user's action should succeed immediately and reconcile later.
• Queue mutations with a retry policy and make them idempotent, so a retried request cannot create a second order.
• Decide the conflict rule before you need it. Last-write-wins is fine for a draft and unacceptable for stock levels or payments.
• Show sync state honestly: saved locally, syncing, synced, failed. Ambiguity is worse than bad news.
• Cache the last-known data and show it with a timestamp instead of an empty state. Stale data with a date beats a blank screen.
• Test on a real flaky connection, not with the network switched cleanly off. Partial and slow is a harder and more common case than absent.

Notifications people do not turn off

Every push notification spends a small amount of a budget you cannot top up. Spend it on things the user asked for or would obviously want: an order shipped, a payment received, a message from a person, a deadline they set. Spend it on marketing and you get the permission revoked, after which the useful notifications cannot arrive either.

• Ask for permission in context, after the user has done something that makes the reason obvious, never on first launch before any value has been delivered.
• Give per-category controls in the app, so someone can keep delivery alerts and mute promotions instead of muting everything.
• Deep link every notification to the exact screen it refers to. A push that opens the home screen wastes the tap and the goodwill.
• Respect quiet hours and time zones, and de-duplicate. Three notifications for one event reads as a bug.
• Track opt-out rate per notification type, and delete the type that drives it. This number tells you more about your product than open rate does.

Think about cost after launch

The build is the smaller half. Both frameworks ship breaking changes; both stores change their requirements on their own schedule and will reject an app that has not kept up. Budget for a maintenance release every quarter whatever else happens, plus OS upgrade cycles each autumn. An app nobody has touched in a year is usually one store policy change away from being unavailable.

Users do not know what framework you used. They know whether it opened fast and whether it worked in the lift.

How to decide this week

Write down what the app must do in its first release, who is building it, what they already know, and who maintains it in year two. If that paragraph does not point clearly at one option, the choice does not matter enough to keep debating, and the time is better spent on scope, which is covered in scoping an app MVP. If iOS is in scope, designing for Apple platforms covers the conventions that decide whether the result feels native or merely cross-platform. What we build and how is on our mobile app development page.