Wie Apple meine App dreimal abgelehnt hat, weil sie zu türkisch war

Die erste Ablehnungsmail kam um 03:14 Uhr. Wir hatten uns auf einen Launch am nächsten Morgen vorbereitet. Der Reviewer schrieb in drei Sätzen, dass er ein UI-Verhalten nicht verifizieren könne, weil die Sprache "nicht Englisch" sei. Wir waren eine türkischsprachige Shopping-App für türkische Kund:innen. Die Sprache sollte tatsächlich Türkisch sein. Die Ablehnung kam mit Code 4.0, Design — Spam.

Ich las die Mail zweimal. Dann ging ich in die Küche, kochte Kaffee und las sie ein drittes Mal. Um 04:00 Uhr stand eine Zeile in meinem Notizbuch: "Sie halten Türkisch für Spam." Ich unterstrich es. Es steht immer noch dort.

Das ist die Geschichte, wie die iOS-App von Stork von dieser 03:14-Mail elf Tage später zu einer sauberen Freigabe kam. Drei Ablehnungen. Drei Lösungen. Eine Lektion, die ich vor dem Prozess nicht erwartet hätte.

Der Merchant-Pilot-Kontext

Stork ist eine türkische Shopping- und Sendungsverfolgungs-App. Als wir sie im App Store einreichten, hatten wir 6 zahlende Merchants im Pilot und etwa 1.800 aktive Beta-Tester auf TestFlight. Alles in der App ist auf Türkisch, weil jede:r, der die App nutzt, Türkisch liest. Der TestFlight-Build war seit drei Wochen stabil. Interne Builds länger. Wir improvisierten nicht.

Das Submission-Paket enthielt einen türkischen Demo-Account, türkische Screenshots und eine einabsatzige Review-Notiz, die erklärte, dass der Zielmarkt der App die Türkei ist. Ich nahm an, das reiche. Ich lag falsch.

Ablehnung 1 — 4.0 Design, Spam

Der Reviewer schrieb, er könne den "In den Warenkorb"-Flow nicht verifizieren, weil die In-App-Texte nicht auf Englisch waren. Der Satz, der hängenblieb: "Bitte stellen Sie einen Build mit englischsprachigem UI oder eine Video-Demonstration mit englischer Erzählung bereit."

Ich möchte hier vorsichtig sein. Ich glaube nicht, dass Apple eine Voreingenommenheit gegen türkische Apps hat. Was meiner Meinung nach passiert ist — und was ich jedem erklären würde, der das durchmacht: Die Standardannahme eines Reviewers ist English-first. Wenn ein Reviewer das UI nicht lesen kann, fällt er auf "Ich kann das nicht verifizieren" zurück, und der nächstliegende Ablehnungseimer ist 4.0. Es ist nicht persönlich. Es ist ein Prozessfehler auf unserer Seite: Wir haben dem Reviewer keinen Weg gegeben, die App in einer Sprache zu bewerten, die er liest.

Lösung 1 — das Erzählvideo

Ich verbrachte den nächsten Nachmittag damit, eine sechsminütige Bildschirmaufnahme der App anzufertigen und jeden Bildschirm auf Englisch zu kommentieren. "Das ist der Home-Tab. Das türkische Wort ist Anasayfa. Das Tippen auf eine Produktkarte öffnet den Produkt-Detail-Bildschirm." Ich schickte es als Resolution-Center-Anhang.

Zwei Dinge, die ich daraus gelernt habe:

1. Das Video muss nicht poliert sein. Meines hatte in der vierten Minute einen bellenden Hund im Hintergrund. Es wurde akzeptiert.
2. Der Reviewer braucht keinen übersetzten Build. Er braucht einen Weg, dem Flow zu folgen. Eine kommentierte Bildschirmaufnahme reicht.

Die Freigabe ging am selben Tag um 19:40 Uhr in die nächste Review-Queue.

Ablehnung 2 — 5.1 Privacy

Diese kam zwei Tage später, zu einer menschlicheren Zeit, um 11:20 Uhr. Der Reviewer schrieb, wir würden während des Onboardings eine Telefonnummer erheben und unsere Datenschutzerklärung würde diese Erhebung nicht rechtfertigen. Die eingereichte Erklärung listete Telefonnummern unter einer einzigen Kategorie auf: "Marketing".

Hier ist das Problem. Stork erhebt Telefonnummern aus drei Gründen, nicht einem:

• OTP-Verifikation beim Login (Sicherheit)
• Sendungsbenachrichtigungen bei Statusänderungen (App-Funktionalität)
• Support-Rückrufe, wenn der Merchant den Kunden erreichen muss (Kundensupport)

Ich hatte das Privacy-Manifest in Eile während der Einreichung ausgefüllt und alle drei unter "Marketing" zusammengeworfen, weil das Formular so kürzer war. Es war nicht akkurat. Es war kaum wahr. Der Reviewer hatte recht.

// PrivacyInfo.xcprivacy — vorher (ein Bucket, falsch)
{
  "NSPrivacyCollectedDataTypes": [
    {
      "NSPrivacyCollectedDataType": "NSPrivacyCollectedDataTypePhoneNumber",
      "NSPrivacyCollectedDataTypeLinked": true,
      "NSPrivacyCollectedDataTypeTracking": false,
      "NSPrivacyCollectedDataTypePurposes": [
        "NSPrivacyCollectedDataTypePurposeProductPersonalization"
      ]
    }
  ]
}

