WebView App Rejected Under Guideline 2.3.10: Android Mentions Fix

Key takeaways

Guideline 2.3.10 bans names, icons and imagery of other mobile platforms or alternative app marketplaces in your app or metadata, unless there is specific, approved interactive functionality.
In a WebView app the reference usually comes from your website: store badges, Android download pages, APK links, device mockups, QR codes and share texts.
Hide or replace these elements for every app user with app detection – a custom user agent plus server-side templates or an app-only stylesheet – on every reachable page.
Clean the listing too: description, promotional text, What's New, keywords, screenshots and previews should be about the iOS app and its experience.
WebViewGold, made by our team, can set a custom user agent and inject app-only CSS, so you can remove store badges in the app without forking your website.

Our recommended solution

Rebuild your wrapper with WebViewGold – a real app, not just a website in a frame

WebViewGold turns your website into native iOS and Android apps with push notifications, a native offline screen, deep links, a QR scanner and more – the building blocks App Store reviewers look for. Built by our own team, and we submit WebViewGold apps all the time.

Get WebViewGold How it helps ↓

What the rejection typically looks like

Guideline 2.3.10 - Performance - Accurate Metadata

We noticed that your app includes references to a third-party platform. Specifically, the app's home screen and footer display a Google Play badge that links to the Android version of the app.

Next Steps

Remove references to other mobile platforms from your app and its metadata.

Paraphrased example – the exact wording in your message may differ.

What Guideline 2.3.10 says

If your WebView app was rejected under Guideline 2.3.10, App Review found a name, icon or image of another mobile platform – almost always Android or Google Play – somewhere in your app or your App Store listing. The guideline is short (App Store Review Guidelines):

Make sure your app is focused on the experience of the Apple platforms it supports, and 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. Make sure your app metadata is focused on the app itself and its experience. Don’t include irrelevant information.

It holds two rules. The first concerns other platforms and stores: no Android robot, no Google Play badge, no download buttons for other app stores or alternative marketplaces – neither inside the app nor in the listing. The second is broader: your metadata should describe the iOS app and what people do with it, not everything your company does. Both apply even if your product genuinely ships on Android. Being cross-platform is fine; advertising it inside the iOS app is not.

Why WebView apps get rejected under Guideline 2.3.10 so often

A native app's screens are written for iOS. A WebView app shows pages written for every visitor of your website – and websites love to advertise both stores. The app's code never mentions Android, yet the reviewer sees the badge because the website renders it. These are the usual places:

Element on your website	Where it usually sits	How the reviewer meets it
Store badge row with "Get it on Google Play"	Footer, hero section, a "Get the app" page	On the start screen or after one scroll
"Also available on Android" or "Download for Android"	Feature pages, FAQ, pricing, release blog posts	Through the menu, search or help links
Android phones in mockups	Hero images, product tours, testimonials	Device frames and status bars from another platform
APK files and other stores	Download pages, changelogs, beta programs	Direct links to .apk files or third-party marketplaces
QR codes for the Play Store	"Scan to download" blocks meant for desktop visitors	A Google Play code inside the app
Platform-specific help	Articles such as "Enable notifications on Android"	Help links in the app's support menu
Share and invite texts	"Invite a friend" messages with both store links	The share sheet sends the text your website provides

A sneaky variant comes from device detection. Many sites pick the badge to show based on the visitor's user agent. If your app replaces the iOS user agent with a custom string, the website may stop recognizing an iPhone and fall back to its Android or desktop variant – Google Play badge included.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

Find every reference: a crawl you can repeat before each release

Reviewers rarely list every occurrence, and they open pages you may have forgotten. Work through the app systematically:

List every page the app can reach. Start with your sitemap, then add what the navigation, footer, account area, help center and legal pages link to. Pages you send to Safari don't appear in the app, but the buttons that lead there do.
Fetch the pages as the app does. Request each URL with your app's user agent and search the HTML, for example curl -s -A "Mozilla/5.0 (iPhone) MyApp-iOS" https://example.com/ | grep -Eio "play\.google\.com|google play|android|\.apk".
Check assets, not just text. Badges hide in images named like google-play-badge.svg, in SVG sprites and in alt texts – the same search finds those names.
Walk through the app on a device. Content rendered by JavaScript, pop-ups and chat widgets only appear in a real session. Use the TestFlight build, sign in with the demo account and open every menu item.
Check what leaves the app. Share texts, invitation emails and push campaigns can carry Play Store links as well.

