Die App fürs Review vorbereiten: Checkliste vor dem Absenden

Was ein App-Review ist - einfach erklärt

Die App steht. Läuft auf deinem Handy, Freunde haben rumgetippt - sieht stark aus. Bleibt nur noch eine Kleinigkeit: ab in den Store. Nur steht zwischen dir und dem „Installieren“-Button für Millionen Menschen noch das Review Review - die Prüfung deiner App durch den Store vor der Veröffentlichung. Ein Zusammenspiel aus automatischen Tests und einem echten Prüfer, der die App öffnet und schaut, ob alles so funktioniert, wie du es in der Beschreibung versprochen hast. - die Prüfung.

Merk dir eine Sache: Deine App öffnet ein echter Mensch. Den Code liest er nicht, und auf dein Wort verlässt er sich auch nicht - er nimmt den Build, geht rein, drückt Buttons und gleicht ab: Funktioniert das, was in der Beschreibung versprochen ist, wirklich oder nur auf dem Papier? Stolpert er unterwegs - kommt nicht rein, landet auf einem leeren Screen, sieht eine Kamera-Abfrage ohne erkennbaren Grund - dann macht er sich nicht die Mühe, das zu ergründen. Er schickt den Build einfach zurück.

Deshalb hat die Review-Vorbereitung mit Code überhaupt nichts zu tun. Es geht darum, dem Prüfer vorab alle Hindernisse aus dem Weg zu räumen. Ein Durchgang durch eine kurze Liste - und die Chance, beim ersten Versuch durchzukommen, steigt enorm.

Warum du dich frühzeitig aufs Review vorbereiten solltest

Eine Ablehnung ist keine Katastrophe. Aber sie kostet dich ein paar Tage und eine Portion Nerven ganz ohne Not. Und bei einem Vibecoder, der die App schnell zusammengebaut hat, lauern besonders viele Fallen: Generierter Code lässt liebend gern Platzhalter zurück und zieht überflüssige Berechtigungen „für alle Fälle“ mit.

• Du sparst Tage: Eine Ablehnung wirft den Release zurück in eine neue Runde Warteschlange und Prüfung.
• Du musst nicht mehr rätseln, „warum sie abgelehnt haben“ - die meisten Ablehnungen haben dieselben Gründe, und die hakst du vorab ab.
• Du blamierst dich nicht aus dem Nichts: überflüssige Berechtigungen und tote Buttons fallen den Stores im Handumdrehen auf.
• Du startest entspannt und nicht im Modus „die Deadline brennt, aber das Review hängt fest“.

Die meisten Ablehnungen bei Anfängern sind kein „schlechter Code“. Es sind ein nicht funktionierender Demo-Account, Platzhalter statt Features und Metadaten, die nicht zur App passen. All das lässt sich mit einer einzigen Checkliste vor dem Absenden erledigen.

Checkliste, bevor du die App zur Prüfung schickst

Geh diese Punkte durch, bevor du auf „Absenden“ drückst. Die Reihenfolge geht vom häufigsten Fehler zu den weniger offensichtlichen.

1. Demo-Account für den Prüfer

Gibt es einen Login? Dann braucht der Prüfer einen Weg, reinzukommen. Selbst registrieren wird er sich nicht, auf eine SMS warten auch nicht, und ein Captcha lösen schon gar nicht. Gib ihm einen fertigen Demo-Account Demo-Account - ein vorab angelegter Test-Login mit Passwort und Vollzugriff auf alle Funktionen. Damit der Prüfer reinkommt und alles sieht, ohne sich selbst registrieren zu müssen. mit Vollzugriff auf alle bezahlten und gesperrten Bereiche.

• Login und Passwort trägst du in das spezielle Feld für den Prüfer ein (im App Store ist das die App Review Information, in Google Play der Zugang für den Rezensenten).
• Der Account muss bis zum Ende der Prüfung leben - lösch ihn nicht und setz das Passwort nicht zurück, solange der Build im Review ist.
• Wenn der Login über einen Drittanbieter (Google, Apple) die Prüfung erschwert, richte einen separaten, einfachen Login mit Benutzername und Passwort speziell fürs Review ein.

