App-Store-Veröffentlichung: alle deine Fragen aus unserem Reddit-AMA beantwortet

Screenshots haben zwei Aufgaben gleichzeitig: Sie überzeugen jemanden, deine App herunterzuladen, und sie helfen Apple zu verstehen, was die App während der Prüfung tut. Zeig deine Hauptfunktionen und den Mehrwert, den sie bieten, statt wahllos irgendwelche Screens zu zeigen — wenn etwas deine App besonders macht, ein einzigartiger Workflow, eine Community-Funktion, ein bestimmter Anwendungsfall, dann sorg dafür, dass es sichtbar ist.

Ein Detail, über das mehr Leute stolpern, als man denkt: Deine Screenshots müssen zu der Version der App passen, die du tatsächlich einreichst. Es kommt überraschend oft vor, dass ein Teil einer App neu gestaltet wird, ein neuer Build eingereicht wird — und man vergisst, die App-Store-Screenshots zu aktualisieren. Eine deutliche Abweichung zwischen dem, was gezeigt wird, und dem, was tatsächlich geprüft wird, kann während der App Review Fragen aufwerfen. Apple stellt außerdem offizielle Produkt-Bezels bereit, um deine Screenshots sauber und einheitlich zu präsentieren — nutze sie, falls noch nicht geschehen. Ein letzter Hinweis von unseren iOS-Ingenieuren: Screenshots, die das Produkt oder den Dienst eines Mitbewerbers zeigen, haben schon Probleme bei der Prüfung verursacht, das solltest du also ganz vermeiden.

Eine D-U-N-S-Nummer brauchst du nur, wenn du dich beim Apple Developer Program als Organisation anmelden willst. Wenn du als Einzelperson veröffentlichst, brauchst du sie überhaupt nicht.

Für ein Organisationskonto musst du deine Organisation zunächst bei Dun & Bradstreet (oder einem lokalen Partner) registrieren — die D-U-N-S-Nummer zu bekommen, dauert in der Regel etwa zwei Wochen, und Apple kann während der Anmeldung zusätzliche Informationen anfordern. Im Gegenzug bringt ein Organisationskonto echte Vorteile: Deine Organisation erscheint im App Store als Entwickler statt deines persönlichen Namens, es passt in der Regel besser zu Unternehmen und Teams (besonders wenn sich die Inhaberschaft im Laufe der Zeit ändert), es erleichtert es, die Eigentümerschaft an deiner Marke und deinen Inhalten während der Prüfung nachzuweisen, und in manchen Ländern kannst du dadurch für einen Erlass der Apple-Developer-Program-Gebühr infrage kommen. Wenn du dagegen ein unabhängiger Entwickler bist, der seine eigenen Apps veröffentlicht, ist ein Einzelkonto völlig ausreichend und du sparst dir die D-U-N-S-Nummer komplett.

Eine wiederkehrende Quelle der Verwirrung: kryptische Transporter-Fehler beim Hochladen eines Builds. Drei der häufigsten, entschlüsselt:

• „No suitable application records were found" → der App-Datensatz existiert wahrscheinlich noch nicht in App Store Connect.
• „Potential loss of keychain" → normalerweise nur eine Warnung, die auftritt, wenn die App zwischen Apple-Entwicklerkonten übertragen wurde.
• „Redundant binary upload" → du lädst wahrscheinlich einen Build mit derselben Versions- oder Build-Nummer hoch wie einen bereits vorhandenen.

Eine der Fragen, die uns am häufigsten gestellt werden. Nach dem, was wir bei der Begleitung unserer Kunden sehen, sind die meisten Prüfungen innerhalb von 24 bis 48 Stunden abgeschlossen, auch wenn es je nach App und Apples Arbeitsauslastung länger dauern kann.

Wenn du gegen eine Deadline arbeitest — ein Launch-Event, ein Veröffentlichungstermin — reiche so früh wie möglich ein, statt bis zur letzten Minute zu warten. So hast du, falls Apple vor der Genehmigung Änderungen verlangt, noch Zeit, sie umzusetzen. Und wenn dein Zeitplan wirklich eng wird, bietet Apple eine beschleunigte Prüfung für zeitkritische Situationen an. Sie ist nicht garantiert, aber einen Versuch wert, sobald du einen festen Termin einhalten musst.

