App Store Screenshots: Why Android References Get Rejected

Apple rejects App Store screenshots that point at other mobile platforms. Android device frames, "Get it on Google Play" badges, "Back to TestFlight" buttons, and "also on Android" overlay text all trip Guideline 2.3.10, which says your metadata has to stay focused on the Apple platforms your app supports [1]. This guide maps each banned element to the rule and shows what to use instead.

TL;DR:

• Guideline 2.3.10 bans names, icons, and imagery of other mobile platforms or alternative app marketplaces in your metadata, and screenshots are metadata [1].
• The usual offenders: Android device frames, Google Play badges, leftover "Back to TestFlight" buttons, rival store logos, and "also available on Android or Web" text.
• It applies even when your app genuinely ships on Android too. The iOS listing still has to read as Apple-only.
• The fix is a metadata change, not a new build: swap the frames, drop the badges, resubmit the same binary.

Table of contents

• What does Guideline 2.3.10 say about screenshots?
• Which screenshot elements count as other-platform references?
• Why does Apple reject other-platform references?
• Does the rule apply to genuinely cross-platform apps?
• How do you fix screenshots flagged under 2.3.10?
• Pre-submission checklist for other-platform references

What does Guideline 2.3.10 say about screenshots?

Guideline 2.3.10 reads, verbatim: "don't include names, icons, or imagery of other mobile platforms or alternative app marketplaces in your app or metadata, unless there is specific, approved interactive functionality" [1]. Screenshots are metadata, so any frame that names or pictures Android, Google Play, or another store falls squarely under it.

The rule sits inside Section 2.3, Accurate Metadata, which opens by saying customers "should know what they're getting" and that your "screenshots, and previews accurately reflect the app's core experience" [1]. So 2.3.10 is really two ideas stacked: keep the listing focused on the Apple experience, and keep it honest about what an iOS user receives. A Google Play badge fails both at once. The only escape hatch in the text is "specific, approved interactive functionality," which is a narrow carve-out for apps that legitimately interoperate with another platform, not a license to show a competitor's logo for marketing.

This is the guideline most rejection write-ups fold into a vague "accurate metadata" warning. Naming it lets you audit for the exact thing reviewers look for. The screenshot best practices guide treats 2.3.10 as one item on a per-frame compliance pass, alongside the "show the app in use" rule.

Which screenshot elements count as other-platform references?

Anything that names or pictures a non-Apple platform or store. The recurring offenders are Android device frames wrapped around your UI, "Get it on Google Play" or "Download for Android" badges, "Back to TestFlight" buttons captured by accident, rival app-store logos, and overlay copy like "also on Android, Web, and Windows."

Here is how each maps to the rule and what to do instead:

The "Back to TestFlight" case is the sneaky one. It usually comes from screenshotting a beta build through TestFlight and never reshooting from the release build. Reviewers have flagged sets for it, and it reads as a frame that was never meant to ship. Recapture from the production app so no beta banners or buttons survive.

Why does Apple reject other-platform references?

Two reasons, both written into the guidelines. The listing is supposed to stay focused on "the experience of the Apple platforms it supports" (2.3.10), and the metadata has to "accurately reflect the app's core experience" for an iOS user (2.3) [1]. A Google Play badge or Android frame markets a different build on a different store, which is off-focus and a cross-promotion the App Store does not host.

There is a product logic underneath the rule too. A shopper on the App Store is deciding whether to download your iOS app. An Android frame or a "works on Android" line answers a question they did not ask and quietly signals that the iOS version might be the afterthought. Apple wants the page to sell the Apple experience cleanly, which is also what converts. If you have already been flagged for this or anything else in the set, the screenshot compliance and rejection guide walks the common causes in order.

Does the rule apply to genuinely cross-platform apps?

Yes. Building for both stores is normal, but each listing stands on its own, and the iOS one has to read as Apple-only. Your screenshots can show the app working across iPhone and iPad, and your copy can say it syncs across your devices, but they cannot name Android, picture an Android device, or link to Google Play.

The line is between describing capability and referencing a competitor. "Syncs across all your devices" is fine because it describes what your app does inside the Apple ecosystem. "Also on Android and Windows" is not, because it names other platforms in metadata, which 2.3.10 prohibits outright [1]. Practical version: keep iPhone and iPad frames in the iOS set, keep Android frames in the Play set, and let each store's listing speak only to its own users. If you are shipping to both at once, the Play Store and App Store differences guide covers where the two listings diverge so you do not copy assets across by mistake.

How do you fix screenshots flagged under 2.3.10?

Replace the offending element and re-upload. Swap Android frames for iPhone or iPad frames, delete store badges and any "Back to TestFlight" buttons, and rewrite "also on Android" into an Apple-ecosystem benefit. Screenshots are listing metadata: you upload one to ten of them per localization in App Store Connect [2], so correcting a frame is a metadata change, not a new build.

That distinction matters for speed. A 2.3.10 screenshot rejection is a metadata rejection, which means you fix the images and resubmit the same binary rather than cutting a new release. The rejection recovery and resubmit guide covers the exact resubmit path, including replying in Resolution Center when you need to. The only time you genuinely need a new build is when the flagged content was baked into the app itself, not just the marketing frames.

Pre-submission checklist for other-platform references

Before you upload, walk every frame for non-Apple signals. One pass through this list catches the entire 2.3.10 class:

• No non-Apple device frames. Use iPhone and iPad frames only, never Android or generic web-browser mockups.
• No store badges. Remove "Get it on Google Play", "Download for Android", and any alternative-marketplace badge.
• No leftover beta chrome. Recapture so there is no "Back to TestFlight" button, TestFlight banner, or debug overlay.
• No rival logos or marketplace names in captions, backgrounds, or device wallpapers.
• No "also on [platform]" cross-promo text. Reframe it as a benefit inside the Apple ecosystem.
• Frames match the device class you are uploading for, so an iPad frame is not sitting in the iPhone set.

Other-platform references are an easy rejection to avoid once you read screenshots the way a reviewer does: as metadata, not decoration. Keep every frame inside the Apple ecosystem, use Apple device frames, and save the Android assets for your Play Store listing. The best practices guide covers the rest of the per-frame review rules, and the 60/40 rule explainer covers the "show the app in use" requirement that sits right next to this one. When you build a fresh set, the screenshot builder keeps Apple device frames in front of you as you iterate, so an Android frame never sneaks into the set in the first place.