2. Funktionierende Features ohne Platzhalter und leere Screens

Halbfertiges mögen die Stores nicht. Gibt es einen Button im Interface, muss er auch etwas tun. Aufschriften wie „Demnächst“ und „In Arbeit“, leere Tabs, Blindtext-Screens (Platzhaltertext, graue Quadrate statt Bilder) - ein häufiger Grund, einen Build abzulehnen.

3. Nur nötige Berechtigungen mit klarer Erklärung

Eine Berechtigung Berechtigung (permission) - die Anfrage auf Zugriff auf sensible Daten oder Funktionen des Handys: Kamera, Mikrofon, Standort, Kontakte, Benachrichtigungen. Der Nutzer bestätigt jede einzeln von Hand. ist der Zugriff auf Kamera, Standort, Mikrofon, Kontakte. Die Regel ist kurz: Frage nur das ab, was du wirklich nutzt, und erkläre wofür - in verständlicher Sprache.

• Nutzt du die Kamera nicht, entfern die Kamera-Berechtigung. Zugriff ohne erkennbaren Grund ist ein Warnsignal für den Prüfer.
• Für jeden sensiblen Zugriff brauchst du einen echten Erklärtext: zum Beispiel „die Kamera wird gebraucht, um Kassenbons zu scannen“, keine leere Zeile.
• Vibecoder verraten sich hier am häufigsten: Die generierte Vorlage zieht einen Haufen Berechtigungen auf Vorrat mit. Geh die Liste durch und räum alles Überflüssige raus.

4. Ehrliche Metadaten: Beschreibung, Screenshots, Datenschutz

Metadaten Metadaten - alles, was die App im Store vor der Installation beschreibt: Name, Beschreibung, Icon, Screenshots, Kategorie, Link zur Datenschutzerklärung, Angaben zu den erhobenen Daten. Das sieht und liest der Prüfer und der künftige Nutzer. sind dein Schaufenster. Der Prüfer gleicht nur eines ab: Passt das, was außen steht, zu dem, was innen ist?

• Name, Beschreibung, Kategorie - ehrlich, ohne Trickserei und ohne fremde Marken.
• Screenshots - aus der echten App, keine gemalten Mockups mit Versprechen.
• Datenschutzerklärung - ein funktionierender Link, der sich öffnet und nicht auf eine leere Seite führt.
• Angaben zu den Daten - was du erhebst und wofür (im App Store ist das App Privacy, in Google Play der Bereich Data safety). Die Stores gleichen das ab und bestrafen Abweichungen.

5. Release-Build, kein Debug-Build

Und zum Schluss: Zur Prüfung geht ein Release-Build, kein Debug-Build. Der Release-Build Release-Build - der finale Build für die Veröffentlichung: optimiert, mit einem Zertifikat signiert, ohne Debug-Werkzeuge und Logs. Das Gegenstück zum Debug-Build, den du während der Entwicklung laufen lässt. unterscheidet sich vom Debug-Build: Er ist optimiert, signiert, ohne Debug-Logs und Test-Server.

• Du baust genau die Release-Version (bei Android ist das meist ein signiertes AAB, bei iOS ein Archiv für den App Store).
• Version und Build-Nummer sind gegenüber der letzten hochgezählt - der Store nimmt dieselbe Nummer kein zweites Mal an.
• Die App zeigt auf den Produktivserver, nicht auf localhost oder eine Test-Umgebung, an die der Prüfer nicht herankommt.
• Debug-Banner, Test-Buttons und Konsolen-Logs sind ausgeschaltet.

Beispiel: ein Durchgang durch die Checkliste mit den Augen des Prüfers

