App Store Connect: App veröffentlichen (Leitfaden 2026)

Eine Sache vorweg, die den Rest dieses Textes erklärt: Apple stellt für App Store Connect keinerlei deutschsprachige Dokumentation bereit. Die Review-Seite unter developer.apple.com/de/app-store/review/ liefert einen 404. Der Hilfe-Leitfaden zu App Store Connect existiert auf Koreanisch, auf Japanisch und auf Chinesisch, aber nicht auf Deutsch. Das ist der Grund, warum sich in deutschen Ratgebern falsche Zahlen so hart halten: Sie werden voneinander abgeschrieben, weil es keine deutsche Primärquelle gibt, gegen die sich prüfen ließe.

Dieser Leitfaden gibt deshalb bei jedem Wert an, wogegen er geprüft wurde, und korrigiert drei Angaben, die in deutschen Beiträgen systematisch falsch stehen: die Review-Dauer, den Preis des Developer Programs und die Größe des Keyword-Felds.

Programm und Kosten

Vor der ersten Veröffentlichung steht die Mitgliedschaft im Apple Developer Program. Apple veröffentlicht dafür 99 US-Dollar pro Jahr. Das ist keine Formalie, sondern eine Korrektur: Zahlreiche deutsche Seiten schreiben „99 Euro“ und geben damit einen Preis an, den Apple so nicht veröffentlicht. Der lokale Betrag entsteht erst im Bezahlvorgang und hängt von Wechselkurs und Steuersatz ab. Wer intern budgetiert, plant deshalb mit dem Dollarbetrag zuzüglich Umrechnung, nicht mit einer gerundeten Euro-Zahl aus einem Blogartikel.

Für Organisationen verlangt Apple zusätzlich eine D-U-N-S-Nummer zur Verifizierung. Wichtig für die Planung: Diese Anforderung ist nicht Apple-exklusiv. Google verlangt sie für Organisationskonten ebenfalls, was auf deutschen Seiten regelmäßig untergeht. Details dazu stehen im Leitfaden zur Google Play Console.

Der API-Key: Issuer ID, Key ID und die .p8-Datei

Sobald der Upload automatisiert werden soll, sei es über eine CI-Pipeline oder ein externes Tool, führt der Weg über einen App-Store-Connect-Key. Er besteht aus drei Teilen, und einer davon ist unwiederbringlich.

Die .p8-Datei lässt sich exakt einmal herunterladen. Geht sie verloren, gibt es keinen Weg zurück: Der Key muss widerrufen und ein neuer erzeugt werden, und jede Pipeline, die ihn nutzte, bricht bis zur Umstellung. Die Datei gehört deshalb sofort nach dem Download in den Passwortmanager oder den Secret-Store der CI, niemals in ein Git-Repository. Rollen lassen sich pro Key vergeben, ein Key für Uploads braucht keine Admin-Rechte.

Metadatenlimits, und warum Umlaute teuer sind

Die dritte Zeile ist für den deutschen Markt die wichtigste. Das Keyword-Feld misst 100 Bytes, nicht 100 Zeichen. In UTF-8 belegt ein normaler lateinischer Buchstabe ein Byte, die deutschen Sonderzeichen ä, ö, ü und ß dagegen jeweils zwei. Konkret:

• „Größe“ hat 5 Zeichen und belegt 7 Bytes.
• „Bücher“ hat 6 Zeichen und belegt 7 Bytes.
• „Ernährungstagebuch“ hat 18 Zeichen und belegt 19 Bytes.

Ein deutscher Keyword-Satz schöpft das Feld also messbar schneller aus als ein englischer, während der Zeichenzähler im Editor beide gleich lang anzeigt. Zwei praktische Regeln folgen daraus: Wörter mit Umlauten nur aufnehmen, wenn Nutzer sie tatsächlich so eingeben, und keine Begriffe doppeln, die bereits im App-Namen oder im Untertitel stehen. Apple indexiert die Summe dieser Felder, jede Wiederholung sind verschenkte Bytes. Der Beitrag zur App Store Optimierung geht auf die Auswahl der Begriffe im Detail ein.

Screenshot-Größen, direkt bei Apple geprüft

Die Größen wurden für diesen Beitrag unmittelbar bei Apple nachgesehen. Bemerkenswert ist, dass für dasselbe Gerät mehrere Größen akzeptiert werden, was in Vorlagen selten abgebildet ist.

Dazu zwei harte Vorgaben: kein Alphakanal in den Bilddateien und ein bis zehn Screenshots pro Lokalisierung. Der Alphakanal ist der häufigste stille Ablehnungsgrund, weil viele Design-Tools PNG standardmäßig mit Transparenz exportieren, auch wenn keine Fläche transparent ist.

Wer beide Stores bedient, pflegt schnell ein Dutzend Exportvarianten pro Sprache. Der Screenshot-Editor von AppBoard exportiert direkt in den akzeptierten Größen und ist in der Beta kostenlos.