// PrivacyInfo.xcprivacy — nachher (drei Disclosures)
{
  "NSPrivacyCollectedDataTypes": [
    {
      "NSPrivacyCollectedDataType": "NSPrivacyCollectedDataTypePhoneNumber",
      "NSPrivacyCollectedDataTypeLinked": true,
      "NSPrivacyCollectedDataTypeTracking": false,
      "NSPrivacyCollectedDataTypePurposes": [
        "NSPrivacyCollectedDataTypePurposeAppFunctionality",
        "NSPrivacyCollectedDataTypePurposeAnalytics",
        "NSPrivacyCollectedDataTypePurposeCustomerSupport"
      ]
    }
  ]
}

Lösung 2 — drei Disclosures, nicht eine

Ich schrieb das Privacy-Manifest neu, sodass es drei separate Zwecke für denselben Datentyp erklärte. Außerdem aktualisierte ich die App-Privacy-Details in App Store Connect entsprechend — diesen Teil vergisst man leicht, und der Reviewer vergleicht beide.

Die Lehre, zu der ich immer wieder zurückkehre: Privacy-Manifeste sollten geschrieben werden, bevor das Produkt gebaut wird, nicht danach. Wir beschrieben Daten, die wir bereits hatten, in der Sprache des Formulars. Wir hätten vom Formular ausgehen und fragen müssen, was wir erheben dürfen.

Erneut eingereicht am Tag sechs. Freigabe ging um 22:08 in die nächste Queue.

Ablehnung 3 — 2.5.4 Background Modes

Tag acht. Der Reviewer schrieb, wir hätten location in unseren UIBackgroundModes deklariert und er könne keinen "klaren und sinnvollen Nutzervorteil" dafür sehen. Der exakte Satz: "Die In-App-Benachrichtigungen funktionieren auch ohne."

Ich las das, öffnete das Projekt und merkte, dass der Reviewer recht hatte. Wir hatten Background-Location aus einem früheren Feature-Plan geerbt — Live-Sendungsverfolgung auf einer Karte — den wir sechs Wochen zuvor still zu Push-Benachrichtigungen reduziert hatten. Der Info.plist-Eintrag war nie entfernt worden. Die App fragte nach einer Berechtigung, die sie nicht nutzte.

<!-- Info.plist — vorher -->
<key>UIBackgroundModes</key>
<array>
    <string>fetch</string>
    <string>remote-notification</string>
    <string>location</string>
</array>

<!-- Info.plist — nachher -->
<key>UIBackgroundModes</key>
<array>
    <string>fetch</string>
    <string>remote-notification</string>
</array>

Lösung 3 — die Berechtigung entfernen

Ich löschte den location-Eintrag, löschte die ungenutzte CLLocationManager-Initialisierung und suchte nach weiteren toten Berechtigungs-Deklarationen. Ich fand eine: NSCalendarsUsageDescription, aus einem Feature, das wir nie ausgeliefert hatten. Das flog auch raus.

Eingereicht an Tag neun. Genehmigt an Tag elf, 14:46 Ortszeit.

Was ich nicht erwartet hatte

Apples dritte Resolution-Center-Nachricht — die Freigabe-Benachrichtigung — begann mit "Sevgili Geliştirici." Liebe Entwickler:in, auf Türkisch.

Ich weiß nicht, ob ein Mensch oder ein Skript das geschrieben hat. Es spielt eigentlich keine Rolle. Es war der höflichste Satz, den ich in elf Tagen von Apple gesehen hatte.

Was ich jedem mitgeben würde

Ein paar konkrete Dinge, in keiner Reihenfolge:

• Gib dem Reviewer einen Pfad durch dein UI. Eine kommentierte Bildschirmaufnahme ist schneller als die Übersetzung des Builds und funktioniert für jede Sprache.
• Schreib das Privacy-Manifest vor dem Produkt, nicht danach. Drei Zwecke in einen Eimer zu werfen, weil das Formular dann kürzer ist, ist eine kleine Lüge, für die du mit einer Ablehnungsmail bezahlst.
• Auditiere deine Info.plist vor jeder Einreichung. Tote Berechtigungen sind ein wartendes 2.5.4. Besonders Background-Modes — Apple sucht aktiv nach ungerechtfertigten.
• Elf Tage sind keine Katastrophe. Zwei der drei Ablehnungen wurden in unter einem Tag gedreht. Der Flaschenhals war immer die Review-Queue, nicht der Fix.

Der kontraintuitive Teil, den ich nicht vorausgesehen hätte: Der Reviewer war nicht das Hindernis. Der Reviewer las unsere Einreichung sorgfältig, in der Sprache, die wir ihm gaben. Das Hindernis war, dass wir unser Produkt weniger ehrlich beschrieben hatten, als wir es gebaut hatten. Jede Ablehnung war Apple, das eine Lücke zwischen unseren Worten und unseren Taten fand.

Wir launchten an Tag zwölf. Am nächsten Morgen schickte uns der erste Merchant, der über iOS onboardet wurde, einen Screenshot des Home-Bildschirms mit der Bildunterschrift "yayında mıyız?" — sind wir live?. Wir waren live.