Mach das mit einem frischen Gerät oder als anderer Nutzer. So siehst du die App mit den Augen des Prüfers und nicht „mit deinen eigenen, wo alles längst eingeloggt und jede Berechtigung erteilt ist“.

Leg einen Demo-Account an oder prüfe ihn. Melde dich damit von einem frischen Gerät an - ohne Captcha, ohne SMS, ohne E-Mail-Bestätigung. Alle bezahlten und gesperrten Bereiche haben sich geöffnet.
Trag Login und Passwort des Demo-Accounts in das Prüfer-Feld in der Store-Konsole ein. Füge eine kurze Notiz hinzu, wie man die App benutzt, falls etwas nicht offensichtlich ist.
Geh alle Buttons und Tabs durch. Kein einziger Platzhalter, kein „Demnächst“, kein leerer Screen und kein Blindtext.
Öffne die Liste der Berechtigungen. Lass nur die übrig, die wirklich funktionieren, und prüfe, dass jede eine verständliche Erklärung hat, wofür sie da ist.
Gleiche die Metadaten ab: Name, Beschreibung, Screenshots aus der echten App, ein funktionierender Link zur Datenschutzerklärung, der ausgefüllte Bereich zu den erhobenen Daten.
Bau den Release-Build. Zähl die Versionsnummer hoch, prüfe, dass die App auf den Produktivserver zeigt und nicht auf den Test-Server, und dass die Debug-Logs aus sind.
Lad den Build hoch, geh die Felder noch einmal durch und drück „Zur Prüfung absenden“. Zeitpuffer ist eingeplant - du releast nicht am Tag der Deadline.

Und noch ein kleiner Schritt, den viele überspringen - die Notiz für den Prüfer. In demselben Feld, in das du den Login einträgst, gibt es Platz für freien Text. Wenn sich in der App ein nicht offensichtlicher Ablauf versteckt (tippe hier, dann dort), spart ein paar Zeilen Hinweis dem Prüfer eine Minute und nimmt ihm jeden Anlass zum Meckern. Hier ist ein Gerüst - einfügen und an dich anpassen.

Demo-Account:
Login: demo@example.com
Passwort: dein-passwort
Login: App öffnen, Login und Passwort von diesem Screen eingeben. Kein Captcha, keine SMS.
So siehst du die bezahlten Funktionen: Bereich „Abo“ öffnen - unter diesem Account ist bereits alles freigeschaltet.
Hauptablauf: einen Eintrag auf dem Startbildschirm anlegen, dann öffnen und „Export“ drücken.
Kontakt bei Fragen: deine-email

Häufige Anfängerfehler beim Absenden zum Review

• Kein Demo-Account oder er funktioniert nicht. Die häufigste Ablehnung. Gib einen funktionierenden Login mit Passwort und Vollzugriff und prüfe den Login selbst mit einem frischen Gerät.
• Login mit Captcha oder SMS. Der Prüfer bekommt keinen Code auf deine Nummer. Richte fürs Review einen separaten, einfachen Login ein.
• Platzhalter und „Demnächst“-Buttons. Ein Feature ist nicht fertig - nimm es aus dem Interface, statt einen leeren Button stehenzulassen.
• Überflüssige Berechtigungen auf Vorrat. Die generierte Vorlage zieht Zugriff auf Kamera und Standort ohne Grund mit. Räum alles raus, was du nicht nutzt.
• Metadaten passen nicht zur App. Hast du in der Beschreibung etwas versprochen, das es innen nicht gibt - ein Ablehnungsgrund. Gleiche Schaufenster und Realität ab.
• Du hast einen Debug-Build geschickt. Test-Server, Debug-Logs, dieselbe Versionsnummer - der Store winkt das ab. Bau einen signierten Release-Build und zähl die Version hoch.
• Release auf den letzten Drücker. Review-Zeiten sind unberechenbar. Eine Ablehnung - und du bist zu spät dran. Plane immer einen Puffer ein.