Review: die Zahl, die deutsche Seiten falsch angeben

Apple gibt an, dass im Durchschnitt 90 Prozent der eingereichten Apps in weniger als 24 Stunden geprüft werden. Die in deutschen Beiträgen verbreitete Angabe von ein bis zwei Wochen entspricht dieser Größenordnung nicht. Wer plant, sollte den Puffer deshalb nicht in die Wartezeit legen, sondern in die Iteration: Eine Ablehnung, eine Korrektur und eine erneute Einreichung sind zeitlich der realistische Risikofall, nicht die Erstprüfung.

Was die Prüfung tatsächlich aufhält, ist in der Regel banal: unvollständige Angaben zum Datenschutz, Testzugänge ohne funktionierende Anmeldedaten, Funktionen hinter einem Login ohne Demokonto oder Screenshots, die eine Funktionalität zeigen, die im Build nicht existiert. Ein sauber ausgefülltes Feld für Hinweise an den Reviewer spart im Zweifel mehrere Tage.

DSA-Händlerstatus: Pflicht, und Apple veröffentlicht die Daten

Dieser Punkt fehlt in praktisch jedem deutschsprachigen Beitrag zum Thema, obwohl er unmittelbar über die Verfügbarkeit der App in der EU entscheidet.

• Der Händlerstatus ist für die Verbreitung in der EU nach den Artikeln 30 und 31 DSA erforderlich.
• Nach der Verifizierung veröffentlicht Apple Name, Adresse, Telefonnummer und E-Mail-Adresse des Händlers auf der Produktseite im App Store, und zwar in allen 27 EU-Territorien.
• Privatpersonen können eine Adresse oder ein Postfach angeben. Wer als Einzelperson veröffentlicht, sollte das vor der Angabe der Privatadresse wissen.
• Seit dem 16. Oktober 2024 ist der Status Voraussetzung für das Einreichen von Updates.
• Seit dem 17. Februar 2025 wurden Apps ohne Händlerstatus aus dem EU-App-Store entfernt, bis der Status angegeben und verifiziert ist.

Für Google Play gilt das nicht analog. Eine offizielle Hilfeseite von Google Play, die eine gleichwertige DSA-Anforderung dokumentiert, ließ sich nicht finden. Google dokumentiert eine Pflicht zur vollständigen Adressangabe für Händlerkonten aus dem Verbraucherschutzrecht, und die Seite zu den allgemeinen Zugangsbedingungen im EWR behandelt den DMA, nicht den DSA. Wer eine symmetrische Pflicht in beiden Stores annimmt, argumentiert über die Quellenlage hinaus.

Getrennt davon steht die deutsche Rechtslage: Nach juristischer Kommentarliteratur besteht für kommerziell betriebene Apps eine Impressumspflicht nach Paragraph 5 DDG, dem Nachfolger von Paragraph 5 TMG. Das ist deutsches Recht und keine Store-Richtlinie. Für die konkrete Umsetzung im Einzelfall ist anwaltliche Beratung angebracht.

Ablauf bis zum Release

1. Mitgliedschaft im Apple Developer Program. 99 US-Dollar pro Jahr, für Organisationen zusätzlich die D-U-N-S-Nummer.
2. Bundle-ID und App-Eintrag anlegen. Die Bundle-ID ist nach der Erstellung nicht mehr änderbar.
3. API-Key erzeugen. Issuer ID und Key ID notieren, die .p8-Datei sofort sicher ablegen, sie ist nur einmal ladbar.
4. Händlerstatus angeben und verifizieren lassen. Ohne ihn keine Updates und keine Verfügbarkeit in der EU.
5. Datenschutzangaben ausfüllen. Datenerhebung pro Kategorie, plus Datenschutzerklärung als erreichbare URL.
6. Metadaten pro Sprache pflegen. 30 Zeichen Name, 30 Zeichen Untertitel, 100 Bytes Keywords, 170 Zeichen Promotional Text, 4000 Zeichen Beschreibung.
7. Screenshots hochladen. Geprüfte Größen, kein Alphakanal, ein bis zehn Stück pro Lokalisierung.
8. Build hochladen und einreichen. Mit Demokonto und Hinweisen an den Reviewer, das verhindert die meisten Rückfragen.
9. Phased Release nutzen. Schrittweise Verteilung statt alles auf einmal.

Häufige Fragen

Weiterlesen

Wer parallel bei Google veröffentlicht, findet die Kontoregeln, die 12-Tester-Pflicht und die Grafikvorgaben im Leitfaden zur Google Play Console. Was ein externer Dienstleister für die laufende Optimierung kostet und wann sich das rechnet, steht im Beitrag zu den ASO-Kosten.

Alle Angaben wurden im August 2026 gegen die Dokumentation von Apple geprüft. Screenshot-Größen und Metadatenlimits ändern sich schneller als der Rest des Prozesses, deshalb vor jedem größeren Release kurz gegenprüfen.