How much does a mobile app cost in 2026: native, cross-platform (Flutter, React Native) or PWA

The managing director of a chain of forty gyms across the Netherlands has been told by her marketing agency: “You need an app.” Members should be able to book classes, pay for memberships, collect points and get a notification when a place opens up on a full class. The first proposal, from a studio specialising in native apps, comes in at €320,000. The second, from a team working in Flutter, at €170,000. The third, from an agency proposing a progressive web app, at €85,000. Each vendor argues its approach is the right one, and each is partly right.

The board does not need a lecture on technology. It needs answers to three questions: where does a nearly four-fold difference come from, what do we lose by choosing a cheaper option, and what will it cost us every year after launch? The first two can be calculated. The third is usually missing from proposals, and for mobile apps it matters more than for web applications, because Apple and Google change the rules every year and an app has to keep up to stay in the stores.

This article shows how much a mobile app costs in 2026 in three variants: native (Swift for iOS, Kotlin for Android), cross-platform (Flutter or React Native) and PWA. We price the same product three ways, with the team, duration and rates from our pricing page in plain view, then add store fees and maintenance. You can swap every assumption for your own.

Why is there no single answer to “how much does a mobile app cost”?

Because “mobile app” is the name of a category, not a product. The same label covers a three-screen app that shows content from an existing website and a banking app with biometrics, payments and offline mode. The cost difference between them is more than ten-fold. No serious vendor will quote “a mobile app” without understanding what it has to do.

Even for the same feature set, though, the cost depends on a technology decision, and that is what drives the spread in the proposals above. A native app is in practice two apps, one for iOS and one for Android, written by two teams in two languages. A cross-platform app is one codebase that produces both versions. A PWA is a web application that the user can “install” from the browser, without a store. Each approach has a different build cost, a different maintenance cost and different limits.

The third variable is the backend. Almost every mobile app needs a server: user accounts, business logic, payments, notification delivery, an admin panel. That part costs the same however you build the mobile layer. That is why the choice of mobile technology never halves the total cost, even when a vendor implies it does.

Finally, unlike a web application, a mobile app lives in an ecosystem controlled by two companies. Apple and Google set the fees, commissions, review rules and deadlines for mandatory updates. You cannot negotiate that cost, but you do have to plan for it.

What actually separates native, cross-platform and PWA?

A native app is written separately for each platform in that platform’s language and tools: Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android. It gives full access to device features, the best performance and an interface that follows each platform’s conventions. The price is double work on the mobile layer: every feature is implemented and tested twice, and the team needs specialists for both platforms.

A cross-platform app is built from one codebase, from which the framework produces iOS and Android versions. The two dominant frameworks are Flutter (Dart, from Google) and React Native (JavaScript or TypeScript, from Meta). One team covers both platforms, and most of the logic and interface is shared. Features that need deep device access or unusual native libraries sometimes still have to be written natively, as so-called native modules. For decision-makers, our articles on what Flutter is and on React Native architecture, ROI and risk describe both frameworks.

A PWA (progressive web app) is a web application that behaves much like a mobile app: it can be added to the home screen, works partly offline and can send notifications. It does not go into the App Store or Google Play, so there are no store fees and no review, but also no store visibility. On iPhones it has significant limits: web push works from iOS 16.4 and only for apps added to the Home Screen, as the WebKit team confirms. Some device capabilities available to native apps are unavailable or behave differently in Safari, so each hardware feature you need has to be checked individually.

A note for the board: choosing between these approaches is a business question, not a technology one. The answer depends on how often people will open the app, whether notifications are essential, whether a store presence matters for marketing and how many phone features you need.

How do we calculate the cost of a mobile app?

The method is the same as in our article on how much a web application costs in 2026: build cost is people × time × rate. The assumptions:

• Mobile developer rates. A senior mobile developer on our rate card costs EUR 370-520 per day, fully loaded. That is slightly more than a senior backend or frontend developer.
• Other roles. Backend, QA, design and project management are priced in the general senior band: EUR 335-485 per day. UX designers are not on our published rate card, so we assume the same band for them.
• Time. 18 billable days per month per full-time person, after holidays, public holidays and sick leave.
• Cost of a person-month. Senior mobile: 370 × 18 = EUR 6,660 to 520 × 18 = EUR 9,360. Other roles: EUR 6,030-8,730.
• Contingency. A separate 15% for requirements that become clear after the first user tests.

We price one product in three variants: the gym chain’s member app from the introduction. Scope: sign-up and sign-in, profile, class booking with a waiting list, card payment for memberships, a points programme, push notifications, a simple activity history, and a backend with an admin panel for front-desk staff and an integration with the existing booking system. The lower bound of each range is the shorter schedule at the lower rates; the upper bound is the longer schedule at the higher rates.

A team with more mid-level specialists will come in below the lower bound. Our MVP cost calculator computes the low end of its range that way. This is not an ARDURA price list. It is an estimation method with stated assumptions, meant to help you read proposals.

How much does a native iOS and Android app cost?

Team assumptions. 6 full-time equivalents on average: 1.5 iOS developers, 1.5 Android developers, a backend developer, a QA engineer testing both platforms, a UX designer at half time and a project manager at half time. Schedule: 5-6 months to release in both stores.

The arithmetic. The mobile layer is 3 FTE, the other roles 3 FTE.

• Lower bound: 5 months × (3 × EUR 6,660 + 3 × EUR 6,030) = 5 × EUR 38,070 = EUR 190,350
• Upper bound: 6 months × (3 × EUR 9,360 + 3 × EUR 8,730) = 6 × EUR 54,270 = EUR 325,620
• With 15% contingency: roughly EUR 219,000-374,000

When native is worth the price: when the app is the company’s main product rather than an extra channel; when it relies heavily on device features (camera with image processing, Bluetooth with external devices, background work, HealthKit or Health Connect integrations); when performance and interface smoothness are part of your competitive edge; when you want to adopt new Apple and Google platform features, such as widgets or assistant integrations, as soon as they ship.

There is also a cost that only appears after launch: every new feature is built twice. If the product roadmap is ambitious, the gap in development cost between native and cross-platform grows every year.

Then there is coordination, which the rate arithmetic does not show. Two platform teams have to keep features in step: the same booking rule, the same error messages, the same release date. In practice one platform almost always runs ahead of the other, and someone has to make sure iPhone and Android users do not end up with different versions of the product. That falls to the project manager and QA, and their time is only partly covered by our team assumptions. If a native proposal has nobody responsible for cross-platform consistency, ask who will do it. Where consistency has legal or financial weight, for example in fee calculation or marketing consent, a gap between platforms is not cosmetic. It is a complaints risk.

How much does a Flutter or React Native app cost?

Team assumptions. 4.75 FTE on average: 2 Flutter or React Native developers, a backend developer, a QA engineer at three-quarter time, a UX designer at half time and a project manager at half time. Schedule: 4-5 months.

The arithmetic. The mobile layer is 2 FTE, the other roles 2.75 FTE.

• Lower bound: 4 × (2 × EUR 6,660 + 2.75 × EUR 6,030) = 4 × EUR 29,902.50 = EUR 119,610
• Upper bound: 5 × (2 × EUR 9,360 + 2.75 × EUR 8,730) = 5 × EUR 42,727.50 = EUR 213,638
• With 15% contingency: roughly EUR 138,000-246,000

In this calculation the cross-platform option costs about a third (34-37%) less than native, not half. The reason is visible in the arithmetic: backend, testing, design and management remain, and testing still has to happen on both platforms and many devices. The saving is mainly in the mobile layer.

