App Development Cost (2026): Web App, PWA or Native?

App development cost in 2026 runs from roughly €5,000-17,000 for a simple web app or PWA to €30,000-80,000 for a mid-sized app built natively for both iPhone and Android. The biggest cost lever is how many front ends you pay for: one web app, or two native apps that each have to be built, tested and maintained.

I'm a freelance developer in Denmark who builds web apps and PWAs, so factor that in. I've tried to be just as clear about when native is worth the money.

The short answer: app development cost by type

"Simple" here means login, a handful of screens and a basic admin panel. "Mid-sized" usually adds payments, notifications, several user roles and one or two integrations with other systems. Large apps with many user types and integrations can pass €100,000 whichever way you build them.

These ranges assume a senior freelancer or a small studio in Western Europe working at around €100 an hour. A London or Amsterdam agency will often quote more, and an offshore team often less, with trade-offs I touch on in the FAQ. The right-hand column is the part to remember: cost jumps the moment you need to be in the App Store and Google Play. For the bigger picture on how software budgets come together, start with my guide to software development cost.

Four ways to build an app

Developers use these terms loosely, so here's what I mean by each.

Web app

A web app runs in the browser on desktop, tablet and phone. There's one codebase, no app store, and you can ship updates whenever you like. Customer portals, booking tools and internal dashboards are usually web apps.

Progressive web app (PWA)

A PWA is a web app that can be installed on the home screen and opens in its own window without the browser bar. It can send push notifications and work offline if it's built to. iPhones have supported push for home screen web apps since iOS 16.4, but as WebKit's own announcement explains, the user has to add the app to their home screen first and tap to grant permission.

Cross-platform

A cross-platform app is written once in a framework like React Native or Flutter and published as real apps in both stores. You get one codebase for both platforms, but you still go through two review processes and test on two kinds of device.

Native

Native apps are built separately for each platform in Apple's and Google's own languages: Swift for iOS and Kotlin for Android. You get the deepest access to the phone and the best performance, and you pay for two codebases and often two specialists.

All four almost always need a backend: the server side with the database, user accounts and admin. It's the part people forget when they compare quotes, and it costs the same no matter what's on the user's screen.

One app, built four ways: a worked example

Take a customer app for a service business. Customers log in, see their bookings and get notified when something changes. Your staff run everything from an admin panel. Here's my rough estimate of the hours a senior developer would need for each approach.

€100 an hour isn't my rate. It's a round number inside the €75-120 range that Lancebase reports for freelance full-stack developers in Western Europe. Senior rates in Denmark tend to sit at the top of that range or above it, which I cover in my post on freelance developer rates in Denmark.

Three things stand out:

• The backend row is identical in every column. It's the largest single line item, and you pay for it whichever way you go.
• The PWA costs 10-15% more than the plain web app and gets you home screen install and push notifications.
• Two native apps cost close to twice the web app, because the interface is built twice and every later change has to be made twice.

In this example, going native instead of PWA adds €12,500-18,000 to version one alone. The gap widens every year the app is live.

What drives the cost of an app

Web versus native is one factor. These move the price whichever route you take:

• User roles: an app for customers, staff and admins has three sets of screens, permissions and rules.
• Payments and subscriptions: doing Stripe properly takes time once you add receipts, refunds, failed payments and VAT for customers in different EU countries.
• Integrations: every connection to another system, such as Xero, HubSpot or a calendar, is a small project of its own. Doubly so when that system's API is poorly documented.
• Offline: showing the last-loaded data without a connection is cheap. Letting people work offline and sync later is expensive on every platform.
• Design: a ready-made component library is cheap. Custom design and complex animation cost more, and on native you pay for them twice.
• Personal data: if you handle personal data of people in the EU, GDPR applies. Sensitive data like health information adds hours for access control, logging and hosting decisions.
• How settled the idea is: unclear requirements are the most expensive driver of all, because they turn into changes mid-build.

The cheapest way to cut cost is to cut scope, not quality. A first version with the three features that matter beats a half-finished one with ten. My breakdown of MVP development cost shows how to draw that line.

Running costs after launch

The build is only the first bill. These follow, and they weigh heavier on native apps:

• Developer accounts: the Apple Developer Program costs 99 USD a year, billed in local currency. Google Play charges a small one-time fee. You only pay either if you publish to the stores.
• Store commission: sell digital goods or subscriptions inside a store app, and Apple and Google typically take 15-30% of it. A web app can charge customers directly through Stripe and pay normal card fees.
• Hosting: a small app can typically run on EU-based hosting for tens of euros a month. It grows with traffic, file storage and backups.
• Maintenance: my rule of thumb is to budget 15-20% of the build cost per year for updates, security patches and small fixes.
• New iOS and Android versions: native apps have to keep up, and Google Play requires apps to target a recent Android version to stay available to new users on newer phones.

That last point is why the gap between web and native keeps growing. You update a web app in one place. Two native apps are two codebases to maintain, test and push through review. I break down the yearly numbers in my post on web app maintenance cost.

When a web app or PWA is enough

A web app or PWA is usually enough when:

• the app mainly shows and collects data: bookings, orders, forms, dashboards, a customer portal
• your users are customers or staff you can simply send a link to
• people also use it on a laptop, which is the norm in B2B
• you want to test the idea quickly and change it often
• home screen install and push notifications are enough of an "app feel" for your users

Go native or cross-platform when:

• the app talks to Bluetooth devices, NFC or other hardware on iPhone, where Safari doesn't support the web APIs for it
• it needs to work in the background, like tracking location while the phone is in a pocket
• it relies on heavy graphics, games, AR or advanced camera features
• you sell to consumers who find apps by searching the App Store
• your users expect widgets, an Apple Watch app or similar

My own work is web apps and PWAs built with Laravel and React. If your project clearly belongs in the second list from day one, a developer or studio specializing in iOS and Android is usually a better fit than me. If you're still torn, my comparison of web apps, native apps and PWAs goes deeper.

Start on the web, go native when the data says so

For most businesses I recommend starting with a web app or PWA and building the backend so it can be reused. In practice, all business logic sits behind an API (a defined way for other software to talk to your server), and the web app is simply the first client. If you later need native apps, they plug into the same API, and the backend hours aren't wasted.

The order usually looks like this:

1. Build the backend and a web app with the core features.
2. Turn it into a PWA if users benefit from installing it and getting push notifications.
3. Measure how it's used and what users ask for.
4. Build native apps when there's a concrete reason, like a feature that needs it or App Store traffic worth paying for.

There's also a middle path: wrapping the web app in a native shell with a tool like Capacitor and publishing it to the stores. It can work, but Apple's review guidelines say an app has to offer more than a repackaged website, so budget extra time to get through review.

Next steps: get a quote you can budget against

A quote is only as good as the brief behind it. Run through this list before you contact developers.

With those answers, any developer can give you an estimate you can plan around. For more price points on web apps specifically, see my web app development cost breakdown. And if you'd like to see how I approach these builds, here's how I work on custom web apps and platforms.

Frequently asked questions

Can a PWA be listed in the App Store or Google Play?+

Not on its own. A PWA installs from the browser, so it doesn't appear in either store by default. Google Play is fairly open to web apps packaged as Android apps, while Apple asks more of an app before it passes review. If being in both stores from launch matters to you, cross-platform is usually the more predictable route.

How long does it take to build an app?+

A simple web app or PWA typically takes one to three months from discovery to launch with one senior developer. Two native apps often take twice as long, because the interface is built and tested twice. The biggest delays are rarely the code itself. They're waiting on decisions, content and access to the systems the app connects to.

Is an offshore team cheaper for app development?+

Often on the hourly rate, not always on the total. Rates in Eastern Europe or Asia can be well below Western European ones, but time zone gaps, handoffs and rework eat into the saving. If you go that way, invest in a clear written spec, insist the code lives in your own repository, and have someone you trust review it early.

Will a web app feel slower than a native app?+

For most business apps, users won't notice a difference. A well-built web app loads and responds quickly, especially once it's installed as a PWA. The gap shows with heavy graphics, complex animation, large amounts of data stored on the phone, and games. That's where native is still clearly better, and where the extra cost pays off.