App Store vs Google Play: Side-by-Side Listing Requirements (2026)

Shipping to both stores means writing two listings, passing two review processes, and satisfying two overlapping-but-not-identical rule sets. Most published guides cover only one side, and most of the side-by-side ones predate the enforcement changes of 2024 and 2025. This post puts the App Store and Google Play listing requirements next to each other in full, current through April 2026, with every field, asset, privacy declaration, binary rule, and review step mapped across both stores.

The core insight: Apple rewards precision — a 30-character subtitle, a 100-character hidden keywords field, a Privacy Label that maps to its own data taxonomy. Google rewards breadth and retention — it indexes your full description for search, reads an 80-character short description as the conversion hook, and weights D1 and D7 retention heavily in its ranking. Neither model is better or worse. They are different rubrics for the same submission.

Pair this post with our ASO playbook for indie developers for tactics across both stores, or jump straight to the quick-reference table below if you want the one-screen answer.

Quick-reference table

Every headline requirement mapped across both stores. Current through April 2026.

Metadata — field-by-field

Each store has roughly six meaningful metadata fields. Most of the confusion comes from assuming Apple fields have Google equivalents when they do not.

Title (both: 30 characters)

The same 30-character budget on both stores. Google Play reduced its title from 50 characters to 30 in 2021 to align with Apple, which simplified cross-store branding. Use the same brand-plus-descriptor formula on both: Bear — Markdown Notes. Apple and Google both rank on the title, and both enforce the same no-trademark / no-competitor-name rules.

Subtitle (iOS, 30 chars) vs Short description (Google, 80 chars)

Different fields with different jobs. Apple’s subtitle is a tight 30-character pitch that sits under the app name on the product page and is heavily weighted for search ranking. Google’s short description is an 80-character field that shows above the fold on every Play Store device and is the single biggest conversion lever on Google. The subtitle helper ships proven patterns for both fields.

Full description (both: 4,000 chars, different use)

The critical asymmetry. Apple does not index the full description for search ranking; it reads the title, subtitle, keywords field, IAP names, and developer name. Google does index the full description — the whole 4,000 characters contribute to what Play ranks you for. This means you can write one description and ship it to both stores, but the optimal description for Google will be denser with keywords than the optimal description for Apple. See the full Apple App Store keywords field deep-dive for Apple’s actual indexing map.

Keywords field (iOS only, 100 chars)

A hidden-from-users comma-separated string Apple uses for search matching. Google Play has no equivalent. Use Push My App’s free keyword character counter to validate the 100-character cap and flag words that duplicate your title or subtitle.

Promotional text (iOS only, 170 chars)

A 170-character field on the App Store that is updateable without a new binary submission — the only App Store field with that property. Google Play has no equivalent. Use it for evergreen positioning; Apple rejects promotional text that runs time-bound promotions under guideline 2.3.1.

What’s New vs Release notes

Apple gives you 4,000 characters per release for What’s New copy; Google Play gives you 500 characters for Release notes. Write a short punchy summary in 500 characters that works for Google, then optionally expand for Apple. Neither field is indexed for ranking on either store — these fields affect whether existing users tap Update.

Visual assets — what each store requires

The asset requirements diverge more than the metadata. Plan for two separate sets of exports.

Icon

Apple:1024×1024 PNG, no alpha channel, no transparency. As of iOS 26 (launched 2025), Apple added Liquid Glass icon variants — optional but increasingly expected.

Google Play:512×512 PNG, 32-bit with alpha allowed. Google Play displays the icon rounded on every device and recommends designing within a safe zone to avoid clipping at the corners.

Push My App’s app icon resizer generates every required size from a single 1024×1024 master for both stores.

Feature graphic (Google only)

A 1024×500 PNG or JPG that Google Play displays above the short description on every Play listing. Required for every app. Apple has no equivalent. Avoid device mocks and call-to-action overlays — Google rejects both under its Metadata policy.

Screenshots

Apple:one 6.9-inch iPhone size is required for new submissions as of 2026 (2056×2868 or 1320×2868 depending on orientation); all other iPhone sizes are auto-scaled from this one. iPad Pro 13-inch (2064×2752) is required if the app supports iPad. Minimum 2 screenshots per device class, maximum 10.

Google Play: 2–8 phone screenshots required with long-edge dimensions between 320 and 3840 pixels and aspect between 1:1 and 2:1. 7-inch and 10-inch tablet screenshots are optional but recommended for tablet-targeted apps.

The full 2026 dimension reference is the screenshot size guide, which updates whenever Apple or Google changes requirements.