Flutter or React Native? From a cost point of view the differences are smaller than from a team point of view. React Native uses JavaScript and TypeScript, so it is easier to hire for and to share knowledge with a web team working in React. Flutter gives a very consistent interface across platforms with its own rendering engine. More important than the framework is whether the vendor has production experience with it and whether your own team could maintain the code if the engagement ended. Availability and rates of mobile specialists in Poland are covered in our article on mobile developer rates in 2026.

When cross-platform is the right choice: when the app must be on both platforms from day one, the budget is constrained and the device features are the usual ones (camera, location, notifications, payments, biometrics). That describes most customer apps in retail, services and loyalty programmes, including the gym chain in our example.

How much does a PWA cost, and what will it not do on an iPhone?

Team assumptions. 3.75 FTE on average: 1.5 frontend developers, a backend developer, a QA engineer at half time, a UX designer at half time and a project manager at quarter time. Schedule: 3-4 months. All roles are priced at EUR 335-485 per day.

The arithmetic. 3.75 FTE × 3 months = 11.25 person-months; × 4 months = 15 person-months.

• Lower bound: 11.25 × EUR 6,030 = EUR 67,838
• Upper bound: 15 × EUR 8,730 = EUR 130,950
• With 15% contingency: roughly EUR 78,000-151,000

A PWA costs about 57-61% of the cross-platform option and 35-40% of native. It also has an advantage proposals rarely mention: an update reaches every user immediately, with no store review and no waiting for users to update.

What will a PWA not do well in the gym example? The key feature is the notification that a place has opened up on a class. On Android this works in a PWA without much trouble. On an iPhone it works only if the user first adds the app to the Home Screen, and most users do not do that without a clear prompt. If a large share of members use iPhones and notifications are the heart of the app’s value, a PWA will be cheaper but will serve the business goal less well.

A PWA also has a less visible cost: no store presence. Some customers look for a brand’s app in the App Store or Google Play and will not find it there. For an app used occasionally, to check an order status or fill in a form, that does not matter. For an app meant to build a daily habit, it may.

How do the three mobile approaches compare?

The table brings together the calculations for one product in three variants, with selection criteria. It is a tool for conversations with vendors and the board, not a price list.

Criterion	PWA	Cross-platform (Flutter / React Native)	Native (Swift + Kotlin)
Team (FTE)	3.75	4.75	6
Time to launch	3-4 months	4-5 months	5-6 months
Build cost (before contingency)	EUR 68,000-131,000	EUR 120,000-214,000	EUR 190,000-326,000
App Store and Google Play presence	No	Yes	Yes
Push notifications on iPhone	Only after adding to Home Screen (iOS 16.4+)	Yes	Yes
Device feature access	Limited, browser-dependent	Common features yes, unusual ones via native modules	Full
Cost of each new feature	One implementation	One implementation, sometimes with native add-ons	Two implementations
Yearly iOS and Android adaptation	No store cycle, browser testing	Framework upgrade plus both platforms	Separately on each platform
When to choose	Occasional use, push not essential, quick test of an idea	Customer app on both platforms with common features	App as core product, heavy use of device features

Assumptions: senior mobile EUR 370-520 per day, other roles EUR 335-485 per day, 18 billable days per month. Add a contingency of about 15% and external costs to every figure.

The key takeaway: the gap between variants is smaller than the proposals in the example suggested, and each variant has cases where it is the best choice. The €320,000 native proposal sits inside our range, as does €170,000 for Flutter and €85,000 for the PWA. None of them is suspicious on price. The choice comes down to whether iPhone notifications and store presence are worth a difference of a couple of hundred thousand euros.

What do the app stores cost: developer accounts and commissions?

The accounts themselves are cheap. The Apple Developer Program costs USD 99 a year for organisations and individuals. A Google Play Console account is a one-time USD 25. The Apple membership must be renewed or the app disappears from the store, so it should belong to your company, not to a developer’s personal account.

