App Store & Google Play Submission Checklist

What Is App Store and Google Play Submission?

App Store and Google Play submission is the process of uploading a finished app build, its store listing, and its compliance data to Apple App Store Connect or Google Play Console, then passing each platform's review before the app goes live.

The two flows share a goal and almost nothing else.

Apple runs every submission through a human reviewer against its App Store Review Guidelines. Google leans on a mix of automated scanning plus human checks for policy-sensitive cases.

What a submission actually bundles together:

• The compiled binary (an .ipa for iOS, an Android App Bundle for Android)

• Store listing text and visual assets

• Privacy and data disclosures

• Content and age rating answers

• Release configuration

The apps affected fall into three buckets: native iOS builds shipped through Xcode, native Android builds, and cross-platform projects. Teams working on cross-platform app development still export to both native formats, so the two submission flows apply regardless of the framework underneath.

One number frames the stakes. Apple reviewed 7.77 million submissions in 2024 and rejected roughly 1 in 4, according to its App Store Transparency Report.

---

What Accounts Do You Need to Submit an App?

You need two paid developer accounts: the Apple Developer Program at $99/year and a Google Play Developer account at a one-time $25 fee. Each unlocks the console where you upload builds, manage listings, and submit for review.

SplitMetrics 2025 pricing data confirms the Apple fee recurs annually while the Google fee is paid once and grants indefinite Play Console access.

The account setup is where most first-time delays start. Not the code.

Apple Developer Program Enrollment

Enrollment splits into two paths: individual and organization.

Individual: faster, tied to your legal name, verified in roughly 24 to 48 hours.

Organization: requires a D-U-N-S Number from Dun & Bradstreet to confirm the business is a real legal entity.

The D-U-N-S lookup is free but can take days if your business isn't already registered. I've seen teams lose a full week here because nobody checked the D-U-N-S status before launch week.

Two-factor authentication on the Apple ID is mandatory before any build reaches App Store Connect.

Google Play Console Registration

Google's side got stricter after 2023.

New personal accounts created after November 13, 2023 must run a closed test with real testers before production access unlocks. The original bar was 20 testers for 14 continuous days.

The number changed: Google reduced the minimum from 20 to 12 testers on December 11, 2024, keeping the same 14-day window (PrimeTestLab, PTKD).

Requirement	Personal account (post-Nov 2023)	Organization account
Closed test	12 testers, 14 days	Exempt
Verification	Identity check	D-U-N-S + business details
Production access	After test completes	Immediate

Organization accounts skip the tester requirement entirely. That single fact pushes a lot of serious teams toward registering as an organization from day one.

---

What Are the Technical Requirements for App Builds?

Both stores enforce build-level specs before a binary is even accepted for review. Miss one and the upload fails at the door, no human reviewer involved.

Apple wants an .ipa built in Xcode against a recent SDK, uploaded through App Store Connect or the Transporter app.

Google requires the Android App Bundle format.

Why the Android App Bundle Replaced the APK

Google made the Android App Bundle (.aab) mandatory for new apps in August 2021. The single monolithic APK upload is gone for fresh submissions.

An .aab isn't installable on its own. Google generates optimized, device-specific APKs from the bundle at download time, which shrinks install size for users.

Anyone still weighing the two formats can dig into the difference between an APK and an AAB before packaging a release. The Android SDK tools inside Android Studio generate the bundle directly.

Target API Level and Signing Rules

Google enforces a rolling target API requirement. Apps must target a recent Android version, and the threshold climbs every year.

App signing differs by platform:

• Apple handles signing automatically through certificates and provisioning profiles

• Google uses Google Play App Signing, where Google holds and manages the signing key

• Both platforms require 64-bit support

The signing key point trips people up. With Google Play App Signing, losing your local upload key isn't fatal because Google keeps the app signing key. Lose an Apple distribution certificate at the wrong moment and your release stalls until it's regenerated.

---

What App Store Assets and Metadata Are Required?

Every submission needs a complete set of visual assets and text fields. Incomplete listings get bounced before code review, and metadata problems are one of the most preventable rejection causes on both stores.

You cannot reuse the same screenshot files across both stores. Apple's required iPhone dimensions fall outside Google Play's accepted aspect ratios, so you export two separate sets every time (CatDoes, 2026).

App Store Connect Listing Assets

