Die Ablehnung vor der von Apple

Was es ist und warum es zählt

Du schickst die App zur Prüfung, wartest, und sie kommt zurück. Die Anmeldung mit Apple fehlt, oder das Konto lässt sich nicht löschen, oder der Satz, der erklärt, warum du die Kamera brauchst, ist zu vage. Jede Runde kostet Tage, und oft stand der Grund schon in deinen Dateien.

Greenlight ist ein Terminalprogramm, das diese Prüfung vor dir macht. Es liest den Code, die Konfigurationsdateien und, wenn du sie ihm gibst, die fertig gebaute App. Dann vergleicht es alles mit Apples Prüfregeln und den Richtlinien von Google Play. Jedes Problem hat eine Schwerestufe und nennt die Regel, aus der es kommt. Die Grundprüfung braucht kein Konto, lädt nichts hoch und geht nicht ins Netz. Es kommt von Revyl, einer Firma für App-Tests, und der Code liegt offen auf GitHub unter MIT-Lizenz: Du nutzt es kostenlos.

Es ist für alle, die allein veröffentlichen, ohne ein Team, das bei jedem Release Apples Regeln nachliest. Eins gleich vorweg: Es ist eine Liste von Dingen zum Anschauen, kein Genehmigungsstempel. Es liest die Dateien, es benutzt die App nicht. In Abschnitt 6 steht, was es nicht sieht.

1. Was es prüft

Der Hauptbefehl heißt preflight, wie der Check vor dem Start. Er startet fünf Prüfungen auf einmal, die in der Dokumentation Scanner heißen:

• metadata: Name, Version, Format der Bundle-ID (die Kennung der App), Icon, Link zur Datenschutzerklärung und die Sätze, die erklären, warum du eine Berechtigung brauchst. Es liest sie in Info.plist oder, bei Expo-Apps, in app.json.
• codescan: 24 Regeln für Code in Swift, Objective-C, React Native und Expo. Zum Beispiel geheime Schlüssel im Code, Google-Login ohne Anmeldung mit Apple, Konten, die man anlegen, aber nicht löschen kann.
• privacy: Ist das Datenschutz-Manifest, das Apple verlangt (PrivacyInfo.xcprivacy), da und vollständig? Und wenn du Tracking-SDKs nutzt, gibt es das ATT-Pop-up, das um Erlaubnis zum Tracking bittet?
• playscan: nur für Android-Projekte. Die Regeln von Google Play: das Android-API-Level, auf das du zielen musst, und seine Fristen, Berechtigungen, die ein Erklärungsformular brauchen, Vordergrunddienste, die Play-Billing-Version für Zahlungen.
• ipa: die fertig gebaute iPhone-App, die .ipa-Datei. Es prüft die Schlüssel in Info.plist, den Startbildschirm, die Icons, die Größe der App und die Datenschutz-Manifeste der eingebundenen Frameworks. Es läuft nur, wenn du ihm die Datei gibst.

Wenn im selben Ordner sowohl der iOS- als auch der Android-Teil liegen, wie bei einer Flutter- oder React-Native-App, prüft es beide in einem Durchgang.

2. Installieren und die erste Prüfung starten

Installiert wird es im Terminal. Auf dem Mac mit Homebrew, dem Programm, das andere Programme über das Terminal installiert. Wenn du stattdessen Go hast, die Sprache, in der Greenlight geschrieben ist, nimm die zweite Zeile.

brew install revylai/tap/greenlight
go install github.com/RevylAI/greenlight/cmd/greenlight@latest

Dann geh in den Hauptordner des Projekts und starte die Prüfung. Der Punkt bedeutet „dieser Ordner“. Das dauert weniger als eine Sekunde.

greenlight preflight .

Wenn du die App schon für den App Store exportiert hast, gib die .ipa-Datei dazu: Dann prüft es auch die gebaute App, nicht nur den Quellcode. Für Android geht das genauso mit --apk oder --aab, der Datei, die du bei Play hochlädst. Setz den Pfad zu deiner Datei statt des Beispiels ein.

