So bereitest du dein Listing für App Store und Google Play vor

Ein Listing in App Store und Google Play braucht dasselbe Kernmaterial: ein Icon, Screenshots in den Größen, die der jeweilige Store akzeptiert, einen Namen und Beschreibungen innerhalb strenger Zeichenlimits, eine URL zur Datenschutzerklärung, eine Datenschutz-Offenlegung (Apples App Privacy Labels und Googles Datensicherheit-Formular) sowie einen Fragebogen zur Altersfreigabe. Fehlt eines davon, ist die Einreichung blockiert – bereite alles also vor, solange deine App noch in Entwicklung ist.

Hier findest du die aktuellen Anforderungen für beide Stores, worauf Reviewer achten und eine Checkliste, die du an einem Nachmittag abarbeiten kannst.

Alles Wichtige auf einen Blick

App-Icon

Apple. Das App-Store-Icon ist ein 1024 x 1024 PNG, quadratisch, ohne Transparenz und ohne abgerundete Ecken (iOS maskiert es). In Capacitor-Apps befindet es sich in ios/App/App/Assets.xcassets/AppIcon.appiconset. Xcode 26 unterstützt auch gestapelte Icons, erstellt mit Icon Composer für den Liquid-Glass-Look auf iOS 26, aber ein einzelnes 1024-Bild wird weiterhin akzeptiert.

Google. Play benötigt einen separaten 512 x 512 32-Bit-PNG-Upload, maximal 1 MB. Google wendet die abgerundete Maske und den Schatten selbst an, daher ein vollflächiges Quadrat hochladen. Das In-App-Startsymbol ist separat und sollte ein adaptives Icon sein.

Alle nativen Icon- und Splash-Größen aus einer Quellgrafik generieren:

bun add -d @capacitor/assets
mkdir -p assets
# put icon.png (1024x1024) and splash.png (2732x2732) in ./assets
bunx capacitor-assets generate

Regeln, die beide Stores durchsetzen: keine Badges wie „Kostenlos“ oder „#1“, keine Screenshots von Geräten oder Logos anderer Marken, nichts, was eine andere App imitiert.

Screenshots

Screenshots sind der größte Faktor dafür, ob jemand installiert. Die meisten lesen die Beschreibung nie.

App-Store-Screenshot-Größen

Im Querformat werden dieselben Werte vertauscht. Formate sind PNG oder JPEG, ohne Alpha-Kanal. Du kannst 1 bis 10 Screenshots pro Größe und 0 bis 3 App-Previews hochladen.

Eine häufige Capacitor Überraschung: Neue Projekte unterstützen iPad standardmäßig. Wenn du keine iPad-Screenshots erstellen möchtest, setze das Target auf Unterstützte Ziele vor dem ersten Upload auf nur iPhone. Wenn du iPad-Support auslieferst, testen Reviewer auf dem iPad und lehnen kaputte Layouts ab.

Google Play Screenshot-Größen

• 2 bis 8 Screenshots pro Gerätetyp (Phone, 7-Zoll-Tablet, 10-Zoll-Tablet, Chromebook, Wear OS, Android XR, TV, Automotive).
• JPEG oder 24-Bit-PNG, ohne Alpha-Kanal.
• Jede Seite zwischen 320 und 3840 Pixeln; die lange Seite höchstens doppelt so lang wie die kurze.
• Für Smartphones mindestens 1080 x 1920 (Hochformat) oder 1920 x 1080 (Querformat) und mindestens vier Screenshots verwenden, sonst kommt die App für manche Featured-Platzierungen nicht infrage.
• Tablet-Screenshots sind erforderlich, wenn die App als tablet-optimiert erscheinen soll.

So werden sie erstellt

1. App auf einem Simulator der richtigen Größe ausführen. Im iOS-Simulator ein iPhone 17 Pro Max für 6,9 Zoll verwenden und Cmd+S drücken. Auf Android einen Emulator mit 1080 x 1920 oder höherem Bildschirm und die Kamera-Taste in der Emulator-Toolbar nutzen.
2. App mit realistischen Demo-Daten füllen. Leere Zustände verkaufen nichts.
3. Debug-UI ausblenden und die Statusleiste sauber halten (xcrun simctl status_bar booted override --time 9:41 --batteryState charged --batteryLevel 100).
4. Jedem Screenshot eine kurze Beschriftung hinzufügen, die den Nutzen beschreibt, nicht den Funktionsnamen.
5. Die ersten beiden Screenshots sollten die stärksten sein. Sie erscheinen in den Suchergebnissen.

Tools wie Figma-Templates, Fastlane snapshot/screengrab oder Online-Screenshot-Frame-Generatoren können die gerahmten Versionen in jeder Größe erzeugen.

Verwende nie Screenshots, die Funktionen zeigen, die die App nicht hat, und füge keine Google Play Badges in App Store Screenshots ein (oder umgekehrt).

