What it costs to ship to the app stores

Budget $99 a year for Apple and $25 once for Google, then stop thinking about fees. The store costs that move a plan are a commission of 15 or 30 percent on anything classed as a digital good, a review queue sitting between your finished build and your launch date, and an annual maintenance bill for platform deadlines. None of the three appears in a build quote, which is exactly why they surprise people.

Every figure below links to the Apple or Google page it came from. Two of the numbers you most want are genuinely unsettled, and this piece says so rather than picking one.

The account fees are the small part

The Apple Developer Program is $99 a year and it renews. A Google Play Console account is a one-time $25 registration fee for the life of the account.

The real cost here is time, and it lands on organisations. Apple requires a D-U-N-S number for every organisation enrolling, excluding government entities, plus a real legal entity rather than a trading name, a publicly available website associated with the organisation, and a work email address on the organisation’s domain. Google verifies organisation accounts against a D-U-N-S profile too, and warns the Dun & Bradstreet process can take up to 30 days. Start it the week you decide to build, not the week you submit.

Against our published minimum for a build, $7,500, both fees are rounding errors. That figure and every other EdgeBrain band here are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

The commission is the number that compounds

A build is paid once. Commission is paid for as long as the product earns, which makes it a line in unit economics rather than a launch cost. On Apple the standard split leaves you 70 percent of the price. The App Store Small Business Program drops the commission to 15 percent for developers who earned no more than $1 million in total proceeds during the previous calendar year, and the threshold is measured across all associated developer accounts. If you pass $1 million during the current year, the standard rate applies to future sales; if your proceeds fall back under it in a later year, you re-qualify the year after. You have to enrol, it is not applied for you.

Subscriptions are treated separately. Apple publishes 70 percent of the subscription price during a subscriber’s first year of service, rising to 85 percent after that subscriber accumulates one year of paid service in the same subscription group, and Small Business Program members receive 85 percent from the first day. So churn is not only a growth problem on iOS. It resets your rate.

In most Google Play markets the service fee is 15 percent on the first $1 million a developer earns each year and 30 percent above that, with 15 percent on automatically renewing subscriptions regardless of revenue earned.

Now the part to check rather than memorise. On 30 June 2026 Google separated the service fee from a billing fee in the United States, the EEA and the United Kingdom. The service fee is charged whether payment runs through Google Play billing, an alternative billing system or a link out to your own site, and a 5 percent billing fee applies on top only when Google Play’s own billing handles the transaction. The rest of the card is keyed to new versus existing installs and to which Play programmes you are in. Read the percentages off Google’s service fees page on the day you model it, because this one moved last quarter.

Apple’s equivalent is worse for planning. The commission Apple may charge on a purchase completed on the web after a link out of a US app has been in litigation since the 2025 injunction in Epic v. Apple, and is still before the court. Model at the standard rate and treat any reduction as upside. Forecasting a recurring per-user cost before launch is the habit we argue for in forecasting LLM cost per user.

What counts as a digital good, which is the question that catches people

If the thing the customer buys is consumed inside your app, it is in-app purchase and the store takes a cut. If it is consumed outside the app, in the physical world, you must use something else and the store takes nothing. That line moves your economics more than your pricing does.

Apple’s guideline 3.1.1 is direct about the first half: unlocking features or functionality within your app, by way of example subscriptions, in-game currencies, game levels or access to premium content, must use in-app purchase, and apps may not use their own mechanisms such as licence keys, QR codes or cryptocurrency instead. Guideline 3.1.3(e) is as direct about the second: if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase.

So a furniture marketplace, a barber booking app and a field service tool all take card payments through Stripe or Apple Pay and pay the store nothing on those transactions. The same app adding a pro tier, credits or an ad-free unlock is in in-app purchase for that part, at the rates above.

The middle is where the money goes. A coaching app where a human writes the plan. A ticketing app where the ticket is scanned at a physical door. A course platform where recorded video is the product but a live cohort call is part of the package. Each has been argued both ways, and the line is drawn by App Review on the day, against your specific screens.

Get the answer before you design the payments layer. The expensive shape of this mistake is a Stripe integration, with the webhook handling that makes it trustworthy, built and then discarded because the feature it gated turned out to require in-app purchase. That is a rebuild of the most consequence-carrying code in the app, landing in the week you wanted to launch. We have watched a client absorb exactly that, on a subscription we had all read as a service rather than as content, and nobody asked early because the answer felt obvious. It was not. The wider version of that arithmetic is in what a third-party integration really costs.

Review is a schedule risk, not a line item

Apple publishes that on average 90 percent of submissions are reviewed in less than 24 hours. Google publishes that review can take up to 7 days or longer in exceptional cases. Both are true, and neither is the number to plan against, because your first submission is not an average submission. The average submission is version 4.2 of an app whose privacy labels, permission strings and subscription screens were approved eighteen months ago.

Apple also publishes what comes back: on average over 40 percent of unresolved issues relate to guideline 2.1, App Completeness, covering crashes, placeholder content and, in Apple’s own wording, whether you included demo account info and turned on your back-end service. A staging API switched off over a weekend is a rejection.

Then the specific ones, roughly in order of how often they bite a first release.