App icon: 1024 × 1024 px, no transparency.

Screenshots: required per device class, sized to the current iPhone and iPad specs.

Text fields: app name (30 characters), subtitle, promotional text, full description.

Apple gives you a dedicated 100-character keyword field that never appears to users but feeds App Store search. Preview videos are optional but sit at the top of the product page.

Placeholder content is an instant rejection. Strip any "Lorem ipsum," "coming soon" banner, or "beta" label before you submit.

Google Play Store Listing Assets

Google's asset rules diverge on almost every dimension.

App icon: 512 × 512 px, 32-bit PNG with alpha.

Feature graphic: a Google-specific 1024 × 500 px banner that sits above your screenshots and is required to publish.

Asset	Apple spec	Google spec
Icon	1024 × 1024, no alpha	512 × 512, alpha OK
Search text	100-char keyword field	Pulled from description
Feature banner	None	1024 × 500 required

Unlike Apple's dedicated keyword field, Google indexes your app description text for search. That changes how you write the listing. Apple rewards tight keyword packing in a hidden field; Google rewards a natural, readable description.

A transparent PNG in the wrong slot fails on both stores. Flatten first.

---

How Does App Privacy and Data Disclosure Work?

Both stores require you to declare what data your app collects before approval. Apple did it first, Google followed, and a mismatch between your declaration and your app's actual behavior triggers rejection or post-launch removal.

Apple introduced Privacy Nutrition Labels in December 2020. Google made its Data Safety section mandatory, with a hard compliance deadline of July 20, 2022 (OneTrust).

Apple Privacy Nutrition Labels and App Tracking Transparency

Apple runs two separate privacy systems.

Privacy Nutrition Labels are answered inside App Store Connect and render on the product page, showing what data is collected, whether it's linked to the user, and whether it's used to track.

App Tracking Transparency (ATT) governs the IDFA. Any app that tracks users across other companies' apps must show the ATT prompt and get explicit permission.

Responses apply at the app level across all platforms, so declare your most comprehensive data practice, not the lightest one.

Google Play Data Safety Section

Google's Data Safety section covers similar ground with different questions.

It summarizes what data the app collects, what it shares, how data is stored, and whether collection is optional. Third-party SDK behavior counts as your behavior here.

Shared requirement: both stores demand a live privacy policy URL. Google expanded this in April 2022 so that every app needs one, not just apps handling sensitive data.

The forms are not interchangeable. You fill out Apple's version and Google's version separately, because the required data-type definitions don't match. Apps that misrepresent their disclosures face enforcement once the gap is found.

---

What Content and Age Ratings Must You Set?

Every app must complete a content rating questionnaire before it can publish. The answers generate an age rating that controls visibility, regional availability, and which audiences the store surfaces the app to.

Both stores automate the rating from your answers. Lie on the questionnaire and you risk removal.

Apple Age Rating System

Apple uses a built-in questionnaire inside App Store Connect.

Your answers map to one of several tiers: 4+, 9+, 12+, and 17+. Questions cover violence, mature themes, gambling, and unrestricted web access.

Apps with user-generated content face extra scrutiny. Apple wants content filtering, a way to report abuse, and a block function before it approves anything social.

Google IARC Rating and Declaration Forms

Google runs the IARC system, which issues region-specific ratings automatically.

One questionnaire produces ESRB ratings for the Americas, PEGI for Europe, and USK for Germany, among others. One set of answers, many regional certificates.

Google also requires standalone declarations:

• Target audience and age group

• Whether the app contains ads

• News app status

• Restricted content categories like gambling or health

Getting the target-audience declaration wrong pulls your app into Google's Families policy, which carries its own stricter rules. Answer it carefully.

---

How Long Does App Review Take on Each Platform?

Apple reviews most submissions in 24 to 48 hours, processing 90% within 48 hours at an average of about 1.5 days. Google Play ranges from a few hours to 7 days, running longer for new accounts and policy-sensitive apps.

Apple's own figures show it handled over 200,000 submissions a week across a recent 12-week stretch (Michael Tsai / Apple).

What Reviewers Actually Check

Reviewers test the live app on real hardware, not just the binary.

They look for: crashes, broken features, placeholder content, guideline violations, and whether the app does what its listing promises.

Login-gated apps need working demo credentials. Over 40% of unresolved review issues trace back to Guideline 2.1 (App Completeness), and missing test accounts are a big share of that (ExtensionBooster).