Name, Untertitel und Beschreibungen

App Store

• Name (30 Zeichen): Marke plus ein kurzer Zusatz, wenn es passt, z. B. „Acme: Expense Tracker“.
• Untertitel (30 Zeichen): der Hauptvorteil. Wird für die Suche indexiert.
• Schlüsselwörter (100 Bytes): kommagetrennt, keine Leerzeichen nach Kommas, keine Wörter, die schon im Namen oder Untertitel stehen, keine Markennamen von Wettbewerbern, Singularformen reichen aus.
• Beschreibungstext (170 Zeichen): Wird über der Beschreibung angezeigt und kann ohne neue Version geändert werden. Ideal für aktuelle Angebote oder Neuigkeiten.
• Beschreibung (4.000 Zeichen): wird im App Store nicht für die Suche indexiert, also schreib für Menschen. Fang mit einem Satz an, was die App macht.

Google Play Store

• Titel (30 Zeichen): keine Emojis, keine GROSSBUCHSTABEN und keine Wörter wie „best“, „free“ oder „#1“, außer sie gehören zur Marke.
• Kurzbeschreibung (80 Zeichen): wird im Listing „above the fold“ angezeigt.
• Vollständige Beschreibung (4.000 Zeichen): für die Suche indiziert. Erwähne deine Haupt-Keywords natürlich ein paar Mal; Keyword-Stuffing führt zur Ablehnung der Listings.

Mehr zum Schreiben von Metadaten und zu Fehlern, die das Ranking kosten, findest du unter App Store-Metadaten: Was Entwickler wissen müssen.

Datenschutzerklärung

Beide Stores verlangen eine öffentliche URL für die Datenschutzerklärung. Diese muss:

• Ohne Login erreichbar sein und kein PDF-Download.
• Nenne den Entwickler- oder Firmennamen wie im Store-Listing.
• Liste auf, welche Daten du sammelst, warum, mit wem du sie teilst, wie lange du sie aufbewahrst und wie Nutzer eine Löschung anfordern können.
• Stimme mit dem überein, was du in den Privacy Labels und im Data-Safety-Formular angibst.

Verlinkt die Richtlinie auch in der App (Einstellungen oder Konto-Bildschirm). Wenn Nutzer Konten erstellen können, verlangen beide Stores die Kontolöschung in der App; Google verlangt zudem einen Web-Link, über den Nutzer die Löschung anfordern können, ohne die App neu zu installieren. Unser Leitfaden zur Kontolöschung und Datenschutzrichtlinien-Guide für Android-Apps tiefer einsteigen.

Apple App-Privacy-Labels

Öffnet in App Store Connect die App und geht zu App-Datenschutz. Ihr beantwortet:

1. Sammelt ihr oder eure Drittanbieter-Partner Daten aus dieser App?
2. Für jeden Datentyp (Kontaktdaten, Standort, Identifikatoren, Nutzungsdaten, Diagnosedaten, Finanzdaten …): Wofür er verwendet wird, ob er mit der Identität des Nutzers verknüpft ist und ob er für Tracking verwendet wird.

„Tracking“ hat eine enge Bedeutung: das Verknüpfen von Daten aus eurer App mit Daten aus Apps oder Websites anderer Unternehmen zu Werbezwecken oder das Teilen mit Datenhändlern. Wenn ihr trackt, braucht ihr auch den App Tracking Transparency-Prompt.

Die Labels müssen mit denen in deiner Privacy-Manifest (PrivacyInfo.xcprivacy) und die der von dir eingebundenen SDKs. Siehe unsere Privacy-Manifest-Guide für iOS-Apps.

Du kannst die App-Privacy-Antworten jederzeit aktualisieren, ohne einen neuen Build zu erstellen.

Google Play Datensicherheit

Gehe in der Play Console zu Richtlinien und Programme > App-Inhalte > Datensicherheit. Du erklärst:

• Welche Datentypen die App sammelt und welche sie mit Dritten teilt.
• Ob Daten während der Übertragung verschlüsselt werden.
• Ob Nutzer die Löschung anfordern können.
• Für jeden Typ: Zweck (App-Funktionalität, Analytics, Werbung, Betrugsschutz …) und ob die Erfassung optional ist.

Google kann Updates ablehnen, wenn die Erklärung nicht mit dem tatsächlichen Verhalten der App übereinstimmt, z. B. wenn ein SDK die Werbe-ID sendet, obwohl du keine Identifikatoren deklariert hast.

Die meisten Fehler bei der Datensicherheit stammen von SDKs. Erstelle eine Tabelle aller nativen SDK und Plugins in package.json, ios/App/Podfile oder Package.swift, und android/app/build.gradle, dann die Datenschutzrichtlinien des jeweiligen Anbieters lesen.

Altersfreigabe

