App Store und Google Play lehnen auch heute noch ab, meist aus vermeidbaren Gruenden. Diese Checkliste hilft.
Ein App-Launch ist kein Sprint-Finish. Es ist eher ein Staffellauf mit klaren Uebergaben.
Die Review-Zeiten bei Apple und Google sind kuerzer geworden, Ablehnungen passieren trotzdem, gerne kurz vor dem geplanten Launch-Termin. Die gute Nachricht: Die meisten Gruende dafuer sind vermeidbar, sie entstehen aus Unkenntnis, nicht aus echten Problemen.
Wo Apple besonders genau hinschaut
Unvollstaendige Datenschutzerklaerungen, fehlende oder falsche Privacy-Manifest-Eintraege, fehlende In-App-Purchase-Pflicht bei digitalen Guetern und irrefuehrende Screenshots gehoeren zu den haeufigsten Ablehnungsgruenden. Apple gilt zurecht als streng.
Wo Google genauer hinschaut
Google Play ist etwas entspannter, verlangt aber ein aktuelles Target API Level, begruendete Berechtigungen und ein vollstaendiges, kohaerentes Store Listing.
Was vor dem Submission stehen sollte
App-ID und Bundle Identifier korrekt gesetzt, Version- und Build-Nummer hochgezaehlt, Release Notes in allen benoetigten Sprachen fertig, Screenshots fuer alle geforderten Geraetegroessen vorhanden, Datenschutzerklaerung verlinkt und aktuell. Bei Apple zusaetzlich eine abgeschlossene TestFlight-Phase mit echten Testpersonen und ausgefuellte App Privacy Labels. Bei Google ein durchlaufener Weg von Internal ueber Closed Testing bis zur Production, mit einem Rollout-Start bei 20 Prozent statt sofort 100 Prozent.
Und vor dem eigentlichen Go-Live lohnt sich der Blick auf Backend-Monitoring, einen definierten Support-Kanal, aktives Crash-Reporting und die Frage, wer im Bereitschaftsdienst ist, wenn kurz nach Release etwas brennt.
Checkliste: App-ID, Bundle-ID und Versionen korrekt, Screenshots fuer alle Groessen, Privacy Labels vollstaendig, interner Track vollstaendig getestet, Release Notes fertig, Crash-Reporting aktiv, Staged Rollout geplant, Support-Kanal fuer Tag eins definiert.
Was bei der Erstsubmission besonders oft uebersehen wird
Neben den offensichtlichen Punkten gibt es kleinere Details, die trotzdem zu Ablehnungen fuehren: ein Support-Link in den Metadaten, der auf eine leere Seite zeigt, App-Icons in falscher Aufloesung fuer bestimmte Geraeteklassen, oder Screenshots, die eine Funktion zeigen, die im finalen Build noch nicht enthalten ist. Auch Testzugaenge fuer Reviewer werden gerne vergessen, wenn die App einen Login erfordert, braucht Apple einen funktionierenden Demo-Account, sonst wird die Pruefung direkt abgebrochen. Eine kurze interne Checkliste, die genau diese Kleinigkeiten vor jeder Einreichung abfragt, spart im Schnitt einen kompletten Review-Zyklus.
Euer erster Release oder ein kritisches Update? markom.digital begleitet Store Releases von der Submission bis zum Go-Live, ohne Zittern um 23 Uhr.
