Guideline 2.3.10: mentions of other platforms

A Guideline 2.3.10 rejection means your app or its metadata names another mobile platform. Usually it is one word, usually "Android", and usually in a screenshot caption or the last line of the description where you were being helpful.

Delete the reference and resubmit. This is the cheapest rejection in the guidelines to fix, and one of the easiest to trip over twice.

How it is usually worded

The header arrives as Guideline 2.3.10 - Performance - Accurate Metadata, and the body is normally close to:

"Your app or its metadata includes references to other mobile platforms, which is not appropriate for the App Store."
"We noticed that your app's description includes references to Android."

The message often quotes the offending string, or attaches the screenshot it was found in. Read the attachment before you start editing; the reviewer has already told you where to look.

What it actually means

Apple's position is that an App Store product page is about the Apple version of your app. Naming a rival platform, showing its logo, or framing your app as the port of something else all fall outside that.

The guideline asks you to keep the app focused on the Apple platform it ships for, and not to include names, icons or imagery of other mobile platforms in the app or its metadata unless there is specific, approved interactive functionality.

The last clause matters. A cross-platform app that genuinely interoperates, a remote control for an Android TV device for example, or a file transfer tool whose whole job is talking to an Android handset, has a real case. The case has to be functional, not promotional.

Why it triggers

The description's closing line. "Also available on Android" or "Now on Google Play" sits at the bottom of a lot of descriptions and gets caught eventually.
Screenshot captions and device frames. A Pixel bezel around a screenshot, a "Works on Android too" caption, a platform badge strip in a feature graphic.
Availability claims. "Sync with the Android app", "your data follows you from Android", "Windows, Mac, Android and iPhone" in a feature list.
Support and onboarding copy inside the app. A migration screen headed "Coming from Android?", an FAQ entry, a help article rendered in an in-app web view.
Google Play branding. The Play badge in a footer, "Get it on Google Play" in a settings screen, a Play Store deep link.
Pricing comparisons. "Cheaper than the Play Store version", or a paywall explaining that the Android subscription is billed differently. Pricing claims about another store attract attention faster than a bare platform name.
Keywords. The keyword field is metadata. "android" in there is a straightforward hit, and it was never going to help you rank on the App Store anyway.

How to fix it, in order

Search the metadata first. Description, promotional text, keywords, What's New, subtitle, screenshot captions, app preview video. Check every localisation, not just English; translated descriptions often keep an older closing line.
Grep the app. Search your source and your localisation files for android, google play, play store, pixel, samsung, windows phone. Include strings files, JSON copy decks and any Markdown you render in-app.
Check images, not just text. Screenshots, app previews, in-app illustrations, onboarding art, empty-state graphics. Platform logos hide in comparison tables and in "available everywhere" hero images.
Rewrite rather than delete where the meaning matters. "Sync with the Android app" becomes "Sync across all your devices". "Coming from Android?" becomes "Importing from another device". You keep the feature and lose the reference.
Handle remote content. If an in-app web view can show a Play badge, either strip it for the iOS user agent or stop rendering that page in the app.
Leave the functional case alone, and explain it. If your app exists to talk to Android hardware, do not gut the feature. Keep it and make the argument in Review Notes.
Fix the source of the copy. If your description comes from one shared marketing string, the mention returns on the next release. Split it at the source.

What to send back

If you removed the references, keep the reply short and specific.

Thank you for the review. We have removed all references to other mobile platforms. The description no longer includes the "also available on Android" line, the same line has been removed from all eight localisations, the keyword field no longer contains "android", and the comparison graphic in screenshot 4 has been replaced with one that shows only Apple devices. The onboarding screen previously headed "Coming from Android?" now reads "Import from another device".

If the reference is functional and you believe it qualifies, argue that once, plainly:

Thank you for the review. The reference to Android in our description describes interoperability rather than availability: the app's core purpose is transferring files from an Android handset to iPhone over the local network, and the platform name identifies the device the user is connecting to. We have removed every promotional reference to the other platform, including the Google Play badge in our help screen, and retained only the wording needed to describe what the app connects to. We are happy to reword further if you would prefer specific phrasing.

Do not escalate this one twice. If the reviewer holds the line, reword to a generic phrase and ship. The feature survives either way, and a week of argument over the word "Android" is a week not spent shipping.

What this is not

Naming a desktop or web version of your own product is not what 2.3.10 targets, though a reviewer may still flag a promotional link. Keep the reference descriptive.
Screenshots that do not match your app is 2.3.3. Description text that overstates what the app does is 2.3.1 or 2.3.7 depending on what was claimed.

The practical habit that prevents a repeat: treat platform names as a lint rule. AppSubmit runs the metadata through a banned-phrase check before a submission goes out, which is exactly the grep described above, only it happens every time rather than when you remember.

Source: Apple, App Store Review Guidelines, 2.3.10 (https://developer.apple.com/app-store/review/guidelines/#accurate-metadata)

Related: apple-guideline-2-3-1-hidden-features, apple-guideline-4-0-design