Disable 2FA on the demo account or the reviewer gets locked out. That's a guaranteed rejection cycle, and each cycle adds days.

Review Timelines Compared

Category matters. Health, finance, and kids apps draw extra scrutiny on both stores.

Platform	Typical new app	Updates	Expedited option
Apple	24–48 hrs	Often faster	Yes, for critical fixes
Google	Few hours–7 days	Usually faster	No formal equivalent

Apple offers expedited review for time-sensitive launches and critical bug fixes, though approval of the request is never guaranteed.

Submit early in the week. Real-world data shows shorter queues on Tuesday mornings and longer waits when developers dump submissions on Friday and Saturday.

Why Do Apps Get Rejected During Submission?

Apps get rejected for crashes, incomplete functionality, metadata mismatches, privacy violations, and duplicate or low-value content. Apple rejected roughly 1.93 million of 7.77 million submissions in 2024, about 1 in 4, and most reasons are preventable in minutes.

Performance issues alone caused more than 1.2 million of those rejections (Apple 2024 Transparency Report).

The good news buried in that number: about 295,000 rejected apps were approved after developers fixed the flagged issue and resubmitted.

Common App Store Rejection Reasons

Apple organizes review around five pillars: Safety, Performance, Business, Design, and Legal.

Guideline 4.3 (spam/duplicate): the single most common rejection, cited in 28% of all rejections (AlmostDone). Template apps and near-identical rebuilds get caught here.

Guideline 2.1 (App Completeness): crashes, placeholder content, or missing demo credentials for login-gated features.

Guideline 4.0 (Design): non-standard navigation and broken layouts drove 378,300 rejections in 2024 (Volpis).

A $1 gap between your listed subscription price and the in-app price triggers a Guideline 2.3 metadata rejection. One AppFollow client lost four launch days to exactly that mismatch.

Common Google Play Rejection Reasons

Google's rejections cluster around policy rather than manual design review.

Violation	What triggers it
Deceptive behavior	Functionality that differs from the listing
Permissions misuse	Requesting access the app doesn't use
Metadata policy	Keyword stuffing, misleading text
Policy 4.3 (webview)	Website wrapped in an app with no native value

Google tightened Policy 4.3 enforcement against thin webview apps through 2025 and 2026 (SaaStoStore).

An app that's a full-screen WKWebView loading your existing site gets rejected on both stores for offering nothing beyond a browser. Building real native value matters, and teams serious about mobile application development design around that from the start rather than wrapping a site.

---

How Do You Release an App After Approval?

Approval doesn't mean instant public availability. Both stores let you control when and how the app reaches users, from an immediate full launch to a slow percentage-based rollout that limits damage from a bad build.

Phased and staged rollouts apply to updates, not brand-new app launches (Departures).

Apple Release Options and TestFlight

Apple gives three release modes after approval: manual, automatic, and phased.

Phased release rolls an update to auto-update users over 7 days at fixed increments: 1%, 2%, 5%, 10%, 20%, 50%, then 100% (James Montemagno). You can pause it for up to 30 days, but you can't pick your own percentages.

Before production, TestFlight distributes beta builds to up to 10,000 external testers through a lighter Beta App Review.

The Tamreeni fitness platform used a 600-person TestFlight cohort to catch three subscription bugs before launch (Brandrums case study).

Google Play Release Tracks and Staged Rollout

Google structures pre-launch testing into four tracks, and each feeds the next.

• Internal: up to 100 testers for fast QA checks

• Closed: the track that satisfies the 12-tester production requirement

• Open: public beta before full launch

• Production: the live Play Store release

Unlike Apple's fixed schedule, Google's staged rollout lets you set the exact percentage and halt the moment a crash monitor fires. Google also supports country-level rollouts, which iOS still doesn't offer.

Managed publishing holds approved changes until you manually push them live, useful for coordinating a launch with marketing.

---

How Do App Updates and Versioning Work?

Every update needs a higher build number than the last, or the store rejects the upload outright. Updates go through review on both platforms, usually faster than a first submission, and the versioning rules differ between iOS and Android.

The store uses the build number purely as a gatekeeper. Submit 2.3.1 with a lower build than 2.3.0 and it bounces.

iOS Versioning Rules

Apple splits versioning into two fields.

