How Apple rejected my app three times for being too Turkish

The first rejection email arrived at 03:14 on April 4, 2026. We were launching the next morning. In three sentences, the reviewer said they could not verify a piece of UI behavior because the language was "not English." We were a Turkish-language shopping app for Turkish customers. Being in Turkish was the whole point. The email came tagged 4.0, Design — Spam.

I read it twice. Then I went to the kitchen, made coffee, and read it a third time. By 04:00 my journal had a single line in it: "they think Turkish is spam." I underlined it. It is still there.

This is the story of how Stork's iOS app went from that 03:14 email to a clean approval eleven days later. Three rejections, three fixes, and one lesson I would not have predicted going in.

The merchant pilot context

Stork is a Turkish shopping and shipment-tracking app. When we submitted to the App Store we had six paying merchants on a pilot and around 1,800 active beta testers on TestFlight. Everything in the app is in Turkish, because everyone using it reads Turkish. The TestFlight build had been stable for three weeks. Internal builds had been stable longer. We were not winging this.

The submission included a Turkish demo account, Turkish screenshots, and a one-paragraph review note explaining that the target market was Türkiye. I assumed that note carried enough weight. I was wrong.

Rejection 1 — 4.0 Design, Spam

The reviewer wrote that they could not verify the "add to cart" flow because the in-app copy was not in English. One phrase stuck with me: "Please provide a build with English-language UI, or a video demonstration with English narration explaining each step."

I want to be careful here. I do not think Apple has a bias against Turkish apps. What I think happened — and what I would tell anyone going through the same thing — is that the reviewer's default assumption is English-first. When they cannot read the UI, they fall back to "I cannot verify this," and the nearest rejection bucket is 4.0. It is not personal. It is a process failure on our side. We did not give the reviewer a way to evaluate the app in a language they could read.

Resolution 1 — the narration video

The next afternoon I recorded a six-minute screen capture and narrated every screen in English. "This is the home tab. The Turkish word is Anasayfa. Tapping a product card opens the product detail screen." I attached it in the Resolution Center.

Two things I learned from this step:

1. The video does not need to be polished. Mine had a dog barking in the background at minute four. It was accepted.
2. The reviewer does not need a translated build. They need a way to follow the flow. A narrated screen capture is enough.

It moved into the next review queue at 19:40 that same day.

Rejection 2 — 5.1 Privacy

This one arrived two days later, at a more humane 11:20. The reviewer said we collected a phone number during onboarding and that our privacy declaration did not justify the collection. The declaration we submitted listed phone numbers under a single category: "marketing."

Here is the problem. Stork collects phone numbers for three reasons, not one:

• OTP verification at sign-in (security)
• Shipment notifications when a package status changes (app functionality)
• Support callback when the merchant needs to reach the customer (customer support)

I had filled out the privacy manifest in a hurry during submission and lumped all three under "marketing" because the form was easier that way. It was not accurate. It was barely true. The reviewer caught it, correctly.

// PrivacyInfo.xcprivacy — before (one bucket, wrong)
{
  "NSPrivacyCollectedDataTypes": [
    {
      "NSPrivacyCollectedDataType": "NSPrivacyCollectedDataTypePhoneNumber",
      "NSPrivacyCollectedDataTypeLinked": true,
      "NSPrivacyCollectedDataTypeTracking": false,
      "NSPrivacyCollectedDataTypePurposes": [
        "NSPrivacyCollectedDataTypePurposeProductPersonalization"
      ]
    }
  ]
}

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

Resolution 2 — three disclosures, not one

I rewrote the manifest to declare three separate purposes for the same data type. I also updated the App Privacy details in App Store Connect to match. That part is easy to forget, and the reviewer will compare both sides.

The lesson I keep coming back to: privacy manifests should be written before the product, not after. We described the data we already had in the language of the form. We should have started from the form and asked what we were allowed to collect.

Resubmitted on day six. It moved into the next queue at 22:08.

Rejection 3 — 2.5.4 Background Modes

Day eight. The reviewer wrote that we declared location in our UIBackgroundModes and that they could not see a "clear and meaningful user benefit" for it. The exact phrase was "the in-app notifications work without it."

I read it, opened the project, and realized the reviewer was right. We had inherited background location from an earlier feature plan — live shipment tracking on a map — that we had quietly scoped down to push notifications six weeks earlier. The Info.plist entry never came out. The app was asking for a permission it did not use.

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

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

Resolution 3 — remove the permission

I deleted the location entry, deleted the unused CLLocationManager initialization, and grepped for any other dead permission declarations. I found one: NSCalendarsUsageDescription, left over from a feature we never shipped. That came out too.

Submitted on day nine. Cleared on day eleven, 14:46 local time.

The thing I did not expect

Apple's third Resolution Center message — the approval notice — opened with "Sevgili Geliştirici." Dear Developer, in Turkish.

I do not know if a human or a script wrote that. It does not really matter. It was the politest sentence I had seen from Apple in eleven days.

What I would tell anyone going through this

A few specific things, in no order:

• Give the reviewer a path through your UI. A narrated screen capture is faster than translating the build and works for any language.
• Write the privacy manifest before the product, not after. Lumping three purposes into one bucket because the form is shorter is a small lie that you pay for in a rejection email.
• Audit your Info.plist before every submission. Dead permissions are a 2.5.4 waiting to happen. Background modes especially — Apple actively looks for unjustified ones.
• Eleven days is not a disaster. Two of the three rejections turned around in under a day. The bottleneck was always the queue, not the fix.

The counter-intuitive part, the one I would not have predicted: the reviewer was never the obstacle. The reviewer was reading our submission carefully, in the language we gave them. The obstacle was that we had described our product less honestly than we had built it. Each rejection was Apple catching a gap between what we said and what we did.

We launched on day twelve. The next morning, the first merchant onboarded through the iOS app sent us a screenshot of the home screen with one word as the caption: "yayında mıyız?" — are we live? I did not have to answer.