• Account deletion. Guideline 5.1.1(v): if your app supports account creation, you must also offer account deletion within the app. Not a support email, not a form on your website. In the app.
• Login services. Guideline 4.8: if you use a third-party or social login to set up the primary account, you must also offer an equivalent option that limits collection to name and email, lets the user keep the email address private, and does not collect app interactions for advertising without consent. Google Sign In on its own is a rejection.
• Privacy declarations. Apple requires app privacy details to submit any new app or update, covering data collected by your third-party partners, which means your analytics and advertising SDKs and not only your own code. Google requires the Data safety formfrom every developer with a published app, including closed and open testing tracks, and treats a mismatch between declaration and behaviour as an enforcement matter up to blocked updates or removal.
• Purpose strings.Apple asks that purpose strings clearly and completely describe your use of the data. A string reading “this app needs access to your location” describes nothing, and it costs a full round trip.
• Subscription presentation. Guideline 3.1.2 asks that before you ask a customer to subscribe you clearly describe what they get for the price, and points at Schedule 2 of the Apple Developer Program License Agreement for the disclosures themselves. Read that schedule rather than guessing at it. A paywall showing a price and a button describes nothing.

A rejection does not cost you the review time. It costs you the round trip: fix, rebuild, re-upload, re-queue behind everyone else. When the fix is a string or a screenshot that is a day or two. When the fix is a feature you never built, and in-app account deletion is the classic, it is a sprint, happening with a launch date already in the calendar.

One hard floor worth knowing before you promise anyone anything: a Google Play personal developer account created after 13 November 2023 must run a closed test with a minimum of 12 testers opted in continuously for at least 14 days before it can apply for production access. That is two weeks that exist regardless of how finished the code is.

Hence the rule. The first submission is never the week before the launch date. Put a complete build in front of both reviewers weeks early, even if it goes no further than TestFlight and a closed track. What you buy is not approval. It is the list of objections, early enough to be a task.

This changes how we quote, and it reads as a weaker promise than you may be offered elsewhere. We do not commit to an App Store approval date. We commit to a complete, guideline-reviewed build submitted on a date, and to turning rejections around inside the engagement. A studio promising an approval date is promising something it does not control, which is a different failure from the estimation risk we take apart in fixed price versus time and materials.

The recurring bill nobody budgets

Three platform deadlines arrive on a schedule you do not set, every year, whether or not you shipped anything.

Android target API level. From 31 August 2026, new apps and app updates submitted to Google Play must target Android 16, API level 36, or higher, and existing apps must target Android 15, API level 35, or higher to stay available to new users on devices running a newer OS than your target. An extension to 1 November 2026 can be requested. Next year the numbers move up one and the deadline returns.

Apple SDK minimum. Since 28 April 2026, uploads to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26. Same annual pattern, and missing it means you cannot ship a hotfix.

Privacy manifests. Since 1 May 2024, Apple has required approved reasons in a privacy manifest for a published list of APIs, and an app that newly adds an SDK from Apple’s commonly used third-party SDK list needs that SDK’s own privacy manifest and a valid signature where it is a binary dependency. Your dependency upgrades are now partly a compliance exercise, and an abandoned SDK is a shipping blocker rather than a tidiness problem.

Under all three sits the unnumbered one: a new iOS and a new Android ship every autumn, and behaviour changes reach users whether or not you recompiled.

None of that is a large budget. It is a persistent one. We publish ongoing product work at $3,500 to $6,000 a month and a support retainer from $2,500 a month, and mobile is where that line is least optional: a web app nobody maintains merely ages, while a mobile app nobody maintains eventually cannot be updated at all. Those bands are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

Where we would tell you not to do this

If the only reason you want an app is distribution, because you assume the store is where people look, a website is cheaper on every axis in this article. No program fee, no commission, no review queue, no annual API level deadline, and a fix ships in an afternoon instead of waiting on a reviewer. That decision is set out in whether you need a mobile app or a website. More often than we would like, the honest answer is a fast responsive site and a home screen shortcut.

If you are still testing whether anyone wants the product, everything above sits on top of a build that is already the most expensive shape of software we sell. Our published bands: a mobile client on an existing API is $20,000 to $32,000, a cross-platform MVP is $24,000 to $40,000, and full native-grade mobile is $40,000 to $60,000 over 10 to 14 weeks. Those figures are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff. Which of the three you are buying is settled in React Native versus native, and every store rule here applies identically to all three, because the store does not care how the binary was produced.

And if your launch date is three weeks out, we are the wrong studio, and so is everyone else. A new personal Google Play account carries a 14-day closed testing floor before production access can even be applied for, and that is before Apple has looked at your account deletion flow.

The compressed version

$99 a year and $25 once, plus a D-U-N-S number that can take up to 30 days. Commission applies only to digital goods, at 15 or 30 percent depending on the Small Business Program, your subscription tenure and, on Google Play in the US, EEA and UK, a fee structure that changed in June 2026 and should be read fresh. Decide whether what you sell is a digital good before you design payments. Submit weeks early and treat the first review as a free defect report. Then budget a year of platform deadlines you did not choose.

To map that onto what you are actually building, send us the feature list and mark which parts are paid, or start from how we scope mobile work. The digital goods question is usually answerable in one reading, and it changes the shape of the build rather than the size of the invoice.