Store-Badges im Web-Footer
Deine Landingpage zeigt "Laden im App Store" neben "Jetzt bei Google Play". Die iOS-App lädt denselben Footer, also sieht der Reviewer ein Google-Play-Badge in einer iPhone-App.
Was Guideline 2.3.10 sagt
Guideline 2.3.10 verlangt, dass eine App sich auf die Apple-Plattformen konzentriert, die sie unterstützt. Weder die App noch ihre Metadaten sollen Namen, Icons oder Bilder anderer Mobilplattformen oder alternativer App-Marktplätze zeigen, es sei denn, die App hat eine bestimmte interaktive Funktion, die Apple genehmigt hat. Dieselbe Regel verlangt, dass sich die Metadaten um die App selbst drehen und irrelevante Informationen weglassen.
In der Praxis haben "Android", "Google Play", "Play Store", APK-Download-Links, Android-Roboter, Pixel- oder Galaxy-Gerätrahmen und Android-Systemleisten nichts in dem verloren, was App-Store-Kunden sehen, weder in der App noch auf ihrer Produktseite. Das Web ist keine Mobilplattform, ein Desktop-Computer auch nicht; ein dezentes "funktioniert auch im Browser" ist deshalb in der Regel in Ordnung. 2.3.10 ist eine Unterregel des größeren Metadaten-Abschnitts; der Guide zu Guideline 2.3 behandelt die übrigen.
Was in der Ablehnungsnachricht meist steht
Die Nachricht erscheint normalerweise unter Performance, Accurate Metadata. Sie erklärt, dass die App oder ihre Metadaten Informationen über eine Drittplattform enthalten, die für App-Store-Nutzer nicht relevant sind. Reviewer nennen meist die Stelle (einen bestimmten Screenshot, die Beschreibung, den Werbetext oder einen Screen in der App) und hängen oft einen Screenshot dessen an, was sie gesehen haben. Sie bitten dich, die Verweise zu entfernen und neu einzureichen.
Achte auf ein Detail: Liegt das Problem in den Metadaten, die du in App Store Connect korrigierst, oder in der App, was du auf deinem Webserver behebst? Viele 2.3.10-Ablehnungen nennen beides.
Wo sich Android-Erwähnungen in Vibe-Coding-Apps verstecken
Screenshots vom falschen Gerät
Aufgenommen auf einem Android-Handy, in den Chrome DevTools mit Pixel-Profil oder in einem Mockup-Tool mit Galaxy-Rahmen. Die Android-Statusleiste, die Navigationsleiste oder die Punch-Hole-Kamera verraten es.
Store-Texte, die zuerst für Google Play entstanden sind
Beschreibung, Werbetext oder "What's New" sagen noch "Android", "Play Store" oder "APK". Ein Keyword-Feld mit "android" ist ein Klassiker.
Hilfe- und FAQ-Seiten
KI-Builder erzeugen gern eine Seite "So installierst du die App" mit Android-Schritten oder eine "Zum Startbildschirm hinzufügen"-Anleitung für Chrome. Jede Seite, die der Reviewer erreichen kann, zählt.
Installationshinweise und Banner
Ein PWA-Installationsbanner, ein Smart Banner "Hol dir die Android-App" oder eine "In der App öffnen"-Leiste aus einem Marketing-Tool taucht in der iOS-App selbst auf.
Onboarding- und Support-Texte
"Funktioniert auf iPhone und Android" im Onboarding-Karussell, in leeren Zuständen oder in den vorgefertigten Antworten eines In-App-Chat-Widgets.
Ich bin sehr glücklich, dass ich diese App gekauft habe! Extrem einfach und großartige Dokumentation. Ich stand in Kontakt mit dem Kundenservice, sie antworteten sehr schnell und sehr freundlich. Sie lösten meine Frage innerhalb eines Tages. 10/10 würde ich empfehlen.
Finde jede Erwähnung in deinem Code
Die meisten Erwähnungen stecken in Code, den ein KI-Tool erzeugt hat, also durchsuche das Projekt, statt dich durch die Seiten zu klicken. Rechne mit ein paar Fehltreffern wie "pixel" in CSS. Texte aus deiner Datenbank oder deinem CMS (Blogartikel, Hilfeartikel) tauchen hier nicht auf; durchsuche sie separat.
bash
# Im Root-Verzeichnis deiner Web-App ausführen (Lovable- oder Bolt-Export, Cursor- oder Claude-Code-Projekt)
grep -rniE "android|google ?play|play\.google\.com|play store|\.apk|galaxy|pixel|samsung" \
--include=*.{ts,tsx,js,jsx,html,md,json,vue,svelte} \
--exclude-dir={node_modules,dist,build,.next} .Behebe es, ohne etwas von deiner Website zu entfernen
Web-Besucher sehen das Google-Play-Badge weiterhin; nur die iOS-App blendet es aus.
Gib der iOS-App einen erkennbaren User Agent
Setze in Config.swift
useragent_iphone(unduseragent_ipad, wenn die App auf dem iPad läuft) auf den Standard-User-Agent von iOS plus eine Markierung wieMyAppiOS. Deine Web-App erkennt dann, dass sie in der iOS-App läuft, und kann dort plattformneutrale Inhalte rendern. Das Android-Projekt hat dieselbe Option (USER_AGENTin Config.java), falls auch die Android-App ihr App-Store-Badge weglassen soll.Blende Badges und Android-Texte in der App aus
Packe Footer-Badges, "Hol dir die Android-App"-Banner und plattformspezifische Hilfeabschnitte in eine Abfrage auf die Markierung (Code unten). Für eine schnelle Lösung ohne Änderung an der Web-App ergänzt du eine Regel in
custom.cssim WebViewGold-Projekt; sie wird auf jede Seite angewendet, die die App lädt (Doku zu Custom CSS und JavaScript). custom.css steckt in der Binary, dieser Weg braucht also einen neuen Build.Formuliere Plattform-Sätze um, statt sie zu löschen
Aus "Verfügbar für iPhone und Android" wird "Verfügbar für iPhone und iPad". Aus "Installation auf Android: Tippe auf das Menü..." wird eine Hilfeseite nur zur iOS-App. "Synchronisiert auf all deinen Geräten" funktioniert überall und nennt keine Plattform.
Nimm die Screenshots unter iOS neu auf
Installiere den TestFlight-Build auf einem iPhone (und einem iPad, falls unterstützt) oder nutze den iOS-Simulator in den geforderten Displaygrößen. Die Statusleiste muss die iOS-Uhr und die iOS-Symbole zeigen: keine Android-Navigationsleiste, kein Pixel- oder Galaxy-Rahmen. Der Guide zu Screenshots und Store-Eintrag enthält die Größen und einen Ablauf für die Aufnahme.
Bereinige jedes Metadatenfeld
Beschreibung, Untertitel, Werbetext, Keywords, "What's New", das App-Vorschauvideo und die Beschreibungen der In-App-Käufe. Entferne "android" und "google play" aus dem Keyword-Feld; sie bringen in der App-Store-Suche nichts und verstoßen außerdem gegen Guideline 2.3.7. Der ASO-Guide hilft dir, den Platz für Keywords zu nutzen, die Installationen bringen.
Prüfe in der installierten App, dann antworte
Öffne den TestFlight-Build und besuche jede Seite in Footer und Menü, eingeloggt und ausgeloggt. Änderungen an der Web-App sind live, sobald du deployst; war die Binary in Ordnung, antworte also im Resolution Center ohne neuen Upload. Hast du Config.swift oder custom.css geändert, lade vorher einen neuen Build mit höherer Build-Nummer hoch.
Eine Abfrage, zwei Ausgaben
Erkenne die App einmal und nutze das Flag überall. Das CSS im Kommentar ist der Fallback für custom.css, wenn du die Web-App nicht ändern kannst.
javascript
// Config.swift: useragent_iphone = "<Standard-User-Agent von iOS> MyAppiOS"
var isIosApp = navigator.userAgent.indexOf("MyAppiOS") !== -1;
// React-Beispiel: in der iOS-App gar keine Store-Badges
function StoreBadges() {
if (isIosApp) return null;
return (
<div className="store-badges">
<a href="https://apps.apple.com/app/id0000000000">App Store</a>
<a href="https://play.google.com/store/apps/details?id=com.example.app">Google Play</a>
</div>
);
}
/* Fallback in custom.css des WebViewGold-Projekts (gilt für jede Seite, die die App lädt):
.store-badges, a[href*="play.google.com"], .android-only { display: none !important; }
*/Was in Ordnung ist und was beanstandet wird
| In deiner App oder deinem Eintrag | Urteil | Besserer Ansatz |
|---|---|---|
| "Jetzt bei Google Play"-Badge | Beanstandet | In der iOS-App ausblenden, auf der Website behalten |
| "Auch für Android verfügbar" | Beanstandet | "Auch für iPad verfügbar" oder weglassen |
| Screenshot mit Android-Status- oder Navigationsleiste | Beanstandet | Aus dem iOS-Build aufnehmen |
| Keyword "android" oder "play store" | Beanstandet (2.3.10 und 2.3.7) | Ein Keyword, das beschreibt, was die App tut |
| "Nutze es am Computer unter yourdomain.com" | In der Regel in Ordnung | Rein informativ halten, ohne Hinweis auf günstigere Preise im Web (3.1.1) |
| "Sign in with Google"-Button | In Ordnung: ein Login-Dienst, keine Plattform | Biete daneben Sign in with Apple an (Guideline 4.8) |
| "Spiel mit Freunden auf jedem Handy" | In der Regel in Ordnung | Die Funktion beschreiben, ohne die Plattform zu nennen |
Antwortvorlage für das Resolution Center
Liste auf, was du wo entfernt hast, damit der Reviewer jeden Punkt in einer Minute prüfen kann. Die Vorlage bleibt auf Englisch, weil App Review Englisch liest.
Antwort im Resolution Center (ersetze die Teile in eckigen Klammern)
Hello App Review team, Thank you for reviewing [App name], version [1.0] ([build number]). We have removed all references to other mobile platforms, as requested under Guideline 2.3.10: 1. Screenshots: all screenshots were replaced with captures from the iOS build on [iPhone display size] [and iPad display size]. They show the iOS status bar and no other device frames. 2. Metadata: the description, promotional text, keywords and What's New text no longer mention Android or Google Play. 3. Inside the app: the Google Play badge in the footer, the "Get the Android app" banner and the Android section of the help page are no longer shown in the iOS app. This content is served by our web server, so the change is already live in the build under review. [Or: build [number] contains this change.] To verify, please scroll to the footer on [Home] and open [Menu > Help]. If anything else should be changed, please let us know and we will fix it right away. Best regards, [Name] [Company], [email]
Checkliste vor der erneuten Einreichung
- Die Suche lief über den Code und über Inhalte aus Datenbank oder CMS; jeder Treffer ist in der App ausgeblendet oder umformuliert.
- Footer, Menü, Hilfecenter, Onboarding und leere Zustände im TestFlight-Build geprüft, eingeloggt und ausgeloggt.
- Kein Android, Google Play, Play Store oder APK in Beschreibung, Untertitel, Werbetext, Keywords und "What's New".
- Screenshots und App-Vorschau aus dem iOS-Build aufgenommen, ohne Android-Systemleisten oder Gerätrahmen.
- Das App-Icon enthält keine Plattform-Symbolik.
- Widgets von Drittanbietern (Chat, Cookie-Banner, Smart App Banner) zeigen in der App keinen Google-Play-Hinweis.
- Die Antwort im Resolution Center nennt jede Änderung und wo sie zu sehen ist.
Häufig gestellte Fragen
Darf ich erwähnen, dass meine App auch im Webbrowser funktioniert?
In der Regel ja. Web und Desktop-Computer sind keine Mobilplattformen, und ein kurzer Hinweis wie "Deine Daten werden mit der Webversion synchronisiert" ist üblich. Halte ihn rein informativ und nutze ihn nie, um Käufe auf die Website zu lenken; das fällt unter Guideline 3.1.1.
Ist ein "Sign in with Google"-Button ein 2.3.10-Problem?
Nein. Google Sign-In ist ein Login-Dienst, keine Mobilplattform. Er bringt allerdings Guideline 4.8 ins Spiel, die daneben eine gleichwertige, datenschutzfreundliche Option wie Sign in with Apple verlangt.
Meine Screenshots stammen von einem Android-Handy, aber die App sieht identisch aus. Ist das wirklich ein Problem?
Ja, wenn irgendein Android-Element sichtbar ist: Symbole in der Statusleiste, die Navigationsleiste oder der Gerätrahmen. Reviewer vergleichen Screenshots mit der installierten App, und Android-System-UI ist ein sofortiger 2.3.10-Befund. Nimm die Screenshots stattdessen aus dem iOS-Build auf.
Brauche ich nach einer 2.3.10-Ablehnung einen neuen Build?
Nur wenn die Korrektur in der Binary steckt, etwa ein geänderter User Agent in Config.swift oder eine neue custom.css. Metadaten bearbeitest du in App Store Connect, und Änderungen an deiner Web-App sind live, sobald du deployst; in diesen Fällen reicht eine Antwort im Resolution Center.
Was hat es mit der Ausnahme für genehmigte interaktive Funktionen auf sich?
Sie ist eng gefasst. Sie ist für Apps gedacht, die eine echte Funktion haben, die mit einer anderen Plattform zusammenarbeitet, und App Review entscheidet im Einzelfall. Dass die App auch für Android verfügbar ist, reicht nicht. Wenn du glaubst, dass deine App so eine Funktion hat, beschreibe sie in den Review-Notizen.
Drei Wege, deine App in die Stores zu bringen
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
Selbst machen
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehenCloud Builder
$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobierenFull Service
$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.