greenlight preflight . --ipa build.ipa
greenlight preflight . --aab app-release.aab

3. So liest du das Ergebnis

Jedes gefundene Problem bringt vier Dinge mit: die Schwerestufe, die Regel von Apple oder Google, aus der es kommt, die Datei, in der es gefunden wurde, und einen Vorschlag, wie du es behebst. Es gibt vier Stufen:

• CRITICAL: Die Ablehnung oder eine fehlschlagende Installation ist fast sicher. Vor dem Einreichen beheben.
• HIGH: eine veröffentlichte Frist, eine fehlende Pflichtangabe oder etwas, das kaputtgeht, während die App läuft.
• WARN: Die Prüferin oder der Prüfer wird es wahrscheinlich bemerken und dich um eine Erklärung bitten.
• INFO: gute Praxis. Blockiert nichts.

Ganz unten steht das Urteil: NOT READY, wenn noch mindestens ein CRITICAL übrig ist, NEEDS REVIEW, wenn noch HIGH übrig sind, GREENLIT, wenn keins von beiden mehr da ist. GREENLIT heißt, dass die Prüfung der Dateien bestanden ist, nicht, dass Apple dich freigibt.

4. Lass Claude Code es benutzen

Greenlight gibt es auch als Plugin für Claude Code. Das Plugin ist nicht das Programm: Es ist ein Skill, also ein Blatt mit Anweisungen, das Claude sagt, wie es die Prüfung startet, die Ergebnisse liest, den Code korrigiert und neu prüft. In Claude Code gibst du ein:

/plugin marketplace add RevylAI/greenlight
/plugin install greenlight

Das Plugin installiert das Programm nicht von selbst: Mach das vorher, wie in Schritt 2. Dann öffne Claude Code im Projektordner und füge ein:

Starte greenlight preflight und behebe alles, bis es besteht. Fang mit den CRITICAL an, dann die HIGH. Starte die Prüfung nach jeder Runde Korrekturen neu. Wenn dir ein Fund wie ein Fehlalarm vorkommt, fass den Code nicht an: Hör auf und erklär mir, warum.

Die HIGH habe ich absichtlich dazugeschrieben. Die Anweisungen des Plugins sehen die Arbeit als erledigt an, wenn kein CRITICAL mehr übrig ist. Die HIGH bleiben aber, und genau darunter sind die fehlende Anmeldung mit Apple und das Konto, das sich nicht löschen lässt.

Wenn dir ein Fund nicht klar ist, lass ihn dir erklären, bevor du etwas anfasst:

Erklär mir diesen Fund von Greenlight in einfachen Worten: [Zeile einfügen]. Sag mir, welche Regel von Apple oder Google er nennt, in welcher Datei er gefunden wurde und was dort steht. Dann sag mir, ob es für dich ein echtes Problem oder ein Fehlalarm ist und wie ich das selbst prüfe.

Und wenn klar ist, dass es ein Fehlalarm ist:

Dieser Fund von Greenlight ist ein Fehlalarm: [Zeile einfügen]. Wenn er aus der Code-Prüfung (codescan) kommt, leg .greenlight.yml im Hauptordner an oder ergänze sie: Senk die Schwerestufe dieser Regel oder schließ nur die nötige Datei oder den nötigen Ordner aus, ohne andere Prüfungen abzuschalten. Schreib einen Kommentar mit dem Grund daneben. Wenn er aus einer anderen Prüfung kommt, änder nichts und sag es mir.

5. Fehlalarme und automatische Prüfung

Die Datei .greenlight.yml

Sie gehört in den Hauptordner des Projekts und stellt die Code-Prüfung ein, auch wenn sie innerhalb von preflight läuft. Für jede Regel kannst du die Schwerestufe ändern (info, warn oder critical) oder sie abschalten, und du kannst Ordner, Dateien oder Pfade ausschließen.

