Checkliste für App-Launch-Assets 2026: Alles, was beide Stores verlangen

Asset-Spezifikationen beim Launch ignorieren? Risiko einer sofortigen Ablehnung

Nichts bringt den Veröffentlichungstag so zum Scheitern wie ein Asset-Mismatch-Fehler oder das gefürchtete letzte-Knopf-Drücken für eine 1024x500 Play Feature-Grafik, an die Sie überhaupt nicht mehr gedacht haben. Der Ansatz „Wir korrigieren das nach dem Launch“ verschwendet nur Zeit – klären Sie das von Anfang an und ersparen Sie sich 24-Stunden-Ablehnungen und manuelle Metadatenprüfungen in beiden Stores. Ich halte diese Checkliste bei jedem App-Release-Sprint offen; jede unten aufgeführte Anforderung ist aktuell für 2026 (und ja, Apple hat die iPad-Screenshot-Gruppierungen im Mai wieder geändert).

Checkliste für App-Launch-Assets 2026

• App-Icon (iOS, Android)
• Screenshots (Gerätefamilien & Spezifikationen)
• Feature-Grafik (Google Play)
• App-Preview-Video (Optional, beide Stores)
• Promo-Assets (Optional, Play Store)
• Metadaten-Limits & was Uploads wirklich bricht

App-Icon: Ihr 1024x1024-Pass

Für unscharfe, schlecht zentrierte oder nicht quadratische Icons gibt es keinen Nachlass. Beide Stores verlangen 1024x1024 px – ohne Transparenz – und Apple skaliert für jedes Gerät und jede Werbeplatzierung herunter. Harte Fehler sehen Sie nur, wenn Sie keine PNG oder Alpha-Kanäle hochladen, aber ein überladenes, detailreiches Icon ist Gift für die Conversion-Rate. Mein Tipp: Prüfen Sie, wie Ihr Design bei 60x60px aussieht. Wenn Sie es nicht auf Distanz erkennen, fangen Sie besser nochmal von vorne an.

• Spezifikationen (2026): 1024 x 1024 px PNG, keine Alphakanäle, keine abgerundeten Ecken (die Stores runden automatisch), <1MB Dateigröße.
• Store-Dokumente: App Store-Richtlinien / Play Console Referenz
• Tool: App-Icons für alle erforderlichen Größen generieren

Screenshots: Pro Gerät, pro Anforderung, keine Abkürzungen

Hier machen viele Indie-Entwickler Fehler: nur iPhone 14 Pro Screenshots vorbereiten oder iPad-Bilder hochladen, die nicht den Spezifikationen entsprechen. Jede Gerätegruppe braucht ihren eigenen Satz. Seien Sie nicht die App mit gestreckten oder letterboxartigen Bildern in der Suche – das hinterlässt einen schlechten ersten Eindruck. Hier ist, was Sie brauchen, um auf „Bereit für Review“ zu klicken und den Upload in beiden Stores zu bestehen.

iOS App Store Screenshot-Spezifikationen (2026):

• Gerätefamilien:
  • iPhone 6,7" (z. B. iPhone 15 Pro Max, 1290x2796px)
  • iPhone 6,1" (z. B. iPhone 15/15 Pro, 1170x2532px)
  • iPad Pro 12,9" (2048x2732px) – Pflicht für iPad-Unterstützung 2026. Kein gemeinsames iPad 11" mehr als Gruppen-Cover.
  • iPad Pro 11" (1668x2388px) – wenn Ihnen Genauigkeit wichtig ist, aber nicht Pflicht für die Veröffentlichung.
• Anzahl: 1-10 pro Gerätegröße (mindestens 1 pro Pflichtfamilie; alle 10 für beste CTR, aber 5 sind das absolute Minimum, wenn es zeitlich knapp wird).
• Format: JPG oder PNG, 72dpi, RGB-Farben, <10MB pro Datei. CMYK-Saves werden abgelehnt.
• Seitenverhältnis: Muss exakt der Geräteauflösung entsprechen, kein Pillarboxing oder Letterboxing.
• Tool: Einfacher Generator für alle iOS-Screenshot-Größen

Google Play Screenshot-Spezifikationen (2026):

• Pflicht: Mindestens 2 pro Typ (Telefon, 7"-Tablet, 10"-Tablet, sobald Tablet-Support angegeben wird).
• Empfohlene Größen:
  • Telefon: 1080x2340px (16:9 und 19,5:9 okay, aber lieber hochkant für moderne Geräte)
  • 7"-Tablet: 600x1024px oder 1200x1920px. Play-Review fordert mindestens einen Full-Res-Tablet-Screenshot, wenn Sie Tablet-Kompatibilität angeben.
  • 10"-Tablet: 800x1280px oder 1600x2560px.
• Limits: Maximal 8 pro Gerätetyp. PNG oder JPG, 24-bit, <8MB pro Datei.
• Tipp: Die Play Console Richtlinie wird strikt für „nicht repräsentative“ Screenshots durchgesetzt – keine gefälschten UIs.
• Tool: Automatisch alle Play Store Screenshot-Größen generieren

Feature-Grafik (nur Google Play)

