A mobile build estimate counts screens. A ship estimate counts the days between code-complete and the first public install. The longest single line in mine is a free form at a credit bureau.
A shippable mobile app is the app plus two store accounts, two signing identities, a push key, a privacy manifest, store metadata, two privacy declarations and an export compliance flag. Register as a company and both stores want a D-U-N-S Number before either account exists. Apple allows up to 7 business days for that. Google says up to 28.
Neither delay is engineering. One is a form at Dun & Bradstreet; the other is twelve strangers keeping your beta installed for a fortnight. Which you get is decided by a radio button on a sign-up page. Every figure below is Apple’s, Google’s, or derived from figures printed here, and I flag the ones I picked.
What is in a shippable mobile app besides the app
Besides the app: two store accounts, a signing identity per platform, a push key, a privacy manifest, store metadata, screenshots, two privacy declarations, an export compliance key, crash reporting, identity verification at both stores, and in-app account deletion. That is the enumerable half: a form or a file or an afternoon each. The other half is waiting, priced in calendar days.
One signing identity has a trap in it. Google signs the final APK itself, and its Play App Signing page says you “must register the Google-held app signing key fingerprint with your API providers”, rather than the local upload key you generated. Get it the wrong way round and Maps and OAuth sign-in work on your machine, work on a test track, then fail on production. Google can reset a lost upload key; one you hold yourself “cannot be reset”.
Two more are files no screen count contains. Apple’s page on adding a privacy manifest says that since 12 February 2025 submissions “must contain a valid privacy manifest file for a certain number of commonly used third-party SDKs”, a PrivacyInfo.xcprivacy list at the bundle root covering your data collection and your dependencies’. Apple’s list of SDKs that require a privacy manifest and signature ran to 86 entries when I counted it on 29 October 2026, Capacitor and Flutter included — so the framework choice I argued in native or cross-platform won’t save you. (Apple’s documentation pages render in JavaScript, so a curl returns an empty shell.)
The last one is a boolean, ITSAppUsesNonExemptEncryption in the build. Apple’s Complying with Encryption Export Regulations says an app distributed outside the U.S. or Canada “is subject to U.S. export laws, regardless of where your legal entity is based” — a sentence that earns its place in an article written from Kathmandu.
The ship tail is the calendar days between code-complete and first public install in which no engineering shortens the wait.
How long does app review take on the App Store and on Google Play?
Apple’s App Review page says it reviews “at least 50% of submissions in less than 24 hours and 90% in less than 48 hours”, while Google Play Console Help on publishing your app says review can run “up to seven days or longer in exceptional cases”. Google’s seven is narrower than it reads: it sits under a note about “certain developer accounts”, and the standard-publishing bullet qualifies it as “Certain apps may be subject to extended reviews”.
Review capacity is not what makes the cheap store the slow one. Both companies check who you are before you publish, and both say so on their registration pages. What differs is the currency. Apple takes a D-U-N-S Number from a company and two-factor authentication from an individual. Google takes the same D-U-N-S Number from a company, and from a personal account fourteen days of twelve other people’s device time. The expensive check is the one that doesn’t look like an identity check, and a plan built on Apple’s reputation as the slow reviewer budgets the wrong fortnight.
Google Play’s 14-day closed test applies to personal accounts only
Twelve testers, fourteen unbroken days, and only on a personal account opened after 13 November 2023. Google Play Console Help’s page on testing requirements for new personal developer accounts scopes itself in its first line to personal accounts, and the rule reads:
Developers with personal accounts created after November 13, 2023, must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days.
Google’s own step list carries the scope too: its registration page gives the step as “Optional: Step 6: Meet testing requirements and device verification requirements (Personal accounts only)”, which files the closed test beside device verification rather than quality. I read it as an identity measure priced in calendar days, and a published pass mark would change my mind. There isn’t one.
The closed test is 14 days. Google says the production-access review “usually takes seven days or less”, and the publishing page puts the release review at up to seven more. 14 + 7 + 7 = 28 calendar days between a finished build and a stranger’s first install. Only the 14 is a floor; the other two are ceilings Google publishes in its own words, so 28 is the planning number and 14 is the one you can’t argue with.
Derive it a second time from recruitment, because the 14-day clock starts when the twelfth tester opts in, not when the build goes up. Getting 12 real devices opted in takes some days, and I’ll pick 3 — a round number I chose, the only input that isn’t Google’s. 3 + 14 = 17 days. 17 + 7 = 24 to production access, and 24 + 7 = 31 to the public release. The 3-day gap against the gate-side 28 is recruitment.
Getting a D-U-N-S Number for a company account at either store
Getting a D-U-N-S Number is the line item most ship estimates miss, it gates company registration at both stores, and the two stores price the same free request two and a half to three times apart. Apple’s D-U-N-S Number page carries its figure under the second of three headings, “Receiving and managing your D-U-N-S Number”:
After requesting a D-U-N-S Number, please allow up to 5 business days to receive your number from D&B. Expediting your D-U-N-S Number creation process will not shorten this waiting period.
Two more business days follow in the paragraph after, for Apple “to receive your information from D&B”. So the ladder. Up to 5 + 2 = up to 7 US business days. 7 ÷ 5 business days per week = 1.4 weeks. Start on a Monday and it lands on the Wednesday of the following week, 9 calendar days on. Start on a Thursday and it’s 11.
Google prices it higher. Google Play Console Help on required information for a developer account says a company account “must provide a D-U-N-S number”, and the Android developer verification FAQ, under its D-U-N-S question, says:
The process can take up to 28 days so you should make preparations to obtain a D-U-N-S number.
One form, two platform owners, no shared unit. 28 ÷ 11 = 2.5 and 28 ÷ 9 = 3.1 against the nine-to-eleven band above, so Google’s ceiling runs 2.5 to 3.1 times Apple’s. I plan on Google’s 28: a sensitivity analysis the counterparty published beats one you ran yourself. Our week runs Sunday to Friday and both clocks count US business days. Monday to Friday overlaps. Sunday doesn’t. We start the request the day a contract is signed, never the day a build is code-complete.
And there’s a way around all of it. Apple’s D-U-N-S page says “If you’re enrolling as an individual, you don’t need a D-U-N-S Number”, and Google’s test is personal-accounts-only, so the routes swap waits. The company route is 28 days of D-U-N-S plus a release review of up to 7: 28 + 7 = 35 days end to end. The individual route is the closed test and its two reviews, 14 + 7 + 7 = 28, shorter end to end by 35 − 28 = 7 days. Measured as ship tail the individual route is the longer by a factor of four: a D-U-N-S request needs no build and a closed test needs twelve installs. 28 ÷ 7 = 4. Apple’s enrolment page settles it for some firms anyway: “We do not accept DBAs, fictitious business names, trade names, or branches.”
What happens when an Apple distribution certificate expires
When an iOS distribution certificate expires, your apps on the App Store stay up so long as the membership is valid, and what stops is your ability to upload a new build. Apple says it in the third of the four sections on its Certificates overview page, headed “Expired or revoked certificates”:
If your Apple Developer Program membership is valid, your existing apps on the App Store won’t be affected. However, you’ll no longer be able to upload new apps or updates signed with the expired or revoked certificate to App Store Connect.
The store listing survives. The release train doesn’t.
Now the part I had wrong. I’ve repeated “distribution certificates last three years, provisioning profiles last one year” for years, and neither number is on that page. The provisioning profiles page gives no validity period either, only that an expired profile is one “you need to regenerate”. Three years might well be right. I wouldn’t hang a release date on it without reading the expiry off the certificate.
Push carries a stranger constraint. Under “Refresh your token regularly” on establishing a token-based connection to APNs — another of those JavaScript-rendered pages — Apple says: “Refresh your token no more than once every 20 minutes and no less than once every 60 minutes.” A floor and a ceiling on re-signing a JWT, with a 403 ExpiredProviderToken once iat drifts past the hour.
What Google Play counts as a bad crash rate
Google Play counts 1.09% of daily users hitting a user-perceived crash across all device models as bad behaviour, and 8% on a single device model. The tolerance is Google’s, on its page about bad behaviour thresholds for core vitals: “At least 1.09% of daily users experience a user-perceived crash, across all device models.” The distribution it reads off is daily users, not sessions, and not installs. The derived value depends on scale: at 10,000 daily users, a base I picked rather than counted, 10,000 × 0.0109 = 109 a day; at the 0.47% ANR threshold, 10,000 × 0.0047 = 47.
Google says an app over the line is “likely to be less discoverable on Google Play”, and that “a warning may be displayed on your app’s store listing”. A warning on your own listing. Crash reporting is a ship requirement, not a version-two nice-to-have.
Cut push notifications from the first release
Cut push notifications from the first release and you remove the APNs key, the annual provider-certificate clock, the Firebase Cloud Messaging wiring and a class of review questions about background behaviour. Push is the largest thing we take out of a version one, and nobody misses it.
And if push survives the cut, don’t run it on a certificate. Apple’s document on establishing a certificate-based connection to APNs says a provider certificate is tied to a single app and is “valid for a year”, and that “it’s often simpler to use token-based authentication to support multiple apps”. The trade is a slightly smaller request against an annual outage you must diary. I wouldn’t put a push certificate on anything built in 2026, and only a provider stack that can’t sign a JWT would change my mind.
Also cut: tablet and foldable layouts, any watch target, deep links, and in-app purchase, whose code side is in code that moves money.
What stays, because none of it is optional and all of it is invisible in a screen count: crash reporting, the privacy manifest, the Data safety form, the export compliance key, and in-app account deletion. Google says “Even developers with apps that do not collect any user data must complete this form”. Account deletion is the second of the seven sentences in guideline 5.1.1(v) of the App Store Review Guidelines: “If your app supports account creation, you must also offer account deletion within the app.” It’s a build task that appears in no feature list anyone writes.
The ship tail with the recruitment estimate tripled
Triple the one input I chose and the personal route gets worse while the recommendation gets louder. The 14-day closed test is a published minimum with nothing to derate, and derating Google’s two seven-day ceilings upward gives a number no page supports. The only genuine estimate here is my 3 days of tester recruitment. 3 × 3 = 9. 9 + 14 = 23, then 23 + 7 = 30 and 30 + 7 = 37 against the gate-side 28. The gap between Google’s pages and the calendar widens from 3 to 9 days, all of it recruitment that could have run before code-complete.
Halve the scope and the tail collapses. iOS only, on a company account that already holds its D-U-N-S Number, shipping an update rather than a first release: 90% of submissions clear in under 48 hours, so the tail is about 2 days. 28 ÷ 2 = 14x out of identical engineering. Double it instead (both platforms, both first releases, new accounts at each store) and a company route is still 35 days, not the 35 + 35 = 70 people reach for, because one D-U-N-S request serves both stores and the reviews run at different companies. Do not add the floors.
The gates run in parallel, and they run before the code does. The D-U-N-S request, the store accounts, the screenshots, the Data safety form and the export compliance key don’t depend on finished code: every one could start the day a contract is signed. A ship estimate that schedules them after code-complete isn’t an estimate. It’s a confession that nobody owned them. Our rule on any mobile build under software development: the store accounts, the signing identities and the D-U-N-S request go in week one, and the account type is settled in the same meeting as the price.