rules:
  hardcoded-ipv4:
    severity: info
  platform-reference:
    enabled: false
ignore:
  - vendor
  - "*.generated.ts"

Für eine einzelne Zeile gibt es einen Kommentar, den du in diese Zeile oder die darüber setzt: // greenlight:ignore, gefolgt vom Namen der Regel. Ohne Namen schaltet er alle Regeln in dieser Zeile ab. Schreib ihn lieber dazu, dann bleiben die anderen Prüfungen an.

let host = "10.1.2.3" // greenlight:ignore hardcoded-ipv4

Die Prüfung bei jedem Release

Mit --exit-code endet der Befehl mit einem Fehler, wenn er ein CRITICAL oder ein HIGH findet oder wenn eine der Prüfungen abgestürzt ist: So gilt eine halbe Prüfung nie als bestanden. Pack ihn in deine CI, also die automatischen Prüfungen, die bei jedem Push laufen, zum Beispiel GitHub Actions: Ein Release mit einem schweren Problem stoppt von selbst.

greenlight preflight . --exit-code

6. Was es nicht sieht

Greenlight liest Text, es öffnet die App nie. Wenn im Code ein Button „Konto löschen“ steht, der mit nichts verbunden ist, sieht es das Wort, die Regel ist erfüllt, und Apple lehnt dich trotzdem ab, sobald jemand darauf tippt.

Dann gibt es Fehlalarme. Der klarste Fall ist Issue Nummer 30 auf ihrem GitHub: In Apps ganz ohne Werbung schlägt die Regel für Google-Anzeigen an, weil sie „ads“ in ganz normalen Wörtern wie loadSdk oder downloads findet. Sie meldet ein CRITICAL ohne Datei und schlägt vor, das ATT-Pop-up einzubauen, was in einer App, die nicht trackt, genau das Falsche ist. Schau vor jeder Korrektur nach, was wirklich in deinem Code steht.

Und der Code, den es liest, ist nur Swift, Objective-C, React Native und Expo. Unsere App ist mit Flutter gebaut: Dart-Code liest es nicht, ein Google-Login ohne Apple in Dart fällt ihm also nicht auf. Es liest aber Info.plist, das Datenschutz-Manifest, das Android-Manifest, die Gradle-Dateien und die gebaute App. Bei Flutter gib ihm immer die gebauten Dateien und teste Login und Kontolöschung von Hand.

Zwei optionale Befehle laufen nicht offline: verify probiert einige Abläufe auf einem Telefon in der Cloud aus und braucht ein Revyl-Konto; scan --app-id prüft den Eintrag in App Store Connect und braucht dort eine Anmeldung. Diese Anleitung nutzt sie nicht.

Häufige Fehler

• GREENLIT für eine Freigabe halten. Es heißt, dass in den Dateien nichts Schweres mehr steckt, nicht, dass die App funktioniert.
• Einen Fehlalarm beheben. Bevor du das ATT-Pop-up einbaust oder Code änderst, schau nach, was es wirklich gefunden hat und wo.
• Nur den Quellcode prüfen. Die Berechtigungen, die Bibliotheken hinzufügen, sieht man erst in der gebauten Datei: Gib ihm auch die .ipa, .apk oder .aab.
• Dem grünen Licht bei einer Flutter-App vertrauen. Dart liest es nicht: Login und Kontolöschung testest du selbst, auf dem Telefon.

Checkliste

• Greenlight installiert, in der neuesten Version
• greenlight preflight . im Hauptordner des Projekts gestartet
• Prüfung mit der gebauten Datei wiederholt: .ipa, .apk oder .aab
• Null CRITICAL und null HIGH, oder jeder Fund erklärt
• Jeder Fehlalarm von Hand geprüft und in .greenlight.yml oder mit greenlight:ignore vermerkt
• greenlight preflight . --exit-code in der CI
• Kontolöschung, Käufe wiederherstellen und Anmeldung mit Apple in der echten App getestet

Häufige Fragen