Die App ist fertig, getestet, das Team will live. Dann steht zwischen Build und Nutzer noch ein Schritt, den viele unterschätzen: die Veröffentlichung. Sie ist kein Knopfdruck, sondern zwei getrennte Hürden. Erst muss die App durch das App Store Review von Apple und die Prüfung von Google Play, ohne abgelehnt zu werden. Und danach muss sie überhaupt gefunden werden, was über App Store Optimization (ASO) läuft.
Dieser Beitrag behandelt beide Hürden in der Reihenfolge, in der sie auftreten: zuerst, wie du eine Ablehnung beim Review vermeidest, dann die ASO-Grundlagen für die Sichtbarkeit danach. Nicht behandelt werden hier die Marketing-Kampagne nach dem Launch und die Detailtiefe der einzelnen Plattform-SDKs. Der Fokus liegt auf dem Einreichungs- und Auffindbarkeitsprozess selbst.
Was beim Review tatsächlich passiert
Beide Stores prüfen jede Einreichung, bevor sie öffentlich wird. Apple prüft stärker manuell, Google stärker automatisiert, beide inzwischen mit KI-gestützten Prüfschritten. Das ist kein Formalakt. Apples eigener App-Store-Transparenzbericht für 2024 weist rund 7,8 Millionen geprüfte Einreichungen aus, davon etwa 1,9 Millionen abgelehnt. Das ist grob ein Viertel. Die meisten dieser Ablehnungen sind vermeidbar, weil sie auf eine überschaubare Zahl wiederkehrender Gründe zurückgehen.
Zur Erwartungssteuerung gehören auch die Zeiten. Apples Review dauerte 2023/24 im Schnitt rund 24 Stunden. 2026 ist die Spanne durch eine stark gestiegene Zahl an Einreichungen breiter geworden: aktuelle Auswertungen nennen typischerweise 24 bis 72 Stunden für neue Apps, in Einzelfällen mehrere Tage. Updates laufen meist schneller durch als Erst-Einreichungen. Plane die Veröffentlichung also nicht auf den Tag genau, an dem die Pressemeldung rausgeht.
Google Play prüft technisch ähnlich, hat aber für neue Entwicklerkonten eine zusätzliche Hürde, die häufig überrascht: Wer sein Konto als Privatperson nach dem 13. November 2023 angelegt hat, muss vor der Produktionsveröffentlichung einen geschlossenen Test mit mindestens 12 Testern über 14 zusammenhängende Tage durchführen. Diese Zahl lag ursprünglich bei 20 und wurde am 11. Dezember 2024 auf 12 gesenkt. Für Organisationskonten gilt die Regel nicht, ein guter Grund, ein Unternehmen nicht über ein privates Konto zu veröffentlichen. Wichtig für die Planung: Diese 14 Tage sind eine harte Vorlaufzeit. Sie lässt sich nicht beschleunigen, und ohne sie kommt die App gar nicht erst in den Produktions-Track. Wer den Test nicht rechtzeitig vor dem Wunschtermin startet, verschiebt den Launch.
Die häufigsten Ablehnungsgründe (und wie du sie vermeidest)
Apple ordnet Ablehnungen seinen App Review Guidelines zu. Vier davon decken den Großteil der Fälle ab.
App-Vollständigkeit: kein Absturz, kein Platzhalter, ein Demo-Zugang
Der mit Abstand häufigste Ablehnungsgrund, von Apple unter Guideline 2.1 geführt. Die App stürzt ab, eine Kernfunktion ist kaputt, ein Feature ist sichtbar unfertig, oder Platzhalter-Inhalte wie „Lorem ipsum" und Test-Bilder sind noch drin. Dazu kommt eine Falle, die banal klingt und trotzdem zuverlässig zur Ablehnung führt: Wenn die App ein Login erfordert, muss ein funktionierender Demo-Account in den Review-Notizen hinterlegt sein. Fehlt er, steht der Prüfer vor einem Login-Screen, kommt nicht hinein und lehnt ab, ohne den Rest der App je gesehen zu haben. Deshalb vor der Einreichung auf einem echten, frisch installierten Gerät durchklicken, nicht nur im Simulator, und die Zugangsdaten ins Feld „App Review Information" eintragen.
Korrekte Metadaten: Screenshots zeigen die echte App
Screenshots, Vorschau-Video und Beschreibung müssen den tatsächlichen Stand der App zeigen (Guideline 2.3). Abgelehnt wird, wenn die Screenshots Funktionen versprechen, die es in der App nicht oder nicht mehr gibt, oder wenn das Vorschaumaterial aus einer älteren Version stammt. Das klingt trivial, ist aber ein Dauerbrenner, weil die Store-Assets oft früh erstellt und bis zum Launch nicht aktualisiert werden. Die Reihenfolge muss stimmen: Die Screenshots entstehen aus dem Build, der eingereicht wird, nicht umgekehrt.
Mehr als eine Website: das Minimalfunktions-Problem
Eine App, die im Kern nur eine Website in einem Rahmen anzeigt, ein sogenannter „Webview-Wrapper" ohne nennenswerte native Funktion, wird unter Guideline 4.3 abgelehnt. Apple erwartet einen eigenständigen Mehrwert gegenüber der mobilen Website: Push-Benachrichtigungen, Offline-Fähigkeit, Gerätefunktionen wie Kamera oder Standort, eine native Navigation. Wer hier unsicher ist, sollte den Funktionsumfang vor dem ersten Build mit der App-Entwicklung abklären, statt nach der Ablehnung umzubauen. Die Technologiewahl entscheidet das früh mit: Plattformübergreifende Frameworks wie React Native oder Flutter erzeugen echte native Komponenten, ein simpler Webcontainer nicht.
Datenschutz: Labels, Manifest, Einwilligung
Der Bereich, der 2024 bis 2026 am stärksten verschärft wurde (Guideline 5.1). Drei Dinge müssen stimmen:
- Die App-Datenschutzangaben („Privacy Labels") im Store müssen ehrlich und vollständig auflisten, welche Daten erhoben und wie sie genutzt werden.
- Eine erreichbare Datenschutzerklärung als URL ist Pflicht, bei beiden Stores.
- Seit dem 1. Mai 2024 verlangt Apple ein Privacy Manifest (
PrivacyInfo.xcprivacy). Es deklariert die Nutzung bestimmter „Required Reason APIs" und gilt auch für eingebundene Dritt-SDKs. Fehlt es, ist das keine Ablehnung im Review, sondern ein harter Stopp davor: App Store Connect weist die Einreichung schon beim Upload ab. Du kommst gar nicht erst in die Prüfung.
Wer Tracking oder personalisierte Werbung einsetzt, braucht zusätzlich das Einwilligungs-Framework App Tracking Transparency (ATT) von Apple. Daten an Dritte, etwa an KI-Dienste, ohne klare Offenlegung und Einwilligung weiterzugeben, ist ein zuverlässiger Ablehnungsgrund.
Ein fünfter, seltenerer Prüfpunkt sind die Human Interface Guidelines: Eine App, die sich nicht an die Plattform-Konventionen hält, auf großen oder kleinen Displays bricht oder eine unklare Navigation hat, wird im Design-Kapitel beanstandet. Das passiert seltener als bei den vier Punkten oben, aber regelmäßig genug, um es im Blick zu behalten.
Google Play: die eigenen Pflichtfelder
Google lehnt seltener wegen Minimalfunktion ab, prüft aber Pflichtangaben streng. Vor der Veröffentlichung müssen vorliegen:
- Das Data-Safety-Formular, die Google-Entsprechung zu Apples Privacy Labels. Es ist für jede veröffentlichte App Pflicht, also für den geschlossenen, offenen und Produktions-Track; nur reine interne Test-Tracks sind ausgenommen. Die Angaben müssen mit dem tatsächlichen Datenverhalten der App übereinstimmen.
- Eine Datenschutzerklärung als URL.
- Das Content-Rating über den Fragebogen und eine Zielgruppen-Deklaration zur Altersgruppe, die strenger geprüft wird, sobald Kinder zur Zielgruppe gehören.
Ein verstecktes Keyword-Feld wie bei Apple gibt es nicht; warum das für die Sichtbarkeit zählt, steht gleich im ASO-Teil. Greift zusätzlich die oben beschriebene 12-Tester-Regel, ist die Veröffentlichung kein Tagesgeschäft, sondern ein Zwei-Wochen-Vorlauf.
Pre-Submit-Checkliste
Eine kurze Liste, die sich vor jeder Einreichung lohnt, bewusst knapp gehalten:
- Auf einem echten Gerät frisch installiert durchgeklickt, kein Absturz, keine kaputte Kernfunktion.
- Demo-Zugang (falls Login nötig) in den Review-Notizen hinterlegt.
- Screenshots und Vorschau stammen aus dem eingereichten Build.
- Datenschutzerklärung-URL erreichbar; Privacy Labels und Data-Safety-Formular ausgefüllt und korrekt.
- Privacy Manifest vorhanden (iOS), Dritt-SDKs geprüft.
- Nativer Mehrwert über eine reine Website hinaus ist erkennbar.
- Bei neuem Google-Privatkonto: Der 12-Tester-Test läuft seit mindestens 14 Tagen.
ASO-Basics: nach dem Review kommt das Gefundenwerden
Eine veröffentlichte App ist noch keine sichtbare App. ASO ist die Arbeit daran, in den Stores für die richtigen Suchanfragen aufzutauchen und Besucher der Produktseite zur Installation zu bewegen. Es zerfällt in zwei Aufgaben.
Sichtbarkeit entscheidet, für welche Suchbegriffe die App erscheint. Hier zählen die Metadatenfelder. Die wichtigsten und am stärksten gewichteten sind Titel und Untertitel: Der Titel kombiniert den Markennamen mit ein, zwei starken Keywords, der Untertitel transportiert den Nutzen plus weitere Begriffe. Apple bietet zusätzlich ein verstecktes Keyword-Feld mit 100 Zeichen in App Store Connect, das nicht für Nutzer sichtbar, aber suchrelevant ist. Eine Eigenheit, die Anfänger oft übersehen: Apple zählt jedes Keyword nur einmal. Begriffe zwischen Titel, Untertitel und Keyword-Feld zu doppeln, verschenkt also Platz; besser verteilen. Bei Google Play gibt es dieses Feld nicht. Stattdessen indexiert Google den sichtbaren Beschreibungstext, weshalb dort die relevanten Begriffe natürlich in die Beschreibung gehören. Sinnvoll ist ein Kernset von etwa 20 bis 40 Keywords, die die App stabil bedienen soll, mit Schwerpunkt auf spezifischeren Long-Tail-Anfragen, die weniger umkämpft sind.
Conversion ist die zweite Aufgabe: Wer auf der Produktseite landet, entscheidet in Sekunden. Das leisten Icon, Screenshots, Vorschau-Video und die Bewertungen. Die ersten drei Screenshots tragen den Großteil der Last, weil sie direkt in den Suchergebnissen erscheinen. Sie sollten den Kernnutzen zeigen, nicht eine Feature-Tour von vorne beginnen. Bewertungen und ihre Menge wirken doppelt: als Vertrauenssignal für den Nutzer und als Ranking-Faktor für den Store.
ASO ist kein Einmal-Setup. Die Felder werden mit jeder Version nachgeschärft, Keywords getestet, Screenshots gegen Varianten gemessen. Für den Start reicht aber die Disziplin, Titel, Untertitel und die ersten drei Screenshots bewusst zu setzen, statt sie als Pflichtfelder abzuhaken.
Einordnung
Zurück zum Team, das live wollte. Zwischen „fertig" und „live" steht kein Knopfdruck, sondern zwei fremde Regelwerke, die sich zudem regelmäßig ändern. Die Ablehnungsgründe sind überschaubar und vermeidbar, wenn du sie vor dem ersten Upload kennst; die Sichtbarkeit ist Handwerk, kein Zufall. Wer einmalig eine einzelne App veröffentlicht, arbeitet die Checkliste ab. Wer regelmäßig veröffentlicht oder mehrere Apps pflegt, baut den Review- und ASO-Schritt fest in den Release-Prozess ein, am besten so früh, dass schon die Technologiewahl die spätere Freigabe stützt statt sie zu gefährden. Wenn diese Entscheidung noch offen ist, lohnt der Vergleich der Cross-Platform-Frameworks vor dem ersten Build, denn ob am Ende echte native Komponenten oder nur ein Webcontainer entstehen, klärt sich genau dort.
