Die App-Einreichungs-Checkliste: jedes Asset für beide Stores (2026)

Du hast die App gebaut. Beide Stores wollen jetzt einen Stapel Assets und Antworten, bevor sie sie durchlassen — und die beiden Stapel sind unterschiedlich. Das hier ist die Obermenge: jedes Asset und jedes Feld, das App Store Connect und Google Play Console verlangen, gruppiert nach Store, mit den 2026er-Build-Regeln, die einen Upload blockieren, noch bevor das Review überhaupt beginnt.

Eine reine Screenshot-Checkliste haben wir bereits (Link unten). Diese hier ist die größere Liste — Screenshots sind hier nur ein Punkt, neben Icons, Feature-Grafiken, Listing-Text, Datenschutz-Formularen, Alterseinstufungen und den Build-Anforderungen, die den Upload selbst blockieren.

Anforderungen und Fristen verschieben sich. Behandle jede datierte Regel unten als Hinweis, das am Einreichungstag gegen die offizielle Dokumentation des jeweiligen Stores zu prüfen ist — nicht als feste Tatsache.

Schritt 0: die zwei Entwicklerkonten

Ohne Konto bei jedem Store geht nirgends etwas — und die Preismodelle unterscheiden sich:

• Apple Developer Program — 99 $ pro Jahr (USD, in Landeswährung abgerechnet). Es ist eine wiederkehrende Mitgliedschaft. Läuft sie ab, verschwinden deine Apps aus dem App Store, bis du erneuerst.
• Google Play Console — 25 $, einmalig bei der Registrierung. Einmalig, nicht erstattungsfähig, keine Verlängerung.
• Identitätsprüfung in beiden Fällen. Privat- und Organisationskonten durchlaufen beide eine Verifizierung. Organisationskonten bei Google brauchen eine D-U-N-S-Nummer; Apple verifiziert die juristische Person bei der Organisationsregistrierung. Plane hierfür ein paar Tage ein, bevor du ausliefern willst.

Apple: was App Store Connect verlangt

Der Build:

• App-Binary, gebaut mit einem aktuellen SDK. Seit April 2025 müssen iOS- und iPadOS-Apps mit dem iOS-18-SDK (Xcode 16) oder neuer gebaut sein, um hochgeladen werden zu können. Apple hat angekündigt, dass Uploads ab dem 28. April 2026 das iOS-26-SDK oder neuer benötigen — prüfe, welches SDK an deinem Einreichungstag gilt.
• App-Icon im Build. Apple zieht das Icon aus dem Asset-Katalog der App; ein separater Icon-Upload in App Store Connect existiert nicht. Ein fehlendes oder fehlerhaftes Icon lässt die Validierung beim Upload scheitern.
• Eindeutige Bundle-ID, gültige Signierung und Export-Compliance-Antworten. Die Verschlüsselungs-/Export-Fragen kommen beim Upload — die meisten Apps antworten mit einer Standardausnahme, aber beantworten musst du sie trotzdem.

Visuelle Assets:

• Screenshots für das 6,9-Zoll-iPhone. Mindestens einer, bis zu zehn. Zulässige Größen sind 1320 × 2868, 1290 × 2796 und 1260 × 2736 (Hochformat). Apple skaliert dieses Set automatisch auf kleinere iPhones herunter, das 6,5-Zoll-Set ist also nur nötig, wenn du 6,9 Zoll komplett auslässt.
• iPad-Screenshots, wenn die App iPad unterstützt. Das 13-Zoll-Set ist 2064 × 2752 oder 2048 × 2732 (Hochformat). Erforderlich, wenn deine App auf dem iPad läuft.
• Optionales App-Preview-Video pro Gerätegröße, 15–30 Sekunden.

Listing-Text:

• App-Name (bis zu 30 Zeichen) und Untertitel (bis zu 30).
• Keywords — ein einzelnes, kommagetrenntes Feld mit 100 Zeichen, das Nutzern nie angezeigt wird, aber die Suche antreibt.
• Beschreibung (bis zu 4.000 Zeichen) und Werbetext (bis zu 170, editierbar ohne neuen Build).
• Support-URL und optional eine Marketing-URL.

Rechtliches, Datenschutz und Alterseinstufung:

• Datenschutzerklärung-URL. Für jede App Pflicht.
• App-Datenschutz-Angaben — das „Nährwert-Etikett". Du gibst an, welche Daten deine App und ihre Third-Party-SDKs sammeln und wie sie genutzt werden. Diese Angaben sind zum Einreichen erforderlich und erscheinen als Datenschutz-Label auf deiner Produktseite.
• Alterseinstufung. Wird per Fragebogen beantwortet. Apple ist zu einem feineren Alterseinstufungssystem übergegangen (mit den Stufen 13+, 16+ und 18+), das auf Geräten mit iOS 26 und neuer angezeigt wird — prüfe deine Angaben also erneut, wenn du eine App zuletzt nach dem alten Schema eingestuft hast.
• Primärkategorie (und optional eine sekundäre), plus ein Weg zur Kontolöschung in der App, falls deine App Kontoerstellung unterstützt.

Google: was Play Console verlangt

Der Build:

• Ein Android App Bundle (.aab), keine APK, für neue Apps.
• Ziel-API-Level. Neue Apps und Updates müssen derzeit mindestens auf Android 15 (API-Level 35) zielen. Google hat angekündigt, dass neue Apps und Updates ab dem 31. August 2026 auf Android 16 (API-Level 36) zielen müssen — prüfe, welches Level an deinem Einreichungstag gilt.
• Signierter Release-Build, typischerweise über Play App Signing.

Visuelle Assets:

• App-Icon — 512 × 512 px, 32-Bit-PNG, unter 1 MB.
• Feature-Grafik — 1024 × 500 px, JPEG oder 24-Bit-PNG ohne Alphakanal. Dies ist ein Pflicht-Asset für Play ohne Apple-Äquivalent — das Banner am oberen Rand deines Listings.
• Mindestens 2 Smartphone-Screenshots (bis zu 8). JPEG oder 24-Bit-PNG, jede Seite zwischen 320 und 3.840 px, Seitenverhältnis 16:9 oder 9:16. Tablet- und andere Formfaktor-Screenshots sind optional, außer du zielst auf diese Geräte ab.
• Optionales Promo-Video als YouTube-URL.

Listing-Text:

• App-Name (bis zu 30 Zeichen).
• Kurzbeschreibung (bis zu 80) — die erste Zeile, die Nutzer lesen.
• Vollständige Beschreibung (bis zu 4.000).

Rechtliches, Datenschutz und Alterseinstufung:

• Datenschutzerklärung-URL. Pflicht.
• Formular zur Datensicherheit. Googles Gegenstück zu Apples Datenschutz-Label — du gibst an, welche Daten du sammelst, weitergibst und wie sie verarbeitet werden. Vor der Veröffentlichung Pflicht, und es muss dem tatsächlichen App-Verhalten entsprechen.
• Fragebogen zur Inhaltseinstufung (IARC). Erzeugt aus deinen Antworten regionsspezifische Alterseinstufungen.
• App-Kategorie sowie Angaben zur Zielgruppe und zu Werbung. Richtet sich die App auch nur teilweise an Kinder, gelten zusätzliche Anforderungen.

Die 2026er-Regeln, die einen Build vor dem Review ablehnen

Hier geht es nicht um Feinschliff — sie blockieren den Upload oder das Release direkt, deshalb lohnt es sich, sie zuerst zu prüfen:

• Apples Mindest-SDK. Uploads brauchen seit April 2025 das iOS-18-SDK (Xcode 16), das iOS-26-SDK wird laut Apples Ankündigung um den 28. April 2026 zur Untergrenze. Baust du mit einem alten SDK, lehnt App Store Connect die Binary beim Upload ab.
• Googles Ziel-API-Level. Neue Apps und Updates zielen heute auf Android 15 (API 35), laut Googles angekündigtem Zeitplan ab dem 31. August 2026 auf Android 16 (API 36). Ein zu niedriges Ziel-Level blockiert das Release.
• Googles Closed-Testing-Schranke für Privatkonten. Private Entwicklerkonten, die nach dem 13. November 2023 erstellt wurden, müssen einen Closed-Test mit mindestens 12 opt-in-Testern über 14 aufeinanderfolgende Tage durchführen, bevor sie Produktionszugriff beantragen können. (Google hat dies Ende 2024 von 20 Testern gesenkt.) Verifizierte Organisationskonten sind davon ausgenommen. Das überrascht Solo-Entwickler am häufigsten — es fügt mindestens zwei Wochen zwischen „App ist fertig" und „App ist live" ein, also starte den Closed-Test frühzeitig.

Der gemeinsame Pre-Flight (beide Stores)

Ein paar Prüfungen gelten auf beiden Seiten und werden im Ausliefer-Trubel leicht übersehen:

• Screenshot-Untertitel in der Sprache jedes Locales. Englische Untertitel in einem deutschen oder japanischen Listing werden markiert. Untertitel-Sprache und Listing-Locale müssen übereinstimmen.
• Assets und Text stimmen mit der App überein. Zeigt ein Screenshot oder eine Beschreibung ein Feature, muss die ausgelieferte App es tatsächlich haben. Beide Stores lehnen bei übertreibenden Metadaten ab.
• Keine Preise oder store-fremde URLs in Screenshots eingebrannt. Preise gehören auf die Store-Seite, nicht ins Artwork; „Besuch unsere Website"-Overlays führen zu Ablehnungen.
• Datenschutzangaben entsprechen der Realität. Sowohl Apples Datenschutz-Label als auch Googles Formular zur Datensicherheit müssen widerspiegeln, was dein Code und deine SDKs tatsächlich tun.
• Ein funktionierendes Testkonto, falls die App hinter einem Login liegt — dem Reviewer in den Review-Notizen übergeben.

Wo Mokbi hineinpasst

Den größten Teil dieser Checkliste erledigst du selbst — das Konto, den Build, die Datenschutz-Angaben, die Einstufungen. Mokbi deckt die visuellen und textlichen Assets ab, also genau den Teil, der die meisten Stunden frisst, wenn du ihn für zwei Stores und viele Sprachen von Hand machst.

• Die visuellen Assets. Es erzeugt aus einem einzigen Projekt die Screenshots für beide Stores in den geforderten Größen sowie die Play-Feature-Grafik — so schneidest du dasselbe Artwork nicht für jede Geräteklasse neu zu.
• Der Listing-Text. Es entwirft Name, Untertitel, Beschreibung und Kurzbeschreibung und übersetzt dann das gesamte Listing in 50 Sprachen, sodass jede Locale mit passenden Untertiteln und Texten ausgeliefert wird.
• Das fertige Listing veröffentlichen. Mokbi überträgt die fertigen Assets und Store-Texte für dich: direkt zu Google Play über die Play Developer API, und bei App Store Connect als versandbereite Version bereitgestellt. Den letzten Submit-und-Review-Schritt verlangt Apple von dir selbst — das ist eine Apple-Regel, keine Grenze von Mokbi.

Der Punkt ist nicht, die Checkliste zu ersetzen — sondern die Asset- und Übersetzungsspalten daraus zu streichen, damit der Rest ein kürzerer Nachmittag wird.

Was als Nächstes lesen

• Google-Play-Listing-Anforderungen, Asset für Asset
• Was du ohne neue Version ändern kannst
• Die reine Screenshot-Checkliste vor der Einreichung

Editor öffnen →