Apple. Unter App-Informationen > Altersfreigabe du beantwortest Fragen zu Gewalt, sexuellen Inhalten, Schimpfwörtern, Glücksspiel, nutzergenerierten Inhalten, Messaging, Werbung und mehr. Apples Einstufungen sind 4+, 9+, 13+, 16+ und 18+. Apps mit unmoderierten nutzergenerierten Inhalten oder freiem Webzugriff bekommen höhere Einstufungen. Antworte ehrlich, Apple prüft das. Siehe unseren App Store Guide für Altersfreigaben.

Google. Unter App-Inhalte > Inhaltsbewertung, fülle den IARC-Fragebogen aus. Er erzeugt auf einmal die Bewertungen für jede Region (ESRB, PEGI, USK und andere). Du musst außerdem Zielgruppe und Inhalte angeben; wählst du eine Zielgruppe, die Kinder einschließt, greifen die Anforderungen der Families-Policy.

Weitere Angaben zu App-Inhalten bei Google Play

Bevor du veröffentlichen kannst, verlangt die Play Console all diese Angaben unter App-Inhalte:

• Datenschutzerklärung
• App-Zugriff (Login-Daten für Reviewer, falls etwas hinter einem Login liegt)
• Werbung (enthält die App Werbung?)
• Altersfreigabe
• Zielgruppe und Inhalte
• Datensicherheit
• Erklärung zu Regierungs-Apps
• Erklärung zu Finanzfunktionen
• Erklärung zu Gesundheits-Apps
• Nutzung der Advertising ID (falls SDK dies erfordert)

Review-Zugriff und Anmerkungen

Falls Teile der App einen Login erfordern, stelle für beide Stores einen funktionierenden Demo-Account bereit. Der Account darf nicht ablaufen, keine 2FA über ein Telefon verlangen, das du kontrollierst, und muss Zugriff auf alle Features bieten, auch auf kostenpflichtige. In App Store Connect fügst du ihn unter App-Review-Informationen; bei Google Play unter App-Zugriffhinzu. Füge eine kurze Notiz hinzu, die weniger offensichtliche Features, Hardware-Anforderungen oder erklärt, wo In-App-Käufe zu finden sind. Unser Guide für die erste App-Review erklärt, worauf Reviewer achten.

Lokalisierung

Beide Stores erlauben die Lokalisierung von Namen, Beschreibungen, Keywords (Apple) und Screenshots pro Sprache. Nur die Metadaten zu lokalisieren – selbst wenn die App-UI auf Englisch ist – verbessert oft die Conversion in nicht englischsprachigen Märkten. Apple indexiert zudem einige sekundäre Locales pro Land (z. B. werden Metadaten für Spanisch (Mexiko) im US-Store indexiert), was dir effektiv zusätzlichen Keyword-Platz verschafft.

Was du nach dem Release ändern kannst

Auf iOS bedeutet eine neue Version in der Regel ein neues Binary. Mit Capgo Live Updates Du kannst JavaScript- und UI-Fixes ohne Store-Review ausrollen, aber Änderungen an den Store-Metadaten müssen weiterhin über App Store Connect laufen.

Häufige Gründe, warum Listings blockiert werden

1. Die URL der Datenschutzerklärung liefert 404 oder erfordert einen Login.
2. Screenshots zeigen eine andere App-Version, Platzhalterinhalte oder das UI einer anderen Plattform.
3. iPad-Support aktiviert, aber keine iPad-Screenshots oder ein kaputtes iPad-Layout.
4. Datensicherheit gibt „keine Daten erfasst“ an, während ein Analytics SDK läuft.
5. Demo-Account fehlt oder ist abgelaufen.
6. Keyword-Stuffing in der Google-Play-Beschreibung.
7. Name oder Icon ist einer bestehenden App oder Marke zu ähnlich.
8. Support-URL oder Kontakt-E-Mail fehlt.

Checkliste

• 1024 x 1024 iOS-Icon in der App, 512 x 512 Play-Icon hochgeladen
• Play Feature-Grafik 1024 x 500
• iPhone 6,9” (oder 6,5”) Screenshots, iPad 13”, wenn iPad unterstützt wird
• Mindestens vier 1080p Smartphone-Screenshots für Google Play
• Name, Untertitel, Kurzbeschreibung innerhalb der Limits
• Keywords (App Store) gewählt, keine Duplikate mit dem Namen
• Beschreibung und Release Notes geschrieben
• URL der Datenschutzerklärung live und in der App verlinkt
• App-Privacy-Labels und Privacy Manifest stimmen überein
• Data-Safety-Formular vollständig, SDKs geprüft
• Altersfreigabe-Fragebögen in beiden Stores erledigt
• Play-App-Content-Deklarationen vollständig
• Demo-Account und Review-Notizen hinzugefügt
• Support-URL und Kontakt-E-Mail hinterlegt

Sobald das Listing steht, zuerst einen Build an Tester hochladen. iOS- und Android-Apps an Tester verteilen umfasst TestFlight, Play-Testing-Tracks und Alternativen.