CFBundleShortVersionString: the marketing version users see, formatted as three integers like 2.3.1.

CFBundleVersion: the internal build number that must increase with every upload, even within the same marketing version.

iOS rejects letters in the version string. Android tolerates 2.3.1-beta in its name field; Apple does not, so strip beta suffixes before submitting (Appypie).

Android Versioning and In-App Updates

Android uses a parallel pair with different rules.

versionName is the human-readable string. versionCode is an integer between 1 and 2,100,000,000 that must climb with every Play upload.

Best practice: keep the marketing version identical across both platforms for the same release so support teams aren't decoding two numbers (UXCam).

Google's in-app update API prompts users to update without leaving the app, either a flexible background download or an immediate blocking flow. Both platforms re-review binary changes, while metadata-only edits (new screenshots, description tweaks) clear faster.

---

What Are the Ongoing Compliance Rules After Launch?

Publishing isn't the finish line. Both stores enforce ongoing rules, and the biggest recurring one is Google's annual target API level bump, which can freeze your ability to ship updates if you fall behind.

Apple re-reviews your app on every update, so each release is a fresh compliance check against the current guidelines.

Google Target API Level Enforcement

Google raises the minimum target API level every year, and the deadline lands around August 31.

Starting August 31, 2025: new apps and updates must target Android 15 (API level 35) or higher (Google Play Console Help).

Miss it and you can't publish bug fixes or new features. The app effectively freezes at its current version.

Apps below the floor stay installed for existing users but vanish from search and recommendations for people on newer Android devices. Understanding the full app lifecycle means budgeting for this yearly maintenance update, not treating launch as the end.

Account and Agreement Obligations

Staying live means keeping the account itself in good standing.

Apple: the $99/year membership must be renewed, or your apps get pulled from sale.

Both stores: repeated policy violations escalate to account termination, not just single-app removal.

Google auto-resets sensitive permissions for apps a user hasn't opened in a few months, which affects background-only apps most.

A single terminated developer account can take every published app with it. Treat the agreement terms and annual deadlines as release-critical, because on these platforms, they are.

FAQ on App Store & Google Play Submission

How much does it cost to submit an app to both stores?

The Apple Developer Program costs $99 per year. Google Play charges a one-time $25 registration fee. Your first year on both stores runs about $124 in account fees, before build, design, or compliance costs.

How long does app review take on each platform?

Apple reviews most submissions in 24 to 48 hours, processing 90% within two days. Google Play ranges from a few hours to 7 days, running longer for new accounts and policy-sensitive categories like finance or health.

Do I still need 12 testers for 14 days on Google Play?

Yes, if your personal account was created after November 13, 2023. You must run a closed test with 12 opted-in testers for 14 continuous days before production access. Organization accounts skip this entirely.

Why do apps get rejected during submission?

Crashes, incomplete features, metadata mismatches, and privacy gaps drive most rejections. Apple's Guideline 4.3 (spam and duplicate apps) alone accounts for 28% of rejections. Missing demo credentials for login-gated apps is another frequent, preventable cause.

What file format does each store require?

Google Play requires an Android App Bundle (.aab), mandatory for new apps since August 2021. Apple requires an .ipa built in Xcode and uploaded through App Store Connect or the Transporter app. You cannot swap formats between stores.

Can I submit to both stores at the same time?

Yes. You maintain separate listings, assets, and compliance forms for each store, but you submit around the same time. Plan a buffer of at least 7 business days before announcing your public launch date.

What privacy disclosures are mandatory before approval?

Apple requires Privacy Nutrition Labels and App Tracking Transparency prompts for cross-app tracking. Google requires a completed Data Safety section. Both demand a live privacy policy URL, and both forms must match your app's actual data behavior.

How do app updates and versioning work?

Every update needs a higher build number, or the store rejects the upload. Apple uses CFBundleVersion, Android uses versionCode, both must increase per submission. Updates go through review, usually faster than a first submission.

What is the target API level requirement on Google Play?

Google raises the target API level yearly. Since August 31, 2025, new apps and updates must target Android 15 (API level 35) or higher. Fall behind and you cannot publish fixes or new features.

What are the different testing tracks on Google Play?

Google offers four tracks. Internal distributes to 100 testers for quick QA. Closed satisfies the production testing requirement. Open runs a public beta. Production is the live release. Each track promotes builds upward.