Commissions matter more, but only for some apps. Store commissions apply to digital content and features sold inside the app: premium subscriptions, unlocked features, virtual currencies. Under the App Store Small Business Program, Apple charges 15% to developers with no more than USD 1 million in annual proceeds. Google Play charges 15% on the first USD 1 million of annual revenue and 30% above it, and 15% on subscriptions; in the EEA, the UK and several other markets a different fee structure applies. Terms change from time to time, so check the current rules for your markets before you design a revenue model.

For the app in our example, another rule matters more. Under App Store Review Guideline 3.1.3(e), an app that sells physical goods or services consumed outside the app must use purchase methods other than in-app purchase, such as Apple Pay or card payments. A gym membership is a service consumed outside the app, so the payment goes through a payment provider, not through Apple. You then pay the payment provider’s fee, not the store’s. Stripe in Ireland, for example, lists 1.5% + €0.25 for standard EEA cards on its pricing page. That difference can change the economics of the whole business model, so settle it before you design the payment features.

How much does it cost to maintain a mobile app after launch?

This is the line most often missing from proposals and the one that most often surprises boards. A web application can run for years with occasional updates. A mobile app cannot, because the platforms enforce updates on a fixed rhythm.

Two examples from 2026. Since 28 April 2026, Apple has required apps uploaded to App Store Connect to be built with Xcode 26 or later using the iOS 26 SDK, according to Apple’s upcoming requirements page. Since 31 August 2026, Google has required new apps and updates on Google Play to target Android 16 (API level 36), and existing apps that do not target at least Android 15 (API level 35) stop being available to new users on newer OS versions. This is not a one-off. Both requirements move every year, and each new OS version changes the behaviour of permissions, background work or notifications.

What does it cost? There is no public source that measures it, so here is our estimate with the factors that move it. The yearly adaptation to a new OS version alone, meaning SDK and dependency updates, testing on the new version and fixes for behaviour changes, is roughly 10-20 person-days per platform per year for an app with typical features. For a native app on two platforms that is 20-40 person-days, or about EUR 7,400-20,800 at senior mobile rates. For a cross-platform app we estimate 15-30 person-days, because upgrading the framework itself comes on top of work on both platforms. A PWA has no store cycle but needs testing on new browser versions. The estimate grows with the number of device features, third-party libraries and supported OS versions.

That is only part of maintenance. Add bug fixes, crash monitoring, small improvements and backend upkeep. As a starting point for the budget, plan 15-20% of the build cost per year and adjust it after the first year based on actual tickets. Support models and service levels are described in our article on why software maintenance matters as much as development.

What does that mean over three years? Take build cost plus two years of maintenance, assuming 15% of build cost per year at the lower bound and 20% at the upper (before contingency and external costs):

• Native: build EUR 190,350-325,620 plus maintenance EUR 57,105-130,248, roughly EUR 247,000-456,000 in total.
• Cross-platform: build EUR 119,610-213,638 plus maintenance EUR 35,883-85,455, roughly EUR 155,000-299,000.
• PWA: build EUR 67,838-130,950 plus maintenance EUR 20,351-52,380, roughly EUR 88,000-183,000.

This calculation is generous to native, because it applies the same maintenance percentage to every variant. In practice, evolving a native app costs more, because every new feature is built twice and the OS update cycle is handled separately on each platform. If your roadmap includes several larger features a year, the three-year gap between native and cross-platform will be wider than the build gap. The board should see this figure next to the build cost, not in year two.

Which mobile app variant is right for your product?

Rather than starting with technology, answer five business questions. The answers usually point clearly to one variant.

1. How often will a user open the app? Daily or several times a week favours a store app. A few times a year favours a PWA, or simply a good mobile website.
2. Are push notifications the heart of the value? If so, and a large share of your users have iPhones, a PWA is out. Check the iOS and Android split among your customers in your website analytics; we wrote about the differences between the two user bases in our article on iOS vs Android user demographics.
3. Which device features do you need? Camera, location, biometrics and payments are standard for cross-platform. Bluetooth with external devices, intensive background work or real-time image processing favour native.
4. Is the app a product or a channel? If the company earns money from the app and competes on experience, native may pay back. If the app is an additional service channel, cross-platform is usually enough.
5. Who will maintain the code in three years? If you have a React web team, React Native lowers maintenance cost. If you plan to bring the code in-house, choose a technology you can hire for.

