01İki mağaza neye takılıyor?What does each store actually reject for?
Apple ve Google farklı kural setleriyle çalışıyor ve farklı şeylere takılıyor. Apple ağırlıkla gizlilik bildirimleri, ödeme akışı ve tamamlanmışlık üzerinden reddediyor; Google izin beyanları, Data Safety formu tutarlılığı ve hesap düzeyindeki ihlaller üzerinden. 2025'te Google Play 1,75 milyon uygulamayı bloke etti; bunun dışında 255.000 uygulama yalnızca gereksiz hassas veri erişimi talebi nedeniyle durduruldu.
Apple and Google run different rulebooks and trip on different things. Apple rejects mostly over privacy declarations, payment flow and completeness; Google over permission declarations, Data Safety form consistency and account-level violations. In 2025 Google Play blocked 1.75 million apps — and separately stopped 255,000 apps solely for requesting unnecessary access to sensitive data.
Redlerin büyük çoğunluğu birkaç saatte düzeltilebilir sorunlardan gelir. Maliyetli olan, bu sorunları gönderim günü keşfetmektir.
Most rejections come from problems fixable in a few hours. The expensive part is discovering them on submission day.
02Apple'da en sık redler: Guideline 2.1, ITMS-91061, IAPApple's most common rejections: Guideline 2.1, ITMS-91061, IAP
Guideline 2.1 — App Completeness, en sık ve en önlenebilir red. Review ekibi uygulamayı gerçek cihazda çalıştırır: App Store Connect'te demo hesap yoksa ya da gönderim günü çalışmıyorsa, ekranlarda Lorem ipsum veya görünür test verisi kaldıysa, backend review sırasında down'sa ya da desteklendiği beyan edilen cihazlarda (iPad, iPhone SE) UI kırıksa red gelir. Pratik kural: demo hesabı gönderim sabahı bizzat test edin — reviewer "video gönderin" teklifinizi kabul etmez, uygulamanın kendi içinde çalışması gerekir.
Guideline 2.1 — App Completeness is the most frequent and the most preventable rejection. Reviewers run the app on a real device: if there's no demo account in App Store Connect (or it doesn't work on submission day), if Lorem ipsum or visible test data remains, if the backend is down during review, or if the UI is broken on devices you claim to support (iPad, iPhone SE), you get rejected. Practical rule: personally test the demo account on submission morning — reviewers won't accept "we'll send a video"; the app must work on its own.
Privacy Manifest — ITMS-91061, 2024'ten beri geçerli, en sinsi engelleyici. Belirli API'leri kullanan uygulamalar PrivacyInfo.xcprivacy dosyasıyla hangi API'yi neden kullandığını beyan etmek zorunda — ve bu zorunluluk üçüncü parti SDK'ları da kapsıyor. Firebase, Amplitude, Adjust veya Mixpanel'in manifest içermeyen eski bir versiyonu varsa, gönderim insan gözüne gelmeden otomatik bloke olur:
Privacy Manifest — ITMS-91061, in force since 2024, is the sneakiest blocker. Apps using certain APIs must declare which API they use and why via a PrivacyInfo.xcprivacy file — and the requirement covers your third-party SDKs too. Ship an outdated Firebase, Amplitude, Adjust or Mixpanel version without a manifest, and the submission is blocked automatically before a human ever sees it:
ITMS-91061: Missing privacy manifest — Your app includes "<path/to/SDK>", which includes an SDK identified as privacy-impacting. # Önleme: Xcode Privacy Report'u her build öncesi çıkarın; # Apple listesindeki tüm SDK'lar manifest içeren güncel versiyonda olmalı.# Prevention: generate the Xcode Privacy Report before every build; # every SDK on Apple's list must be current and ship a manifest.
Guideline 3.1 — In-App Purchase. Dijital içerik, abonelik veya özellik satıyorsanız Apple'ın IAP sistemi (StoreKit) zorunlu. Harici ödeme sayfasına link, "web sitemizden abone olun" çağrısı ve Stripe/PayPal checkout bağlantısı — tamamı 3.1.1 ihlali. IAP zorunlu olmayan durumlar: fiziksel ürün satışı, gerçek dünya hizmetleri (taksi, yemek) ve reader app'ler (harici satın alma linki olmadan). Not: ABD App Store'da 2025 sonrası Epic davası kararıyla harici link artık entitlement'sız izinli. Redlerin bir kısmı davranışsal: agresif paywall, ücretsiz deneme bitişini gizlemek, abonelik koşullarını ödeme öncesi göstermemek — reviewer ödeme akışını adım adım test eder.
Guideline 3.1 — In-App Purchase. If you sell digital content, subscriptions or features, Apple's IAP (StoreKit) is mandatory. A link to an external payment page, a "subscribe on our website" prompt, a Stripe/PayPal checkout link — all violate 3.1.1. IAP is not required for: physical goods, real-world services (rides, food) and reader apps (as long as there's no external purchase link). Note: on the US App Store, external links are allowed without an entitlement after the 2025 Epic ruling. Some IAP rejections are behavioral, not technical: aggressive paywalls, hiding when a free trial ends, not showing subscription terms before payment — reviewers walk the payment flow step by step.
İki tarih bazlı zorunluluk: Kasım 2025'ten beri, kullanıcı verisini OpenAI, Gemini veya Claude gibi harici bir AI servisine gönderen uygulamalar, servisin adını ve paylaşılan veri tiplerini belirten bir onay ekranı göstermek zorunda — göstermeyenler reddediliyor. Nisan 2026'dan beri de Xcode 26 SDK ile build almak şart; eski sürümle gönderilen binary'ler ITMS-90725 ile otomatik dönüyor, CI/CD pipeline'ları dahil.
Two date-driven requirements: Since November 2025, apps sending user data to an external AI service (OpenAI, Gemini, Claude) must show a consent screen naming the service and the data types shared — apps without it get rejected. And since April 2026, building with the Xcode 26 SDK is mandatory; binaries built with older SDKs bounce automatically with ITMS-90725 — CI/CD pipelines included.
03Az bilinen tuzaklar: Çin, ATT, pacgaThe lesser-known traps: China, ATT, pacga
Çin App Store'unda CallKit yasak. Jitsi, Agora veya Azure Communication Services gibi bir VoIP SDK'sı kullanıyorsanız ve Çin dağıtım listesindeyse, Guideline 5.0 (Legal) reddi gelir: MIIT, CallKit'in native arama entegrasyonunun Çin'de devre dışı bırakılmasını istiyor. VoIP'in kendisi yasak değil; native entegrasyon yasak. Seçenekler: Çin'i dağıtımdan çıkarmak (Jitsi'nin tercihi), CallKit'i tamamen kapatmak ya da bölgeye göre açıp kapamak — ki reviewer'lar lokasyon bazlı davranış farkını kabul etmiyor. Ek olarak Çin'de sunucuya istek atan her uygulama için ICP filing numarası zorunlu; bunun için Çin'de tescilli şirket ya da yerel yayıncı ortaklığı gerekiyor. Çin'i hedeflemiyorsanız en temiz yol, dağıtım listesinden çıkarmak.
CallKit is banned on the China App Store. If you use a VoIP SDK (Jitsi, Agora, Azure Communication Services) and China is in your territories, you'll get a Guideline 5.0 (Legal) rejection: MIIT requires CallKit's native call integration to be deactivated in China. VoIP itself isn't banned — the native integration is. Options: remove China from distribution (Jitsi's choice), disable CallKit entirely, or toggle it by region — which reviewers reject as location-based behavior differences. Additionally, any app talking to servers from China needs an ICP filing number, which requires a registered Chinese company or a local publishing partner. If you're not targeting China, the cleanest path is removing it from your territories.
ATT tavuk-yumurta tuzağı. Tracking'i kaldırmak için güncelleme gönderiyorsunuz; Apple, binary'de hâlâ NSUserTrackingUsageDescription olduğu için reddediyor — ama bu anahtarı içeren binary yayında olduğu sürece App Store Connect, Data Privacy'de "tracking" işaretini kaldırmanıza izin vermiyor. Çözüm: tüm tracking referanslarını (SDK'lar dahil) binary'den temizleyin, yeni build gönderin; red gelince Resolution Center'dan bunun Apple tarafında bilinen bir durum olduğunu forum bağlantısıyla açıklayın. Review ekibi geçişe izin veriyor — ama genellikle ilk denemede değil.
The ATT chicken-and-egg trap. You submit an update to remove tracking; Apple rejects because the live binary still contains NSUserTrackingUsageDescription — but as long as a binary with that key is live, App Store Connect won't let you untick "tracking" in Data Privacy. The fix: strip all tracking references (SDKs included) from the binary, submit a new build, and when the rejection comes, explain via Resolution Center that this is a known issue on Apple's side, with a developer-forum link. Review teams allow it through — usually not on the first try.
pacga false positive'i. Bazen uygulama, kullanmadığı bir private API gerekçesiyle reddedilir: Guideline 2.5.1, "non-public API: pacga". pacga aslında bir API değil — ARM64e mimarisinde Apple'ın Pointer Authentication (PAC) mekanizmasının derleyici tarafından otomatik üretilen bir assembly instruction'ı. Apple'ın statik analizcisi bunu ara sıra private API kullanımıyla karıştırıyor. Resolution Center'dan açıklama gönderip beklemek genellikle çözüyor. Benzer bir kalıntı problemi konumda da var: uygulamada konum özelliği olmadığı hâlde review "Background Location ne için?" diye sorabiliyor — sebep çoğunlukla bir üçüncü parti SDK'nın Info.plist'inde kalan NSLocation* anahtarları. strings YourApp.ipa | grep -i NSLocation ile binary'yi kontrol edin.
The pacga false positive. Sometimes an app is rejected for a private API it never uses: Guideline 2.5.1, "non-public API: pacga". pacga isn't an API — it's an assembly instruction emitted automatically by the compiler for Apple's Pointer Authentication (PAC) mechanism on ARM64e. Apple's static analyzer occasionally mistakes it for private API usage. An explanation via Resolution Center and some patience usually resolves it. A similar leftover problem exists for location: review may ask "what requires Background Location?" even though the app has no location feature — the cause is usually NSLocation* keys left behind in a third-party SDK's Info.plist. Check the binary with strings YourApp.ipa | grep -i NSLocation.
04Google Play: izinler, Data Safety, kapalı testGoogle Play: permissions, Data Safety, closed testing
Over-permissioning tek başına 2025'te 255.000 uygulamayı durdurdu. READ_SMS, ACCESS_FINE_LOCATION, READ_CONTACTS gibi hassas izinler gerekçesiz kullanıldığında doğrudan red sebebi. Permission Declaration Form'da "özelliğe ihtiyacım var" yetmiyor — hangi kullanıcı aksiyonunun bu izni gerektirdiğini somut olarak açıklamanız gerekiyor. Foreground service kullanan SDK'lara da dikkat: eski Jitsi versiyonlarında foregroundServiceType eksik geliyor ve Play Store reddediyor.
Over-permissioning alone stopped 255,000 apps in 2025. Sensitive permissions like READ_SMS, ACCESS_FINE_LOCATION and READ_CONTACTS are direct rejection grounds when unjustified. On the Permission Declaration Form, "my feature needs it" isn't enough — you must concretely explain which user action requires the permission. Watch SDKs using foreground services too: older Jitsi versions ship without foregroundServiceType, and Play rejects.
Data Safety formu uyumsuzluğu ciddi bir red sebebi — ve üçüncü parti kütüphanelerin topladığı veri de sizin beyan sorumluluğunuza giriyor. Tehlikeli kısım: Google bu uyumsuzluğu yalnızca başvuruda değil, yayın sonrasında da takip ediyor; sonradan tespit edilen uyumsuzluk uygulamanın kaldırılmasına yol açabiliyor. Bir de yeni hesap kuralı var: 2025 ortasından beri yeni Play Console hesapları, production'a geçmeden önce en az 12 gerçek kullanıcıyla 14 ardışık gün kapalı test yapmak zorunda.
Data Safety form mismatch is a serious rejection ground — and data collected by your third-party libraries falls under your declaration responsibility. The dangerous part: Google checks the mismatch not only at submission but after release too; a post-launch discrepancy can get the app taken down. There's also the new-account rule: since mid-2025, new Play Console accounts must run a closed test with at least 12 real users for 14 consecutive days before going to production.
05Gönderim öncesi kontrol listesiThe pre-submission checklist
Bu listeyi gönderim gününde değil, sprint'in bir parçası olarak çalıştırın:
Run this list as part of the sprint, not on submission day:
# Apple [ ] PrivacyInfo.xcprivacy mevcut; tüm SDK'lar manifest'li güncel versiyondaPrivacyInfo.xcprivacy present; all SDKs current, with manifests [ ] Xcode Privacy Report temizXcode Privacy Report clean [ ] Demo hesap bugün bizzat test edildiDemo account personally tested today [ ] StoreKit sandbox uçtan uca: satın alma → restore → cancelStoreKit sandbox end-to-end: purchase → restore → cancel [ ] AI özelliği → provider + veri tipi belirten consent ekranıAI feature → consent screen naming provider + data types [ ] Xcode/SDK Apple'ın güncel minimumundaXcode/SDK at Apple's current minimum [ ] ATT yoksa → NSUserTrackingUsageDescription binary'de YOKNo ATT → NSUserTrackingUsageDescription NOT in binary [ ] Çin listedeyse → CallKit + ICP netleştirildiChina listed → CallKit + ICP resolved # Google Play [ ] Manifest'teki her izin kullanılıyor + gerekçesi hazırEvery manifest permission used + justification ready [ ] Data Safety formu SDK'lar dahil doğruData Safety form accurate, SDKs included [ ] Privacy Policy URL erişilebilirPrivacy Policy URL reachable [ ] foregroundServiceType tanımlıforegroundServiceType defined [ ] Yeni hesap → 12 tester ile 14 gün kapalı test tamamNew account → closed test done: 12 testers, 14 days # Her ikisi# Both stores [ ] Gerçek cihazda test (yalnızca emülatör değil)Tested on a real device (not just the simulator) [ ] Backend review boyunca stabilBackend stable throughout review [ ] Screenshot'lar gerçek uygulama UI'ındanScreenshots from real app UI
Red geldiğinde tek kural: yeniden gönderimde sadece red nedenini kapatın. Panikle ilgisiz değişiklikler yapmak review sürecini uzatır ve yeni red gerekçeleri açabilir. Mobil uygulama geliştirme sürecinin tamamında bu disiplini nasıl kurduğumuzu hizmetler sayfamızda anlatıyoruz.
When a rejection does come, one rule: fix only the cited reason in your resubmission. Panicked unrelated changes prolong review and can open new rejection grounds. How we build this discipline into the whole mobile development process is on our services page.
06Sık sorulanlarFrequently asked questions
Apple'da en sık red sebebi nedir? Guideline 2.1 — App Completeness: çalışmayan demo hesap, placeholder içerik, review sırasında down olan backend. Aynı zamanda önlenebilirliği en yüksek olan.
What's Apple's most common rejection reason? Guideline 2.1 — App Completeness: a broken demo account, placeholder content, a backend that's down during review. It's also the most preventable.
ITMS-91061 nasıl çözülür? Xcode Privacy Report'u çıkarın; Apple'ın listesindeki tüm üçüncü parti SDK'ları privacy manifest içeren güncel versiyona yükseltin. Bu hata insan incelemesine gelmeden otomatik bloke eder.
How do you fix ITMS-91061? Generate the Xcode Privacy Report; upgrade every third-party SDK on Apple's list to a current version that ships a privacy manifest. This error blocks automatically, before human review.
Google Play'de en yaygın sebep? Gerekçesiz hassas izinler ve Data Safety formu uyumsuzluğu — üçüncü parti SDK'ların topladığı veri de sizin beyanınıza dahil.
Most common on Google Play? Unjustified sensitive permissions and Data Safety form mismatches — data collected by your third-party SDKs counts as your declaration.
Red sonrası ilk adım? Sadece red nedenini kapatan minimal bir yeniden gönderim. False positive şüphesinde (pacga gibi) Resolution Center'dan açıklama gönderin.
First step after a rejection? A minimal resubmission that fixes only the cited reason. If you suspect a false positive (like pacga), send an explanation via Resolution Center.