Getting Your MVP Approved on the App Store and Google Play
Getting an MVP into both stores costs $124 in developer fees ($99 a year for Apple, $25 once for Google), takes 1 to 5 days of review per submission once your accounts exist, and fails most often for a handful of preventable reasons. The time sink is not the review but account setup: an organization account on either store needs a D-U-N-S number, which can take 2 to 4 weeks, and a new personal Google Play account must run a closed test with at least 12 testers for 14 days before it may publish at all. So the store path starts the day you sign the build contract, not the day the code is finished.
Developer accounts: fees, identity checks and waiting times
Both accounts must belong to you, never to your studio. If a vendor offers to publish under their account "to save time", decline: the app, its reviews and its subscribers would live in an account you do not control. The full list is in which accounts a founder must own before the build starts. Here is what each store asks for as of October 2026.
| Apple Developer Program | Google Play Console | |
|---|---|---|
| Fee | $99 per year | $25, one time |
| Account types | Individual, or Organization (a registered legal entity) | Personal, or Organization |
| Identity check | Individuals: government ID in the Apple Developer app. Organizations: D-U-N-S number, a website on your domain, proof you can sign for the company | Government ID plus phone and email verification. Organizations: D-U-N-S number and a company address |
| Time to approval | Individuals: 1 to 2 days. Organizations: 1 to 4 weeks, almost all of it waiting on D-U-N-S | Personal: 1 to 3 days. Organizations: 1 to 3 weeks |
| Gate before publishing | None, but a first app from a new account is reviewed more strictly | Personal accounts opened after November 2023: a closed test with at least 12 testers for 14 consecutive days, then an application for production access |
| Name shown to users | Individual: your legal name. Organization: the company name | Your developer name, plus a verified address and contact details if you sell anything |
| Commission on digital sales | 30%, or 15% under the Small Business Program (under $1M a year) | 15% on the first $1M a year, 30% above it |
Two decisions follow. Register as an organization if you have a company, because an individual Apple account prints your personal name under the app. And start the D-U-N-S request on day one: it is free through Dun and Bradstreet, but it is the longest wait in the process. Opened on day one, the accounts are ready while the build runs and a 14-day build can be live in both stores around day 17 to 24; opened after code complete, day 30 to 50 is typical.
Review times in 2026: what to actually expect
Apple publishes that 90% of submissions are reviewed within 24 hours, and for updates to a live app that is accurate. A first submission of a new app takes 1 to 3 days in our experience, and it attracts a "Guideline 2.1 Information Needed" message or a rejection far more often than an update does. Each rejection restarts the clock, so plan 1 to 2 weeks from first submission to live, with two review cycles budgeted.
Google Play states that review can take up to 7 days. Most new apps clear in 1 to 3 days, but apps from brand-new accounts, apps requesting sensitive permissions and apps aimed at children regularly take the full week. Google also reviews the first release on a closed-testing track, so testers can wait a day or two for your first test build.
The rejection reasons that hit MVPs most
Reviewers check a fixed list, and MVPs trip the same items because the build was scoped around users, not reviewers. These are the ones we see repeatedly, with the guideline number from the rejection message.
App Store
- 2.1 App Completeness. A crash, a dead button, "Coming soon" text, or a reviewer who cannot log in. Fix: a demo account in the review notes, zero placeholders, a test of the exact uploaded build on a real device.
- 4.2 Minimum Functionality. The app is a website in a shell. Fix: real native capability (push notifications, camera, offline mode, Face ID, widgets) or launch as a web app first. The most common rejection for MVPs built on web app builders.
- 5.1.1 Data Collection and Storage. Forced sign-up before any value, a permission prompt with no explanation, a missing privacy policy, or no way to delete an account inside the app (required since 2022). Fix: let users browse first, write one sentence per permission, build the delete-account button before submission.
- 3.1.1 In-App Purchase. Subscriptions and digital content sold through Stripe or a web checkout inside the app. Apple requires its own purchase system for digital goods, at 15% to 30% commission. Physical goods and real-world services (a cleaning booking, a delivery) may use any payment provider.
- 4.8 Login Services. Google or Facebook login with no option that limits data collection. Fix: add Sign in with Apple or an email-only login.
- 2.3 Accurate Metadata. Screenshots showing features the build lacks, a description that mentions Android, or "beta" in the app name.
- 1.2 User-Generated Content. Users can post, but there is no report button, no block function and no stated moderation process. All three are required.
Google Play
- Data safety form mismatch. You declared "no data collected" while an analytics or crash-reporting kit sends device identifiers. Google scans the binary and compares. Fix: list every third-party kit before filling in the form.
- Privacy policy missing or unreachable. It must be a live URL on your domain, linked in the listing and reachable inside the app.
- Target API level too old. New apps must target a recent Android version (API level 35 was the 2025 bar; expect it to rise each August). An app on an old template fails before a human looks at it.
- Sensitive permissions. Background location, SMS, call log and all-files access each need a declaration and a demo video. Most MVPs can drop them or go foreground-only.
- Account deletion. Google requires an in-app flow and a web link for deletion requests. Reuse the Apple work.
- Play Billing for digital goods. Same rule as Apple; services and physical goods are exempt.
- Deceptive metadata. Keyword stuffing in the title, a feature graphic promising features you lack, an icon that imitates a known brand.
Most of these are spec decisions, not bugs. Account deletion, the privacy policy, the demo account and the billing route belong in the scope. A spec that skips them produces an app that works and cannot ship, one of the most expensive MVP mistakes we see.
What to prepare before you press submit
The listing is a small project of its own: 8 to 20 hours, or $800 to $3,000 if a studio bills it by the hour. Every item below is required on at least one store.
- Privacy policy URL on your own domain, matching what the app actually collects.
- Support URL or email that a human monitors. Apple requires a support URL; Google shows a contact email publicly.
- Demo credentials pre-loaded with realistic data so every screen has content.
- Review notes: five sentences on what the app does, how to reach each feature and why any unusual permission exists.
- Screenshots: Apple needs the 6.9-inch and 6.5-inch iPhone sets (plus iPad if supported); Google needs 2 or more phone screenshots and a 1024 by 500 feature graphic. A 1024 by 1024 icon serves both.
- Age rating questionnaires, App Privacy labels (Apple) and the Data safety form (Google), answered from the real list of kits in the build.
- Export compliance answer on Apple; standard HTTPS usually qualifies for the exemption.
- Account deletion flow in the app plus a web page for deletion requests.
- A clean build on real devices, not the simulator. The crash that rejects you usually happens only on a 3-year-old phone.
Put every item into your acceptance criteria so "done" includes "submittable"; MVP acceptance criteria: how to define done before you pay shows the format. Then ask every vendor one direct question: "Is store submission, including rejection cycles, inside the fixed price?" Listing work is one of the hidden costs of building an MVP that quotes most often leave out, and a rejection cycle costs 2 to 6 hours of fixes plus 1 to 3 calendar days. Budget two. If nobody on the team owns a Mac, add $0 to $100 a month for a cloud build service such as Expo EAS or Codemagic.
The TestFlight path: real users weeks before launch
You do not have to wait for approval to put the app in users' hands. Both platforms run free test tracks, and for an MVP they are where the first 20 to 50 users live, where retention data starts, and where a personal Google account satisfies the 14-day rule.
| Track | Platform | Max testers | Review before testers get it | How testers join |
|---|---|---|---|---|
| TestFlight internal | iOS | 100 (members of your App Store Connect team) | None; minutes after upload | Invitation email, install the TestFlight app |
| TestFlight external | iOS | 10,000 | Beta App Review, usually 1 to 2 days for the first build, hours for later ones | Email invite or a public link |
| Internal testing | Android | 100 | None; minutes | Email list, opt-in link |
| Closed testing | Android | Email lists or Google Groups, effectively unlimited | Policy review of the first release, 1 to 3 days | Opt-in link; counts toward the 12 testers for 14 days rule |
| Open testing | Android | Unlimited or capped by you | Full review | Anyone, from the Play Store listing |
TestFlight builds expire 90 days after upload, never a problem during an active MVP, and testers can send screenshots and crash reports from inside the TestFlight app, your cheapest usability lab. Our sequence: an internal build to you and 3 to 5 friendly users in week one; by the end of week two, an external TestFlight build and an Android closed-testing release to your first 20 to 50 people from the waitlist. Measure who comes back on day 7 and fix what they trip on, using the method in how to onboard your first users without a growth team. By the time the store approves the app, you have two weeks of behavior data and a reason to believe the launch is worth announcing.
Our recommendation
Do five things, in this order. Form the company and open both developer accounts as an organization on the day you sign the build contract, under an email you own. Decide the billing route before the spec is final: store billing for digital subscriptions, your own provider for services and physical goods. Put the privacy policy, account deletion, demo account and review notes into the acceptance criteria. Get a TestFlight build and an Android closed test to 20 to 50 real users by the end of week two. Budget two review cycles and treat a first-time approval as good fortune. And if the MVP sells software by subscription, decide early between selling on the web with the app as a companion, or accepting the 15% store commission that changes the math in how to price your product before the MVP ships.
If your MVP is mostly a web product with no need for the camera, push notifications or offline use, consider skipping the stores for the first version. A responsive web app has no review, no commission and no 90-day expiry, and it is the right first step for many of the products in how much a mobile app MVP costs in 2026. The stores reward apps that arrive with users already waiting, so earn those users first. The free MVP cost calculator gives you a baseline for either route.
At SquadPrime we build mobile and web MVPs at one fixed price from $4,000, agreed before the build starts, with senior professionals, a private preview link you can click by day 5, and 100% of the code yours on delivery. Bring the store questions above to the free call and you will leave with a scope, a fixed price and a launch date that accounts for Apple's and Google's calendars, not just ours.
Have a spec? Get one fixed price for it.
Bring your spec to a free 30-minute call. We will pressure-test the scope, flag anything that will inflate the build, and quote one fixed price (from $4,000). Live in 14 days or you don't pay, and you own all the code.
Get My Launch Date & Fixed PriceFAQ
How much does it cost to publish an MVP on the App Store and Google Play?
The store fees are $99 per year for the Apple Developer Program and a one-time $25 for a Google Play Console account, so $124 to be on both stores in year one. The real cost is the preparation around them: a privacy policy, screenshots for every required device size, store copy, the data-safety and privacy questionnaires and the review notes. For most MVPs that is 8 to 20 hours of work, which is $800 to $3,000 if you pay a studio by the hour, or zero extra if it is written into a fixed-price scope.
How long does App Store review take for a brand-new app?
Apple states that 90% of submissions are reviewed within 24 hours, and that holds for updates to existing apps. A first submission of a new app from a new account usually takes 1 to 3 days and more often gets a request for information or a rejection. Each rejection, fix and resubmission cycle adds 2 to 4 days, so plan 1 to 2 weeks from first submission to live and treat anything faster as a bonus.
Do I need a Mac to publish an iOS app?
You do not need to own one. Apple requires builds to be signed and uploaded with Apple tools, which run only on macOS, but cloud build services such as Expo EAS, Codemagic and Bitrise do that step on their own Macs for $0 to $100 per month, and any studio building your app already has this covered. What you must own is the Apple Developer account itself, registered to you or your company, not to the vendor.
Can I give early users my app before it is approved in the stores?
Yes, on both platforms, for free. On iOS, TestFlight lets up to 100 internal testers install a build minutes after upload with no review, and up to 10,000 external testers after a lighter Beta App Review that usually clears in 1 to 2 days. On Android, the Play Console internal testing track reaches up to 100 testers instantly, and closed testing reaches larger lists after a short review. Builds on TestFlight expire after 90 days, which is plenty for an MVP feedback round.
Why do MVPs get rejected under Guideline 4.2 Minimum Functionality?
Because Apple sees the app as a website in a shell. If the app only loads your web pages inside a frame and offers nothing a browser could not, reviewers reject it under 4.2. The fix is to give the app a real reason to be native: push notifications, camera or photo access, offline use, biometric login, widgets or share-sheet integration. If your MVP is genuinely a web product, launch it as a responsive web app first and add the native app once you have users asking for it.
All third-party names and trademarks belong to their respective owners and are used for identification only. Any market figures reflect our experience building MVPs and typical ranges as of October 26, 2026, and may change at any time. Spotted something outdated or inaccurate? Email talk@squadprime.com and we'll correct it promptly.
Related: How to Build a Chrome Extension MVP: Cost, Timeline, Store Review · How Much Does a Mobile App MVP Cost in 2026?