The build cost is the same in both — so stop comparing quotes and start comparing what happens in year two. Real India numbers, the store rule that delays both by a fortnight, and the cases where we tell clients to overrule our own default.
Pick Flutter if your app is under about ₹2,50,000 and its job is screens, forms, lists and payments. Pick React Native if you already run a React or Next.js web product, or if you plan to hire an in-house mobile developer in India within twelve months. The build cost is the same either way — at a small Indian agency in 2026 a simple app is ₹50,000–₹1,00,000 and a medium app with logins and payments is ₹1,00,000–₹2,50,000, in both frameworks, because the price is driven by screen count and backend complexity, not by the SDK. The framework does not decide your build cost. It decides your year-two hiring cost.
We build in both. Our internal default is Flutter, so read everything below with that bias in mind — and then read the section headed “when we tell clients to overrule us,” because on roughly one project in three we do. Every rupee figure on this page is the price we actually charge, published on our pricing page, not a range collected from other people’s blogs.
Most comparison tables are written for developers and argue about rendering engines. If you are paying for the app rather than writing it, almost none of that reaches you. These are the rows that change a business decision.
| React Native | Flutter | |
|---|---|---|
| Build cost, same scope | Identical | Identical |
| Language | JavaScript / TypeScript | Dart |
| Hiring pool in India | Deep — shares the web JS pool | Narrower — a separate specialism |
| Shares code with a React website | No — but shares the team | No |
| UI consistency across devices | Uses native components; small variations | Pixel-identical — draws its own UI |
| Heavy animation / custom design | Workable | Easier and faster |
| Third-party Indian SDK coverage | Usually first to ship | Good, occasionally lags |
| Install size added | Smaller | Larger (roughly 4–8 MB more) |
| Mac needed for iOS release | Yes | Yes |
| Best for | Teams that already write React | Design-led apps built from zero |
| Worst for | Heavy bespoke animation on a tight budget | A company whose whole stack is JavaScript |
Install-size figures are the typical framework overhead added to a release build and vary with what you include. “Hiring pool” reflects the Indian market specifically, where React Native and web-React recruitment draw from one pool.
This is the table nobody publishes, because it kills a useful sales lever. Here is what we charge for the same scope in each framework. The columns are the same on purpose.
| What you’re building | React Native | Flutter | What actually moves the price |
|---|---|---|---|
| Simple app, 4–8 screens, no login | ₹50,000 – ₹1,00,000 | ₹50,000 – ₹1,00,000 | Screen count and how custom the design is |
| Medium app, logins + payments | ₹1,00,000 – ₹2,50,000 | ₹1,00,000 – ₹2,50,000 | The backend and the payment gateway, not the app |
| Marketplace / on-demand app | ₹2,50,000+ | ₹2,50,000+ | Two or three user roles, live tracking, payouts |
| Backend hosting, monthly | ₹3,000 – ₹25,000 | ₹3,000 – ₹25,000 | Users and data, framework irrelevant |
| Maintenance cover, monthly | ₹5,000 – ₹30,000 | ₹5,000 – ₹30,000 | OS releases and store policy changes |
Read that table and you have the whole argument: the framework is not a line item. What consumes an app budget is screen design, API integration, the payment gateway, testing on real Indian devices and getting through store review — and every one of those costs the same in Dart as it does in TypeScript. If a vendor quotes you meaningfully cheaper “because Flutter,” they are discounting to win the job and will find the money back somewhere. Our full breakdown of what drives an app quote is in the mobile app development cost guide.
Framework comparisons argue over build speed in days. Your launch date is decided by something else entirely, and almost no React-Native-vs-Flutter article mentions it.
If you publish under a personal Google Play developer account opened after November 2023, Google requires you to run a closed test with at least 12 testers opted in continuously for 14 days before you can even apply for production access. Not 12 downloads — 12 people opted in and staying opted in, for a fortnight, before the application is accepted. Apple review then adds its own days. That is a two-to-three week gate that is completely indifferent to your framework, your agency and your code quality.
Two practical consequences. First, put the store gate in your plan before you argue about compile times — a framework choice that saves three developer-days cannot save you a fortnight of Google’s clock. Second, start recruiting your 12 testers while the app is still being built, not after. Staff, friends, early customers, a WhatsApp group — it is a genuinely hard requirement for a small business with no user base yet, and it is the single most common reason a first app launches later than promised. An organisation-type developer account is exempt from the 12-tester rule, which is often reason enough to register one properly. Our timeline guide puts this in the context of the full schedule.
Cross-platform means one codebase. It does not mean one machine. iOS release builds must be compiled and signed on macOS in React Native and in Flutter alike — neither framework removes Apple’s requirement. Add to that the Apple Developer Program at 99 US dollars a year and Google Play’s one-time 25 US dollars, and if nobody on the project owns a Mac you are paying for hardware or for a cloud build service on top of the quote. It is the most common surprise in an Indian cross-platform app budget, and choosing the other framework does not avoid it. Ask any vendor, in writing, whether iOS build and signing infrastructure is inside their price.
We prefer Flutter, mostly because a design-led app built from zero comes out closer to the mockups with less fighting. But an agency that recommends the same framework to every client is describing its own comfort, not your project. These are the cases where we say React Native, against our own default:
And the mirror image — where we hold the Flutter line even when a client arrives asking for React Native: a heavily designed, animation-rich app; a product that must look pixel-identical on every device; a first app at a company with no existing JavaScript team; and anything where the design is the product rather than a wrapper around a database.
Switching frameworks later is not a migration. It is a rewrite. Expect it to cost 60–80% of the original build: every screen is built again from scratch, while the backend, the API, the design and the product decisions carry over. On a ₹2,00,000 app that is a ₹1,20,000–₹1,60,000 bill to end up exactly where you already were, feature for feature, with nothing new to show a customer.
Which is why the protective moves matter more than the choice itself. Keep business logic on the server, not in the app — anything that lives in the API survives a rewrite untouched, and anything hard-coded in the app dies with it. Own the repository from day one and have code pushed to it continuously, not delivered in a zip at the end. Insist the API is documented as part of the deliverable. Do those three things and a framework switch in year three is expensive but survivable. Skip them and the framework choice becomes a trap you pay to escape.
One last honest note. For the large majority of business apps — a catalogue, a booking flow, a dashboard, a customer portal — either framework will do the job well, and the project will succeed or fail on the quality of the requirements, the design and the testing, not on the SDK. If you have spent more than a week on this decision, the decision is not what is holding you up.
No. Any quote where the two differ by more than about 10% for the same scope is telling you about the vendor, not the framework. We price the same app identically in both, because the work that consumes the budget — screens, APIs, payments, device testing, store submission — is framework-independent. The real difference is hiring supply later, and that lands in maintenance, not in the build invoice.
Neither. A personal Google Play developer account opened after November 2023 must run a closed test with at least 12 testers opted in for 14 continuous days before applying for production. Framework build-speed differences are measured in days; that gate is measured in weeks. Organisation accounts are exempt.
Yes, for iOS release builds — and equally for React Native. Neither framework removes Apple’s macOS requirement. Budget for a Mac or a cloud build service, plus 99 US dollars a year for Apple and a one-time 25 US dollars for Google Play.
Not the screens. You can share business logic, validation, types and API clients, but every piece of UI is rebuilt because the web renders HTML and React Native renders native components. What you genuinely reuse is the team and the hiring pipeline — which is worth a lot, just not the 50% saving people expect.
Take the SDK audit — list every third-party service your app needs and check official support in both. If that is a tie, and you have no React team and no in-house hiring plan, pick Flutter and move on. The cost of a further week of deliberation is higher than the cost of the difference.
We will price your scope in React Native and in Flutter and tell you honestly which one we would build it in — including when that answer is “neither, you do not need an app yet.”