Preview video

Apple: App Preview, up to 3 per device class, 15 to 30 seconds each, H.264 or HEVC at 1080p or 4K. Auto-plays muted on the product page.

Google Play: one promotional video per listing, hosted on YouTube, 30 seconds to 2 minutes. Displays as a thumbnail users tap to watch.

Privacy declarations — both required, each different

Both stores now require a privacy declaration before submission. The two forms use different taxonomies, so you cannot copy answers from one into the other — but the underlying audit of your code is the same.

Apple — App Privacy label + Privacy Manifest

Completed in App Store Connect under App Privacy → Data Types. Apple’s taxonomy covers categories like Contact Info, Location, Health & Fitness, Financial Info, each with sub-items. The label is shown to users on the product page under App Privacy.

Since May 2024, Apple also requires a PrivacyInfo.xcprivacy file inside the binary for any app that uses a required-reason API. Every third-party SDK you bundle must also ship its own manifest. A missing or mismatched manifest is a binary-level submission rejection — see the App Store rejection reasons index under guideline 5.1.1.

Google — Data safety form

Completed in Play Console under App content → Data safety. Google’s taxonomy is more granular about third-party SDKs and asks more specifically how the data is used (app functionality, analytics, personalization, developer communications, fraud prevention). The form is shown to users on the Play product page under Data safety.

A Data safety form that does not match what your code actually collects is the single most common Google Play submission rejection. Audit every network request — including every SDK — before filling out the form.

Binary format and signing

Two formats, two signing models. Both are detailed in the IPA vs APK vs AAB deep-dive; here is the summary.

Apple — IPA + Distribution certificate

Ship an .ipa built from Xcode Archive. Signed with a Distribution Certificate tied to your Apple Developer Program account plus a matching Provisioning Profile. Xcode automatic signing handles the cert-to-profile matching for most teams. As of 2026, new apps must build with the iOS 18 SDK or later and include a Privacy Manifest for required-reason API usage.

Google — AAB + Play App Signing

Ship an .aab (Android App Bundle) built from Gradle bundleRelease. Required for new apps on Play since August 2021. The upload key is the keystore you generate and hold; you sign every AAB with it. The app signing key is what the final device-installed app is signed with. With Play App Signing (the default since 2020), Google holds the app signing key, letting you rotate the upload key if it is compromised.

2026 Android-specific rules

• Target API 35. New apps must target Android 15 as of August 2025.
• 16 KB page-size support. Apps targeting Android 15+ must support 16 KB memory pages in their native libraries as of November 2025.
• Play Protect and Play App Signing enrollment. Default for new apps; the few pre-2020 apps that opted out should plan to enroll before any key-rotation need arises.

Review process

Two different review philosophies.

Apple App Store review

Automated static analysis pass, then a human reviewer picks up the build from a global queue. First-submission median hovers around 24 hours; updates are often faster; peak launch windows (late November through mid-December) stretch to 2–3 days. Rejections arrive in App Store Connect’s Resolution Center with a cited guideline number and usually a screenshot or log line. Every letter on a given app thread is preserved in the Resolution Center.

Google Play review

Automated pre-launch report (device testing, crashes, ANRs, policy issues), static policy scan, then a human policy review where flagged. New apps often clear in 3 to 7 days; updates to established apps usually clear in under 24 hours. Unlike Apple, Google continues to scan apps post-launch — a policy violation surfaced after the app is live triggers an email with a 7-day appeal window.

Pricing and account costs

Apple Developer Program: $99 per year, renewed annually, required to submit to the App Store. Includes TestFlight, App Store Connect access, and all certificates. Lapsed memberships pull your apps off the store.

Google Play Developer: $25 one-time registration fee, payable once at account creation. No annual renewal. Play Console access and developer-verification requirements (rolled out progressively from 2024 through 2025) are included.

For a solo indie, that is a $99 annual line item on iOS versus a single $25 cost on Android over a multi-year window. Both stores now require identity verification — Apple via D-U-N-S for organizations, Google via a rolling identity-verification programme for all developer accounts.

One dashboard or two

The traditional workflow is two completely separate pipelines: Xcode Organizer or Transporter for iOS; Play Console manual upload (or fastlane supply, or gradle-play-publisher) for Android. Push My App’s direct submission to both the App Store and Google Play sends signed binaries and metadata to both stores from one dashboard after the Pre-Flight Scanner has verified the binary. That removes the context-switch between two different credential models and two different upload tools.

Frequently asked questions