Mobile app development cost: what actually drives the price

Ask three agencies to quote "a mobile app for my business" and you get three numbers that can differ by 3x. The gap is not markup, it is scope: each agency silently read your one-line brief as a different job. This piece does not give you a number. It shows you exactly which decisions move the price, so you can read a quote and know what it actually contains.

Where the 3x gap actually comes from

"Mobile app" covers wildly different jobs. One quote might cover a clickable UI shell with no working login. Another covers a production build with real authentication, a backend, and store submission handled end to end. A third quietly assumes you already have a backend and only prices the screens. None of these lies about the number, they just answer a different question than the one you asked.

The fix is not asking for a lower number. It is asking each agency to list what is included and what is not, item by item, against the list below.

One codebase or two: what the platform decision changes

The first real fork in cost is whether you build one codebase for both platforms or two separate native apps.

This is why our own mobile app development work defaults to React Native and Expo: it is the right answer for the large majority of business apps, and it is what keeps a single team able to ship both stores from one codebase.

Backend or no backend: the single biggest variable

An app that only displays static content, a menu, a catalog, a set of read-only pages, needs no backend at all. The moment you add accounts, data that syncs across devices, or anything an admin needs to update without a new app release, you need a backend: either a custom one, or a backend-as-a-service platform like Supabase or Firebase configured properly (auth, database, row-level security, storage rules).

This decision moves more cost than any single integration on this page, because it is not a feature, it is an entire second system that has to be designed, secured and kept running. If your app already has a web version with a working backend, the mobile client can often reuse it. That is one of the cheapest paths to a real app that exists.

Payment, subscriptions and store commission

Selling digital goods or subscriptions inside the app triggers Apple's and Google's in-app purchase rules, and both take a commission on that revenue (Apple and Google's own developer terms cover the exact percentage and the small-business reduced rate; check the current terms for your account before pricing this in). Selling physical goods or services can usually route through your own payment provider outside the store's cut, but the rules around what counts as "digital" versus "physical" are specific and worth checking against the store's own guidelines before you scope it.

Subscriptions add their own engineering: trial periods, renewal, cancellation, and restoring a purchase on a new device. None of that is optional once you offer a subscription, and none of it is visible in a demo that only shows the checkout screen once.

Push, maps, camera, location: each one is its own line item

Individually small features are not free just because they sound small. The ranges below are rough effort weight based on how this kind of work is usually scoped, not a quote, your exact integration and edge cases move them.

Fixed costs: developer accounts and infrastructure

Separate from any agency's labor, three platform fees apply to every store app, and they rarely get itemized in a quote:

The Apple and Google accounts have to belong to you, not to your agency or to the AI tool that scaffolded the app. Losing access to that account later means losing the ability to ship an update to an app that is already live.

Getting to the store

Beyond the account fees, submission itself is real work: store listing copy, screenshots at the required device sizes, a privacy policy, and Apple's App Privacy questionnaire or Google's Data Safety form filled out accurately, not copy-pasted from another app. Apple's review also weighs whether the app reads as your own product with real functionality, not a template's default output; we covered exactly which App Store guideline sections trip up AI-generated apps in a separate piece if that is your starting point. Budget for at least one review round-trip: first submissions get rejected on a metadata or permissions detail often enough that it should not derail a launch date.

After launch: maintenance, OS versions, store rule changes

A store app is not done at launch the way a deployed website is. Apple and Google ship new OS versions yearly, and the SDK your app is built on eventually requires an upgrade to stay installable on new devices. Store policies change too, sometimes requiring a new privacy disclosure or a permission justification you did not need last year. None of this is optional maintenance, it is what keeps the app in the store at all. This is the exact gap our LumiCare package is built to close: certificate renewal, SDK bumps, and the store re-reviews that never really stop.

The right way to cut scope

Do not cut authentication, data access rules, or payment correctness to save money, those failures cost far more later. Cut instead: launch on the platform your actual users are on and add the second one once you have traction, ship without a backend if your content genuinely does not need one yet, and defer non-core integrations like maps or camera to a second release. A form that spits out one instant number the moment you answer four questions cannot know any of these decisions, so treat that number as a starting guess, not a quote.

FAQ

Should I ask for a fixed price or a scope-based quote?
Scope-based, with the items on this page named explicitly. A fixed price only means something once both sides agree what is included.

When does native (Swift/Kotlin) actually come out cheaper than React Native?
Almost never for a first version. It can make sense later, for one platform only, if that app leans on something the bridge handles poorly, like sustained background processing.

Is it cheaper to add a backend later or build it from the start?
From the start, if you already know you will need accounts or synced data. Retrofitting a backend into an app built as static content means rebuilding data flow you already shipped once.

Does Apple and Google's commission apply to every payment?
No. It applies to digital goods and subscriptions purchased in-app. Physical goods and most services can typically route through your own payment provider; check the current store guidelines for your category before scoping it.

Should I launch an MVP on one platform and add the second later?
Only if your users are genuinely concentrated on one OS. If your audience is mixed, launching on one platform just delays finding out whether the other half converts.