App Store vs Google Play: Submission Requirements Explained

Roughly a quarter of first-time App Store submissions get rejected, and Google Play's enforcement has gotten meaningfully stricter too. Most rejections trace back to a small, predictable set of causes, not bad luck. Here's exactly what each platform requires in 2026, including two rule changes that catch even experienced founders off guard.

This article assumes you already know the platform and cost basics, covered in our complete guide to app development for business. For a realistic build timeline that accounts for this submission process, see How Long Does It Take to Build an MVP Mobile App in India?, and for what happens after launch, see Mobile App Maintenance Costs: What Agencies Don't Tell You Upfront.

What Both Platforms Require, At Minimum

At a baseline, both platforms need: a registered developer account, a working app build that passes basic functionality review, complete metadata (name, description, keywords, screenshots), and a live privacy policy URL. Beyond that baseline, the two platforms diverge in specific, important ways.

Apple requires screenshots for the largest current iPhone display size, with iPad screenshots optional but recommended, and metadata including a 30-character title with a separate keywords field.

Google Play requires a minimum of 2 and maximum of 8 screenshots, plus a required 1024x500px feature graphic prominently displayed in the store listing, and has no separate keyword field, so keywords must appear naturally within the title and description itself.

The Google Play 12-Tester Rule Most Founders Miss

This is the single most commonly missed 2026 requirement. For personal Google Play developer accounts created after a certain date, Google now requires a mandatory 14-day closed testing period with at least 12 opted-in testers before an app can even apply for production review. This isn't optional, and it isn't something a solo founder can simply skip by being ready to launch, the 14 days must genuinely elapse with real, opted-in testers actively using a test build.

Practically, this means your realistic timeline needs to include recruiting testers and running this closed period well before your intended launch date, not discovering it exists the week you planned to submit.

The 2026 API Deadline That Blocks Submissions

From August 31, 2026, all new Android apps and updates must target API level 36 (Android 16) or higher, this is enforced, not a suggestion, submissions targeting an older API level will be blocked outright. Similarly, iOS submissions from a specific 2026 date onward must be built with the current iOS SDK or later. Platform requirements like this shift periodically and can take real time to roll out through your development toolchain, so it's worth confirming your build setup meets current requirements well before a submission deadline, not the week of.

Privacy Requirements That Actually Matter

Both platforms have become significantly stricter on privacy declarations, and mismatches here are one of the most common causes of rejection or later removal, not just at initial submission.

Apple's Privacy Nutrition Labels and Google Play's Data Safety section both require you to declare every category of data your app actually collects, why, and whether it's shared with third parties. The critical detail: your declared behavior must genuinely match your app's actual behavior. A generic privacy policy template that doesn't reflect what your app actually does gets flagged, not accepted as a formality.

If your app requires a login, both platforms also expect working demo credentials provided directly in your review notes, a reviewer who can't actually log in and test the core app functionality is one of the most avoidable rejection causes on this entire list.

Review Timelines: What to Actually Plan For

Apple: roughly 1 to 3 days for an update, 3 to 7 days for a first submission, though it's worth budgeting 5 to 7 days to account for a possible rejection and resubmission cycle.

Google Play: up to 7 to 10 working days for review, plus the mandatory 14-day closed testing period for new personal accounts covered above, meaning a genuinely realistic first-launch timeline on Google Play often runs closer to 3 to 4 weeks end to end, not the few days the raw review number alone suggests.

One practical tip worth following exactly: avoid modifying your Google Play store listing while a review is in progress, doing so commonly triggers listing-change delays on top of the standard review timeline.

The Top Rejection Reasons, and How to Avoid Them

Crashes or the app failing to launch. Thoroughly test on real devices, not just a simulator, before submitting, this remains one of the most common and most avoidable causes of rejection.

Missing or broken core functionality. Every visible button and feature genuinely needs to work, reviewers actively test UI elements, placeholder buttons or incomplete flows get caught.

Minimal functionality. Apple specifically rejects apps that are little more than a single web view or something that should genuinely be a website rather than a native app. Your app needs clear, meaningful functionality beyond what a mobile browser could already provide.

Deceptive or inaccurate metadata. Screenshots must show the app's actual current interface, both platforms reject listings where screenshots depict features that don't actually exist in the shipped app.

Privacy declaration mismatches. Covered above, but worth repeating as its own rejection category since it's become increasingly aggressively enforced on both platforms.