Der richtige Zeitpunkt, die Beta zu verlassen, ist nicht, wenn deine App perfekt ist — sondern wenn sie bereit für echte Nutzer ist. In der Praxis heißt das: Das Kernerlebnis ist stabil, die App hat bereits relevante Inhalte, und deine Beta-Nutzer kommen immer wieder zurück, weil sie tatsächlich ein Problem für sie löst.

Der zweite Teil zählt genauso: Veröffentliche nicht ohne Launch-Plan. Ein häufiger Fehler ist, die ganze Energie in die Genehmigung zu stecken, nur um danach festzustellen, dass niemand weiß, dass die App existiert. Eine klare Zielgruppe und eine klare Antwort auf die Frage „Warum sollte sich jemand für diese App statt für eine andere entscheiden?" wirkt sich viel stärker auf die Zugkraft aus als ein paar Tage früherer Launch. Und diese Antwort hilft nicht nur dem Marketing: Sie passt in der Regel auch zu dem, wonach Apple während der App Review sucht. Apps, die etwas wirklich Nützliches oder Eigenständiges bieten, haben meist einen reibungsloseren Weg als Apps, die wie eine weitere Variante von etwas Bestehendem wirken.

Beide Plattformen können auf ihre eigene Art knifflig sein. Nach dem, was wir sehen, werden Erstveröffentlichungen bei Apple häufiger abgelehnt als bei Google Play — das heißt aber nicht, dass Google Play einfacher ist. Es hat seine eigenen Einschränkungen, die je nach Entwicklerkonto-Typ und App-Konfiguration genauso viel Reibung erzeugen können. Bei Updates ist die Ablehnungsquote zwischen beiden meist viel ähnlicher.

Ein langjähriger GoodBarber-Nutzer hat diesen Trade-off im Thread gut zusammengefasst: Bei Apple zu veröffentlichen ist ein ganzer Prozess, und es gibt immer irgendeinen Grund, aus dem eine App markiert wird — aber mit GoodBarbers Dokumentation und Support an der Seite fällt der größte Teil des Stresses weg, und es ist gewährleistet, dass die App dauerhaft konform mit den Store-Richtlinien bleibt. Er wies auch darauf hin, dass Google Play, früher die einfachere Plattform, ebenfalls strenger geworden ist: Apps brauchen jetzt regelmäßige Updates, sonst riskiert das Entwicklerkonto eine Markierung. Zuverlässiger Support auf beiden Seiten sei, seiner Meinung nach, unbezahlbar.

Zu Google Play im Speziellen gibt es wirklich noch viel zu sagen — genug, dass wir ein eigenes AMA zu diesem Thema planen, statt hier alles zu vermischen.

All das oben Genannte ist genau das, womit sich unser Support-Team täglich beschäftigt — und genau deshalb gibt es dafür ein eigenes Angebot: GoodBarber Takes Care (GBTC). Statt die App Review selbst zu übernehmen, reicht das GBTC-Team die App von Anfang bis Ende für dich bei App Store und Google Play ein. Apple lehnt im Schnitt rund 42 % der Erstveröffentlichungen ab — oft aus Gründen, die schwer vorherzusehen sind —, aber in den letzten 12 Monaten hat das GBTC-Team erreicht, dass 91 % dieser abgelehnten Erstveröffentlichungen letztlich doch angenommen wurden. Bei Updates senkt vorausschauende Präventionsarbeit die Ablehnungsquote auf nur noch 5 %. Wenn du die App Review lieber einem Team überlässt, das täglich damit lebt, ist GBTC genau dafür da.

Das war die Zusammenfassung, aber der ursprüngliche Thread lohnt sich weiterhin für alle Details zu jeder Antwort — und er bleibt offen. Wenn du also eine Frage hast, die wir nicht behandelt haben, kannst du sie dort weiterhin stellen: App-Store-Veröffentlichungs-AMA auf r/GoodBarber.

Das war unser zweites Live-AMA. Sag uns in den Kommentaren, welches Thema wir uns als Nächstes vornehmen sollen.