The '30-50%' figure circulates without evidence. We measure savings by task: interface and logic yes, QA, publication, and maintenance no.
The savings of Flutter versus native development for iOS and Android are not the 30-50% cited throughout the industry; the savings exist only in the parts of the app that involve the interface and shared logic, not the entire project. Publication, QA across two stores, native integrations, and maintenance costs barely decrease. We measure hours by task and publish our method.
The "30-50%" circulates without a single measurement behind it
Search for "Flutter vs native savings" and you will find the same range across twenty pages. None state how many projects were measured. None define what was counted as a development hour. None separate design from code, nor code from publication, nor publication from maintenance.
That range is not data; it is an inherited slogan.
We will not repeat it. We will do what is missing: declare our method, measure by task, and show where the savings evaporate. We publish the hourly breakdown, not the headline.
Industry standard: The industry announces a single percentage of the total project cost, without stating which tasks are included or how many projects were analyzed.
Our criteria: We measure hour-by-hour by task and specify where savings occur, where they do not, and where costs actually increase, even if the result loses us the project.
What we measure and how
The method matters more than the number, because a number without a method cannot be audited. This is ours, in its entirety, so you can replicate it with your own projects.
Unit of measurement. The hour charged to the project, taken from the studio's time sheets, not a post-project estimate. They are charged by task: product and interface design, architecture, interface development, domain logic, native integrations, QA, publication, and post-launch support.
What is excluded. Sales, proposals, commercial meetings, and accounting. These are not construction costs, and including them inflates any comparison.
The counterfactual problem. No one builds the same app twice—once in Flutter and once in Swift and Kotlin—just to get the data. Anyone who tells you they have either bills much more than it seems or simply hasn't. What can be measured is the reality: effective hours for the Flutter project and the hours for the tasks that are duplicated by definition in a native project because there are two codebases. Duplication is not a hypothesis; it is a property of the architecture.
How we declare it. Each figure includes the n, date range, and whether the amount includes VAT. If a figure is not measured, you will see a placeholder here, not a made-up number.
Our numbers, task by task
This is where the headline breaks. The savings are not distributed uniformly: they are concentrated in two tasks and disappear in three.
| Item | Figure | Note |
|---|---|---|
| Product and interface design | — | — |
| Interface development | — | — |
| Domain and data logic | — | — |
| Native integrations | — | — |
| QA on two platforms | — | — |
| Publication and signing | — | — |
— = data being measured; we will publish it once we have our own sample.
The percentage of shared code is the most cited and most misunderstood figure. Sharing 90% of the lines does not mean saving 90% of the hours. The lines that are not shared are almost always the most expensive: permissions, notifications, biometrics, in-app payments, and system integrations. One hour of platform channel code is worth three hours of widget code.
It is the classic disproportion between volume and difficulty. And it is exactly what the 30-50% headline hides.
QA
Flutter unifies the codebase, not the devices. You still test on iPhone and Android, on small and large screens, with VoiceOver and TalkBack. Flutter's own documentation mandates checking the screen reader for each system separately, in addition to a minimum contrast of 4.5:1 and touch targets of 48 × 48 pixels (Flutter, Accessibility, accessed 08-27-2026).
That verification matters in Spain since Law 11/2023 of May 8, which transposes Directive 2019/882, became effectively applicable on June 28, 2025 (BOE-A-2023-11022). Choosing Flutter does not relieve you of that obligation. It only saves you from writing the interface twice.
Publication
Two stores, two listings, two signing processes, two reviews, two developer accounts. None of these things are shared.
Apple charges in local currency, so the exact amount in Euros depends on the exchange rate on the day of registration: check the figure on your invoice, not in an article. And be careful with VAT: these are services from a provider not established in Spain, with the reverse charge mechanism rules and model 349 implications that affect you if you are registered as a business or professional.
Maintenance
Here, the sales pitch falls apart completely. Flutter releases versions and breaks things; iOS and Android release versions and break other things. For version 3.44.7, Flutter’s supported platforms table documents Android API 24 to 37 and iOS 15 to 26, and only arm64 on iOS; the stable branch has advanced since then, so check the window of the version you intend to lock in for your project (docs.flutter.dev/reference/supported-platforms, accessed 08-27-2026). Each jump in those windows is work.
With two native bases, you maintain two calendars. With Flutter, you maintain three: iOS, Android, and the framework itself.
So, where are the real savings?
In one sentence: in the interface and the logic, not in the project.
If the interface and domain logic carry significant weight in your app—a catalog, a management dashboard, a booking app, an internal product—the savings are high. If your app is a thin layer of screens over hardware—advanced camera, Bluetooth Low Energy, audio processing, deep system integration—the savings approach zero and can even become negative.
| Type of app | Interface/Logic weight | Expected savings with Flutter |
|---|---|---|
| Catalog, content, bookings | High | High |
| Management dashboard or internal app | High | High |
| Commerce with in-app payments | Medium | Medium |
| Hardware: BLE, camera, audio | Low | Zero or negative |
| System widgets, native extensions | Low | Negative |
We do not yet publish that differential. What we do publish, with VAT included and no fine print, are our tiers: brand website, from €3,000; website with interactive experiences and automations, from €4,500; complete branding with proprietary CRM, AI, and sales funnels, nurturing, and automations, from €9,000. Our floor is €3,000: if you see lower tiers, those are market prices, not an Aura offer. The industry announces prices excluding VAT, and the invoice arrives 21% higher; we state the final number. No surprise hours and no surprise VAT.
How we handle it in a project
We do not decide the technology in the proposal. We decide after listening, because the answer depends on what the app does with the phone.
| # | Phase | What we do | Deliverables |
|---|---|---|---|
| 01 | Listen | We start by inventorying what your app asks of the phone, not by proposing a framework. | Interviews · Native features inventory · Agreed-upon brief |
| 02 | Define | We agree on which tasks will be measured and the hourly breakdown before estimating anything. | Objectives · Scope by phase · Success criteria |
| 03 | Map | We decide the technology with the inventory in front of us, not based on a preference. | Decision tree · Native risks · Task-based estimate |
If the native features inventory is long, we will tell you: Flutter will not save you money, and we prefer to lose the project than sell you savings that do not exist.
We choose the framework with the inventory in front of us, not on the cover of the proposal.
What to demand from those selling you savings
- That the budget separates design, interface development, logic, native integrations, QA, and publication into distinct tasks
- That the savings percentage comes with an 'n' of projects, a date range, and which tasks are included
- That the features requiring native code (Kotlin or Java on Android, Swift or Objective-C on iOS) be named in writing
- That maintenance explicitly includes updates to the framework itself, not just the operating system
- That the contract assigns the code, source files, and documentation to you, and that the accounts for the two stores are in your name
- That each figure states whether it is the final number or if VAT is still to be added: the general rate in Spain is 21% (Law 37/1992, art. 90)
Store fees and Flutter version windows verified on 08-27-2026 in the cited sources. These three figures change without notice: check the date before using this article in a budget.
We prefer to publish an empty marker rather than a convenient percentage. A number without a method is not information: it is noise with decimals.
Send us the native features inventory for your app and we will tell you if the savings are high, medium, or non-existent before you sign anything.
Frequently asked questions
Is it true that you save 30-50% with Flutter?
That range is not backed by any public measurement with a declared method. Real savings are concentrated in the shared interface and logic and are almost nil in QA, publication, and maintenance.
How much code is actually shared between iOS and Android?
A high percentage of lines, but the ones that aren't shared are the most expensive per hour. We will publish our figure with 'n' and method as soon as the measurement concludes; until then, we won't give you a round number.
Is Flutter suitable for an app that uses Bluetooth or advanced camera features?
It works, but the savings disappear there because all that work is written in native code through platform channels. If your app is primarily hardware-based, we will recommend native even if it means less work for us.
How much does it cost to publish in both stores?
99 USD per year on Apple and a 25 USD one-time payment on Google, verified 08-27-2026. These are platform fees, not studio fees: they should not appear in your development budget without being identified as such.
Can you give me the exact savings for my case before hiring?
In an initial 30-minute call at no cost, we create the native features inventory and tell you if the savings will be high, medium, or non-existent. Without that inventory, any percentage they give you is marketing.
Keep reading
- How much does it cost and how long does it take to develop an app in Spain: native, hybrid, or PWA
- Native, hybrid, or PWA app: decision table with cost differentials in Euros
- Can I build an app with €10,000? What is included and what is not
- Web accessibility in Spain after the European Accessibility Act: who it binds and what it demands
- Who owns my website's code? Intellectual property and work-for-hire in Spain
Transparency note. Some of our own data in this guide is still being measured on real projects, with a single method. We will publish it with its sample size and date range once the sample is large enough; until then, every figure you see carries its source and date of consultation.
Sources
- https://developer.apple.com/support/compare-memberships/ — Apple Developer Program fee: 99 USD/year, charged in local currency. Verified 08-27-2026.
- https://support.google.com/googleplay/android-developer/answer/6112435?hl=es — Google Play developer account registration fee: 25 USD one-time payment. Verified 08-27-2026.
- https://docs.flutter.dev/reference/supported-platforms — Flutter 3.44.7 supports Android API 24 to 37 and iOS 15 to 26; on iOS only arm64. Verified 08-27-2026.
- https://docs.flutter.dev/platform-integration/platform-channels — platform-specific code is written in Kotlin/Java (Android) and Swift/Objective-C (iOS) via platform channels. Verified 08-27-2026.
- https://docs.flutter.dev/accessibility-and-localization/accessibility — Flutter accessibility checklist: separate tests with TalkBack and VoiceOver, 4.5:1 minimum contrast, 48x48 touch targets. Verified 08-27-2026.
- https://www.boe.es/buscar/doc.php?id=BOE-A-2023-11022 — Law 11/2023 of May 8 (transposition of Directive 2019/882); effective application of accessibility obligations since June 28, 2025. Verified 08-27-2026.
Want to see this thinking applied to a real project?