When to choose a native app, hybrid app, or PWA: a three-column comparison table, Apple and Google fees, EU store commissions, and the actual cost in euros.
Choose native if you depend on hardware, high-end graphics performance, or reliable notifications on iPhone. Choose hybrid—Flutter or React Native—if you need to cover iOS and Android with a single team. Choose PWA if usage is occasional, access is link-driven, and you can do without an app store. The cost differential is determined by maintenance, not development.
Three distinct things, not three versions of the same
Most Spanish-language comparisons treat these three options as three levels of quality for the same product: the good, the mediocre, and the cheap. They are not. They are three distribution models with three different channel owners.
Native means one binary for iOS written in Swift and another for Android written in Kotlin. Two codebases, two review cycles, and full access to system APIs. This is the option with the most control and the highest maintenance overhead.
Hybrid—the correct term today is cross-platform—means a single codebase in Flutter or React Native that compiles to both stores. The interface is rendered once. The parts that interface with specific hardware still require native code, and that is where the savings promised in the brochure evaporate.
PWA stands for an installable web app: manifest, service worker, offline functionality. It does not pass through any store. It updates like a website, without anyone’s review and without waiting.
You are not choosing a technology: you are choosing who controls your distribution channel and who has the power to shut it down.
The Decision Matrix
| Criterion | Native | Hybrid (Flutter / React Native) | PWA |
|---|---|---|---|
| Codebases | 2 | 1 + native patches | 1 |
| App Store and Google Play presence | Yes | Yes | No |
| Installation | From the store | From the store | Add to home screen |
| Notifications on Android | Full | Full | Full (Push API) |
| Notifications on iPhone | Full | Full | Only if user adds web app to home screen, iOS 16.4 or later |
| Camera, Bluetooth, sensors | Full access | Full access via plugin | Partial and inconsistent across browsers |
| Updating text or price | New version and review | New version and review | Publish and done |
| Risk of rejection during review | Low | Low | N/A |
| Mandatory annual fee | Apple 99 USD/year + Google 25 USD one-time | Same | None |
| Commission on digital sales | Yes | Yes | No |
| Indexable by Google | No | No | Yes |
| Maintenance forced by platform | High | High | Low |
A table does not decide for you. It organizes the trade-offs so you can make them with your eyes open.
Fixed costs exist before the first line of code
Apple bills membership in dollars and only states that it may be charged "in local currency where available": it does not publish a rate in euros on its membership comparison page. If your accounting department requires the exact amount in euros and the VAT treatment for the Apple Distribution International invoice, ask for it before budgeting, as the actual charge depends on the daily exchange rate and your status as a business or professional.
These two figures are the only cheap part of the matter. Publishing costs 124 dollars for the first year. Keeping it published costs quite a bit more, and that is the line item almost no Spanish budget details.
The cost differential: where the budget truly diverges
The industry sells the savings of the cross-platform option as if it were simple arithmetic: one codebase instead of two, therefore half the cost. Arithmetic does not work that way. Design is performed once in all three cases. Testing is performed in all three cases on two real operating systems. Publishing and review are performed twice for native and hybrid.
These are the line items where the allocation changes. We measure ours and will publish the percentages as soon as we have a statistically significant sample:
| Item | Figure | Note |
|---|---|---|
| Product definition, architecture, and design | — | — |
| Interface and design system | — | — |
| Product logic development | — | — |
| Platform-specific code | — | — |
| Device testing and QA | — | — |
| Publishing, store listings, and review | — | — |
— = data being measured; we will publish it once we have our own sample.
When someone gives you a price differential in euros without explaining the sample size, they are giving you an opinion formatted as an invoice. We prefer to show the gap rather than fill it with a convenient number.
We can, however, give you a reasoned estimate, marked as such. At 60 €/hour—the standard rate for a Spanish studio of this size—a second native codebase replicating an existing app rarely costs under 300 hours, i.e., 18,000 € plus VAT. It is an estimate, not a measurement: use it to rule out scenarios, not for signing contracts.
1. Notifications on iPhone
This is where half of all PWA projects in Spain die. Apple does support web push, but with a condition that is rarely read: the official documentation literally says "Add web push to Home Screen web apps in iOS 16.4 or later." Translated: on iPhone, your PWA can only send notifications if the user has added it to their home screen using a manual gesture that no one has taught them to perform.
If your product relies on notifications—a delivery alert, a shift change, a banking alert—, a PWA is not a cheaper option: it is a different option with a delivery rate that depends entirely on a user action. Native and hybrid apps do not have this problem.
Friendly detail: Apple clarifies that you do not need to be in the Apple Developer Program to send web push. The 99 dollars are for publishing in the store, not for push notifications.
2. Charging for digital content inside the app
If you sell subscriptions, courses, credits, or any digital good consumed within the app, the store collects a commission. If you sell a physical good or a service performed outside the app, it does not.
Apple also documents a 10% commission for subscriptions from the second year onwards under the EU alternative terms derived from the Digital Markets Act. If your app is European and subscription-based, that line item is worth real money.
3. Your app must contribute something your web does not
App Review Guideline 4.2 is explicit: "Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store."
And 4.2.6 closes the door on a model widespread in the Spanish market: "Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content."
If someone offers you "your website turned into an app" for a round price, they are selling you the process of being rejected. This is not our opinion: it is written in the guidelines applied by the reviewer.
4. Who pays for mandatory maintenance
An app is never finished. Platforms force you to keep moving.
Verified 08-27-2026. Google Play requires new apps and updates to target Android 16 (API level 36) or higher starting August 31, 2026—four days from now—with exceptions for Wear OS and Android Automotive (API 35) and Android TV and Android XR (API 34). Existing published apps that do not comply will cease to be visible to new users on devices with Android versions higher than their target API. Google accepts extension requests until November 1, 2026, via Play Console. Source: support.google.com/googleplay/android-developer/answer/11926878.
This is the cost that does not appear in the budget but appears every year. A PWA does not have it: there is no target API to pursue, no binary to recompile, no listing to review. A native or hybrid app does, in both stores, forever.
Two commission tables that say different things
There is a contradiction here that no Spanish guide addresses, and you should know it before modeling your margins.
Google Play documentation describes, for the European Economic Area, the UK, and the US, a scheme in effect since June 30, 2026: auto-renewing subscriptions at 10% plus a 5% billing commission; other transactions at 20% plus 5% for new installations, and 25% plus 5%—or 20% with external web links—for existing installations.
At the same time, that same documentation maintains the classic scheme for other markets: 15% on the first million dollars annually and 30% above that, with 15% for subscriptions.
Two schemes coexisting in the same source, with a cut-off date in between. Spain is in the first one. If you have calculated your model using the 15/30 figure cited by half the internet, recalculate it. And if your provider gives you a figure without stating which scheme it belongs to, they have not read the source.
A PWA does not fall into either table. You collect via Redsys, Bizum, or Stripe, paying only the gateway commission. That is the real economic argument for the PWA, and almost no one frames it that way.
Spain: VAT, accessibility, and the fine print of the budget
The general VAT applicable to a development project in Spain is 21% (VAT Law 37/1992, rate increased from 18% to 21% by Royal Decree-Law 20/2012, in effect since September 1, 2012). If an app budget says "12,000 €" without stating whether it includes VAT, the difference is 2,520 €. Ask for it in writing.
Accessibility is no longer optional. Directive (EU) 2019/882—the European Accessibility Act—applies to products placed on the market and services provided after June 28, 2025, and expressly includes e-commerce services and specialized software. Micro-enterprises providing services are exempt from the requirements and obligations according to Article 4. If your app sells, it falls under the scope. If your app sells and you are a service micro-enterprise, verify your status before assuming you are exempt.
And a note on performance that only affects the PWA, because it is the only one of the three that Google measures and indexes: the "good" thresholds for Core Web Vitals are LCP 2.5s, INP 200ms, and CLS 0.1, evaluated at the 75th percentile of loads, segmented by mobile and desktop. A slow PWA is not a bad app: it is a bad website with a manifest.
The industry standard: The industry starts with technology: "we'll build your app in Flutter." They choose the tool before knowing what the product needs to do, and then justify the savings with arithmetic that does not hold up under testing or maintenance.
Our criteria: We start with the channel: who installs, who notifies, who collects, and who forces updates. Technology is the consequence of those four answers, not the starting point.
How we decide on a project
| # | Phase | What we do | Deliverables |
|---|---|---|---|
| 01 | Listen | We start by asking, not proposing. | Interviews · Audit of existing assets · Agreed brief |
| 02 | Define | We agree on what winning means before moving a pixel: installs, notifications delivered, or net income after commission. | Objectives · Scope · Success criteria |
| 03 | Map | We map the user journey and mark the exact point where a user receives an alert or pays. That is where native, hybrid, or PWA is decided. | Flows · Navigable prototype |
| 04 | Design | System, grid, and typographic rhythm. This line item costs the same in all three options. | Design system · Components |
| 05 | Build | Code, physical device testing, and CI/CD. Each commit leaves a trace in your repository, not ours. | Repository · Testing environment |
| 06 | Launch and Support | Launch is a checklist, not a leap of faith. 30 days of support included and documented handover. | Publication · Handover · Documentation |
- The document states which commission scheme your case belongs to and the date of consultation
- The price explicitly says "plus VAT," with the 21% broken down
- The Apple (99 USD/year) and Google (25 USD) fees are named, and it is stated who pays them
- It is written who owns the App Store Connect and Play Console accounts: you, not the provider
- Annual maintenance for target API changes has a price, not a "we'll see" promise
- If it is a PWA, there is a written response regarding iPhone notifications and the gesture of adding to the home screen
- The transfer agreement names the code, source files, and design
- There is a handover date and a deliverable documentation package, so your team can continue without us
A reliable app budget names the fees, the commission scheme, account ownership, and the handover date; a comfortable app budget only names the total.
Frequently asked questions
Can a PWA replace a native app?
It works when usage is occasional and access is link-driven: lookup, booking, tracking, catalog. It does not work if you depend on reliable iPhone notifications, because Apple only allows them for web apps added to the home screen from iOS 16.4.
How much is really saved with Flutter compared to native?
You save on the interface layer and part of the logic, but you save nothing on design, testing, or publishing. We prefer not to give you a round percentage until we have our own published measurements with n and dates.
Can I publish an app in the App Store that is just my website in a container?
Almost certainly it will be rejected: Guideline 4.2 requires the app to elevate beyond a repackaged website, and 4.2.6 rejects those generated with template services. If someone sells it to you as a simple procedure, they are selling you a rejection.
Do store commissions apply if I sell a physical product?
No. App Store and Google Play commissions apply to digital goods and services consumed inside the app. A physical product or service provided outside the app is collected via your gateway and its commissions, not the store's.
How long does an app project take with you?
We work on digital products in 8-week phases with a fixed price per phase, agreed upon before starting. No surprise hours; and if, upon listening to you, we see your case does not need an app, we will tell you in the first call.
Our stance
The right question is not which of the three is better: it is how much you are willing to pay, every year and forever, for the privilege of being inside a store. For many Spanish products, that annual fee buys something real—discovery, trust, integrated billing. For others, it buys only maintenance work and a commission on every euro.
We accept a limited number of projects per year and prefer to tell you that you do not need an app rather than charge you for one that no one will install. The first call lasts 30 minutes and costs nothing. Does this way of working suit you?
Keep reading
- How much it costs and how long it takes to develop an app in Spain: native, hybrid, or PWA
- Can I make an app with 10,000 €? What is included and what is not
- How much do you really save with Flutter versus native? Our measurement
- Web accessibility in Spain after the European Accessibility Act: who is obligated and what is required
- Redsys and Bizum in your online store: how they integrate and what commissions they have
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 per membership year, "or in local currency where available"; does not publish rate in euros. Accessed 08-27-2026.
- https://support.google.com/googleplay/android-developer/answer/6112435 — Google Play developer account registration fee: 25 USD, one-time payment. Accessed 08-27-2026.
- https://support.google.com/googleplay/android-developer/answer/112622 — Google Play commission scheme: for EEA, UK, and US from 06-30-2026, subscriptions 10% + 5% billing commission, other transactions 20% + 5% (new installs) and 25% + 5% or 20% with external links (existing installs); in other markets 15% up to 1M USD and 30% above. This is the contradiction noted in the article. Accessed 08-27-2026.
- https://developer.apple.com/app-store/small-business-program/ — reduced 15% commission up to 1 million USD revenue in the previous calendar year; mention of 10% for subscriptions from the second year under EU alternative terms (DMA). Accessed 08-27-2026.
- https://developer.apple.com/documentation/usernotifications/sending-web-push-notifications-in-web-apps-and-browsers — literal quote "Add web push to Home Screen web apps in iOS 16.4 or later" and confirmation that Apple Developer Program is not required for web push. Accessed 08-27-2026.
- https://developer.apple.com/app-store/review/guidelines/ — literal text of guidelines 4.2 (Minimum Functionality, "beyond a repackaged website"), 4.2.6 (rejection of apps generated with commercial templates), and 2.5.6 (WebKit and alternative engines in EU and Japan). Accessed 08-27-2026.
- https://support.google.com/googleplay/android-developer/answer/11926878 — target API requirement: Android 16 (API 36) for new apps and updates from 08-31-2026, exceptions Wear OS/Automotive (API 35) and TV/XR (API 34), extension until 11-01-2026. Accessed 08-27-2026.
- https://web.dev/articles/vitals — "good" Core Web Vitals thresholds: LCP 2.5s, INP 200ms, CLS 0.1, measured at the 75th percentile segmented mobile/desktop. Accessed 08-27-2026.
- https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=CELEX:32019L0882 — European Accessibility Act: application to products and services from 06-28-2025, express inclusion of e-commerce, exemption for micro-enterprises providing services (art. 4). Accessed 08-27-2026.
- https://www.boe.es/buscar/doc.php?id=BOE-A-2012-9364 — Royal Decree-Law 20/2012: increase in general VAT from 18% to 21% and reduced from 8% to 10%, in effect since September 1, 2012 (amending Law 37/1992). Accessed 08-27-2026.
Want to see this thinking applied to a real project?