Before choosing a variant at all, ask question zero: do you need an app, or a good mobile website? If your site works poorly on phones and customers reach it from search anyway, fixing the mobile site may deliver more than an app nobody installs. An app makes sense when it gives users something a website cannot: notifications, quick access from the home screen, offline use, phone features. If none of those gets a “yes”, the cheapest app still costs more than a good website.

There is also a middle path, often the most sensible start: a PWA or a simple cross-platform app as a first step, with measurement of how many people use it and how often. The decision on a more expensive variant is then based on data rather than an agency’s conviction.

What should you ask a mobile app vendor before signing?

Beyond the questions common to every project (team, person-months, rates, code ownership), mobile apps have their own list.

• Which devices and OS versions do you test on? Ask for the list: models, iOS and Android versions, screen sizes. Our mobile app testing checklist for iOS and Android shows what good coverage looks like, and the glossary entry on mobile testing explains the scope.
• Who owns the store accounts? Developer accounts should belong to your company from day one. An app published from the vendor’s account is a problem when you change vendors.
• Who prepares the release and handles review? Store listings, screenshots, privacy declarations, responses to reviewer rejections. That is several days’ work per release.
• What does the yearly update to new iOS and Android versions involve, and what does it cost? If the vendor cannot answer, it has not planned for this cost.
• Which features need native code in the cross-platform variant? A list with day estimates. No such list for an app with unusual features is a warning sign.
• How is crash monitoring handled after launch? Tool, who responds and how fast.
• How are in-app payments handled? Whether the product falls under in-app purchase rules or external payments, and how that affects margin.

Warning signs: a quote with no backend (“we assume you already have the API”), no QA on physical devices, store accounts in the vendor’s name, no word on maintenance, and the promise that cross-platform “costs half of native”. The arithmetic in this article shows why that last sentence is usually untrue.

How can you reduce the cost of a mobile app without losing quality?

The biggest savings come from discipline over the first version’s scope. The app in our example does not need a points programme or activity history at launch. Booking, payment and the open-place notification are the core of the value. The rest can come in version two, once data shows how members use the app. Cutting two modules takes several weeks off the schedule.

The second lever is reusing an existing backend. If the gym chain has a booking system with an API, the app can use it rather than duplicate its logic. You then build mainly the mobile layer, and backend cost falls.

The third is using ready-made services instead of building your own: sign-in, notifications, payments, analytics and crash reporting all have mature third-party services that cost less than building and maintaining your own.

The fourth is planning device testing sensibly: rather than testing on everything, set the device and OS list based on data about your users. If you need help there, our software testing services include mobile app testing.

What not to cut: testing on physical devices for both platforms, crash monitoring and the budget for yearly updates. An app that freezes on a popular phone model or disappears from the store after a requirements change costs more than those savings.

Where do you start to get a reliable mobile app quote?

Start with a quick reference point. Our MVP cost calculator lets you pick a mobile app, platforms and key features and shows an indicative cost range, timeline and team in seconds. Budget phases for a first product version are covered in our guide on how to budget MVP development.

Then write down your answers to the five questions in the section on choosing a variant, the list of systems the app must connect to, and the revenue model. That is enough for vendors to price the same thing.

Finally, discovery. At ARDURA Consulting it takes 1-2 weeks and ends with a recommendation of the variant (native, cross-platform or PWA) with its rationale, the scope of the first version and a quote with the arithmetic in plain view: roles, time, rates from our published rate card and a first-year maintenance budget. Our software development team builds native iOS and Android apps as well as React Native and Flutter apps, so the recommendation is not decided in advance by a single technology. Describe your product and we will come back with a concrete proposal.