Put the crawl into your CI pipeline, so a new marketing block on the website doesn't undo the fix three months later.

Hide store badges in the app without breaking your website

The fix is app detection used for presentation only. Give your app a recognizable user agent and let the website render differently for it:

Append, don't replace. Keep the standard iOS user agent and add a token such as MyApp-iOS at the end. Device detection keeps working, and your site can still tell app users from Safari visitors.
Prefer server-side templates. When the server sees the token, it simply doesn't render the badge row, the "Get the app" section or Android download pages – nothing flashes while the page loads.
Add an app-only stylesheet as a safety net. A rule such as a[href*="play.google.com"], [data-store-badges] { display: none !important; } catches badges a page builder or plugin adds later.
Rewrite sentences instead of hiding them. CSS can't remove "also on Android" from the middle of a paragraph. Give app users neutral wording such as "use your account on all your devices".
Redirect dead ends. A download page makes no sense inside the app; send app users from /download to the start page.

Apply this to every app user, all the time. Hiding elements only while a build is in review is the reviewer-specific behavior that leads to Guideline 5.6 rejections. Removing store badges for all app users is a legitimate presentation choice – it is the same app for everyone. If the app shows little beyond your website once the badges are gone, read our article on Guideline 4.2 for WebView apps as well.

Clean the App Store listing – and keep it about the app

2.3.10 covers metadata as much as the app. Go through every localization in App Store Connect:

Description and promotional text: no "available for iPhone and Android", no Play Store links, no "Android version coming soon".
What's New: release notes copied from a shared changelog often mention Android fixes.
Keywords: "android" or "apk" are irrelevant for an iOS listing and waste the 100-byte field anyway.
Screenshots and previews: no Android device frames, no captures of your website's download section, no badge in the corner of a marketing image. Our 2.3.3 screenshots guide covers the specifications.

The second sentence of 2.3.10 – metadata "focused on the app itself and its experience" – is a common trap for website wrappers. Descriptions pasted from the company website talk about the agency behind the product, press logos, desktop dashboards or browser extensions. Rewrite the description around what someone does in the iOS app. Name, subtitle and keyword rules are in our Guideline 2.3 Accurate Metadata guide.

The fastest fix for most WebView rejections

WebViewGold: native features for your web app

Instead of building native features from scratch, start from WebViewGold. You get ready-made Xcode and Android Studio projects for your website, with native modules you switch on in the configuration:

Push notificationsOneSignal or Firebase, for real, personal events
Native offline screenNo browser error pages when the connection drops
Native splash screenApp-like start instead of a loading web page
Deep linksLinks open the right screen inside the app
QR & barcode scannerDevice features the website alone can't offer
In-app purchasesNative purchase flows where the store requires them

No tool guarantees an approval: Apple still judges what your app offers. Use the native features in your main user journey – our App Specialists review your WebViewGold app before it goes to the App Store.

Discover WebViewGold Let us submit your WebViewGold app

The exception: specific, approved interactive functionality

2.3.10 allows platform references "unless there is specific, approved interactive functionality". Both words matter: the mention has to be part of something the app actually does with the other platform, and App Review has to accept it. A footer badge is never interactive in that sense.

A mention can be part of a feature when an app moves data to or from Android devices, manages a mixed fleet of phones or shows which platform a connected device runs. If your app does something like that, name the other platform only where the feature needs it, explain the feature in the Notes for Review and expect App Review to decide case by case. Everywhere else, neutral wording works: "your other devices", "the web version" or "our apps".

Use WebViewGold to keep the app mode clean

If you'd rather not touch every template on your website, handle it in the native shell. WebViewGold, our team's website-to-app product, gives you an Xcode project in which the relevant pieces are configuration:

Custom user agent (useragent_iphone and useragent_ipad in Config.swift) for the app detection described above.
Custom CSS and JavaScript that WebViewGold injects into every page the app loads – the place for app-only rules that hide store badges without changing your website.
Local HTML bundling for an app-specific start or onboarding page that never shows download badges.
Native share dialog and push notifications via OneSignal, Firebase or Pushwoosh, so you control the texts that reach iOS users.