Bleibt auch 2026 Pflicht. Wird in Suchergebnissen und einigen Webansichten angezeigt – eine fehlende oder nicht den Specs entsprechende Grafik killt heimlich Ihre Akquisitionsrate. Viele Apps verzichten darauf oder nutzen einen Screenshot-Crop (fauler Trick). Gestalten Sie sie aussagekräftig und gut lesbar in kleinen Größen – denken Sie an Spotify oder Calm, nicht an eine Textwand.

• Spezifikationen: 1024 x 500px, JPG oder 24-bit PNG (kein Alpha), <1MB.
• Fallen: Setzen Sie keine wichtigen Logos am Rand – Google schneidet auf manchen Oberflächen zu.
• Tool: Feature-Grafik designen und skalieren

App Preview Video: Optional, aber nicht verzichtbar

Technisch gesehen können Sie auch ohne Video starten. Die meisten Indie-Entwickler verzichten beim ersten Mal, aber die Conversion-Daten meiner Launches sagen: ein halbwegs kompetenter Preview schlägt reine Screenshots – besonders bei Play, wo das Videominiaturbild Ihr Listing dominiert. Wenn Sie nur eines erstellen können, priorisieren Sie Google Play (nur 1 Landscape, max. 30 Sekunden).

• App Store: 15-30 Sekunden, M4V/MP4, 1920x886px für iPhones (horizontal) oder 886x1920px (vertikal), max. 3 pro Gerätefamilie. Keine Cross-Promotion oder Werbung – Apple markiert „Download auf Google Play“-Overlays automatisch und lehnt Ihr Build ab.
• Play Store: YouTube-Link, empfohlen 30 Sek. Landscape (16:9), mind. 720p. Sehr strikt bei "In-App-Footage", keine Talking-Head-Promos.

Promo-Assets: Nicht Pflicht, aber nützlich

Neun von zehn Indie-Launches, die ich sehe, verzichten auf Promo-Images oder Sticker für den Play Store – bis eine Featurechance oder Bannerplatzierung ansteht und Sie in 10 Minuten eine 180x120px-Grafik zusammenschustern müssen. Für den Launch nicht erforderlich, aber wenn Sie für Store-Features mitspielen wollen, erstellen Sie diese sechs Dateien einmal und versionieren sie zusammen mit Ihrer Quelle. (Aktuelle Liste via Play Console.)

• TV-Banner: 1280x720px
• Wear OS Screenshot: 384x384px (wenn Sie Smartwatch-Support angeben)
• Promo Image: 180x120px (selten 2026, aber nicht veraltet – wird noch für einzelne Suchplatzierungen genutzt)

Metadaten: Titel, Beschreibungen und wo Sie Fehler machen

Asset-Uploads scheitern sofort bei falscher Auflösung. Metadaten-Limits schreiten erst nach dem Einfügen Ihrer liebevoll verfassten Beschreibung ein und zeigen die Fehlermeldung „ungültige Länge“ mittendrin beim Absenden. Ich habe keine Zeit für allgemeine „optimiere deine Keywords“-Tipps – die Grenze zwischen „freigegeben“ und „Fehler“ ist ein harter Zeichencut, den die Stores tatsächlich durchsetzen.

• iOS:
  • Titel: 30 Zeichen
  • Untertitel: 30 Zeichen
  • Werbetext: 170 Zeichen
  • Beschreibung: 4000 Zeichen
  • Keywords: 100 Zeichen (kommagetrennt)
• Google Play:
  • App-Name: 50 Zeichen
  • Kurzbeschreibung: 80 Zeichen
  • Volltextbeschreibung: 4000 Zeichen
  • Was gibt’s Neues: 500 Zeichen
• Falle: Play lehnt Emojis oder Sonderzeichen im Titel ab, und der App Store lehnt konsequent ab, wenn Sie Ihren App-Namen im Untertitel wiederholen. Prüfen Sie mit einem einfachen Texteditor – intelligente Anführungszeichen schleichen sich gerne beim Kopieren aus Google Docs ein.

Testen und Einreichen: Der fehlende Schritt

Bevor Sie hochladen, testen Sie alle Assets auf echten Geräten (Hintergründe im Dunkel-/Hellmodus, neue Geräte-Notches, iPad-Landschaft bei Split View, falls Ihnen Tablets wichtig sind). Stores zeigen keine Vorschau, wie User Ihre Uploads sehen. Ich nutze ScreenshotWhale für eine letzte Prüfung der Gerätevorschauen und um dumme Fehler zu erwischen – es ist schneller als das erneute Exportieren jeder Größe aus Figma und behebt die meisten der oben genannten Stolperfallen.

Diese Checkliste aktuell halten

Spezifikationen ändern sich, meist kurz vor Deadlines oder rund um WWDC/Google I/O. Legen Sie die Dokumente, die Sie tatsächlich nutzen, als Lesezeichen an, und vertrauen Sie nicht auf beliebige Reddit-Threads oder Discord-Gerüchte zu akzeptierten Größen. Wenn Apple oder Google eine neue Gerätefamilie einführt oder stillschweigend die Bezeichnungen ändert (wie „Feature Graphic“, die für Play in manchen Ländern zu „Listing Banner“ wurde – das passierte letztes Jahr im Beta-Status), prüfen Sie die aktuellen Anforderungen vor jedem Launch nach. Die Checklisten oben haben mir mindestens vier Launch-Desaster gerettet – hoffentlich auch Ihnen eines.