The injected stylesheet ships inside the app, so it is part of the build App Review sees and changes only with a new build – which also keeps it stable. WebViewGold is a one-time purchase and you publish in your own developer account. It can't promise an approval, so test the result on a device.

appsubmitter.io takes care of the store side: our App Specialists prepare the listing and screenshots for every locale, run AI-powered and human pre-submission checks that look for other-platform references and submit the app in your own account. Book the iOS service or start with a free consultation call.

Reply to App Review and resubmit

Where the reference lived decides the route:

Only in metadata (status Metadata Rejected): edit the fields and screenshots, reply in the same thread and resubmit without a new build.
On your website: change it for all app users, verify on a device and explain in your reply that the content is served from your site. A new build may not be necessary; if App Review asks for one, increment the build number and upload.
Inside the bundle (local HTML files, injected CSS, native strings): upload a new build.

List each place you changed and attach a screenshot of the cleaned screen. If you believe a mention is part of interactive functionality, describe that feature factually instead. Replies can be up to 4,000 characters and carry attachments (App Store Connect Help). When appsubmitter.io submits your app, we write and send this reply for you.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]) and for pointing out the Guideline 2.3.10 issue.

The [Google Play badge / Android download link] was part of our website, which the app displays. We have removed references to other mobile platforms for every user of the iOS app:

1. Store badges, QR codes, Android download pages and APK links no longer appear in the app. App users are redirected from [/download] to the start page.
2. Help articles and share texts shown in the app no longer mention other platforms.
3. App Store metadata: we removed [Android mentions] from the description, promotional text and What's New text in [locales] and replaced [number] screenshots.

[No new build was required, because this content is served from our website. / Build [build number] contains the updated app-only stylesheet.]

Screenshots of the updated [home screen and footer] are attached. If you find any remaining reference, please let us know the screen so we can fix it right away.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

Every page the app can reach was fetched with the app's user agent and searched for Google Play, Android, APK and marketplace references.
Store badges, "Get the app" sections and QR codes for other stores are hidden or removed for all app users.
App users are redirected away from download pages and Android-only help articles.
The custom user agent extends the standard iOS user agent instead of replacing it.
Sentences such as "also available on Android" have neutral wording in the app, not just a CSS rule.
Share texts, invitation emails and push campaigns for iOS users contain no Play Store links.
Description, promotional text, What's New, keywords, screenshots and previews are free of other-platform references in every locale.
The description focuses on what users can do in the iOS app, not on the company or desktop products.
The badge crawl runs automatically before every submission.

Frequently asked questions

Why was my WebView app rejected under Guideline 2.3.10 when my code never mentions Android?

Because App Review judges what the app shows, not where it comes from. Your website runs inside the app, so a Google Play badge in its footer is a reference to another platform in your app. Detect the app with a custom user agent and remove such elements for all app users, not only for the reviewer.

Can I say that my app is also available on Android in the App Store description?

No. Guideline 2.3.10 covers metadata as well as the app, and an "also on Android" line is exactly the kind of other-platform mention it rules out. Use neutral wording such as "use your account on all your devices" or point to your web version instead.

Is the "Download on the App Store" badge inside my iOS app a problem?

It isn't another platform, so 2.3.10 doesn't target it. Inside an installed app it is pointless, though, and it usually sits in the same row as the Google Play badge. Hide the whole badge section in app mode – that is simpler to maintain and looks more like an app.

Do I need a new build to fix a 2.3.10 rejection?

It depends on where the reference lives. Metadata is fixed in App Store Connect without a build. Website content changes on your server, which you explain in your reply. References in local HTML files, injected CSS or native strings are part of the binary, so they need a new build.

Does Guideline 2.3.10 also cover alternative app marketplaces?

Yes. The guideline names alternative app marketplaces right next to other mobile platforms. If your website promotes a marketplace version of your app – for example to visitors in the EU – treat those badges and links like Google Play badges and hide them in the App Store version.

How does WebViewGold help with Guideline 2.3.10?

WebViewGold, made by our team, lets you set a custom user agent for app detection and inject custom CSS into every page the app loads, so you can hide store badges in the app without forking your website. It can also bundle local HTML for an app-only start page. No tool can promise an approval, but app mode becomes easy to maintain.

Sources and further reading

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.

WebView App Rejected Under Guideline 2.3.10: How to Remove Google Play Badges and Android References