App Store'a gönderdiğin uygulama reddedildiğinde ilk bakman gereken yer Resolution Center'daki mesajda geçen guideline numarasıdır; bu rehber, App Review Guidelines'ın güncel metnine dayanarak en sık karşılaşılan red nedenlerini guideline numarasıyla eşleştirir ve gönderim öncesi neyi kontrol etmen gerektiğini gösterir. "App Store red nedenleri" araması yapan çoğu geliştirici aslında tek bir maddeyi değil, birbirine benzeyen birkaç guideline'ı (4.1 ile 4.3, 2.3.3 ile 2.3.4, 3.1.1 ile 3.1.2) karıştırıyor — bu yazı onları ayırt etmeyi hedefliyor.
💡 Pro Tip: Red mesajını aldığında önce guideline numarasını (ör. 4.3(b)) not et, sonra guidelines sayfasındaki ilgili maddenin tam metnini oku — Apple'ın kullandığı ifadeler yanıt yazarken de doğrudan işine yarar.
İçindekiler
- İnceleme süreci nasıl işliyor
- En sık red nedenleri (guideline numarasıyla)
- Metadata ve ekran görüntüsü reddi
- Guideline 4.3: benzerlik ve spam tuzağı
- Abonelik ve satın alma reddi
- Gizlilik, izin ve hesap silme reddi
- Red mesajını doğru okumak ve yanıt yazmak
- Gönderim öncesi 25 maddelik kontrol listesi
- SSS
- App Store uygulamamı neden reddetti?
- Guideline 4.3 (spam) reddi nasıl aşılır?
- 2.3.8 neden yüksek yaş derecelendirmeli uygulamalarda da geçerli?
- 3.1.1 hangi kilit açma yöntemlerini yasaklıyor?
- Ekran görüntüsü reddi ile önizleme video reddi aynı şey mi?
- Abonelik reddi ile IAP reddi arasındaki fark ne?
- Red kararına nasıl itiraz edilir?
- Güncelleme (Eylül 2026)
- Sonuç
- Kaynaklar
İnceleme süreci nasıl işliyor
Gönderdiğin build, App Store Connect üzerinden incelemeye girer ve sonuç yine App Store Connect'teki Resolution Center'da bir mesaj olarak karşına çıkar. Her red, App Store Review Guidelines'ın belirli bir maddesine referans verir ve bu maddenin numarası (ör. 2.3.3, 3.1.2, 4.3(a)) Resolution Center mesajının içinde açıkça yazar. Aşağıdaki bölümler bu numaraların ne anlama geldiğini ve en sık hangilerinin tetiklendiğini tek tek açıklıyor.
Bir şeyi baştan netleştirmek gerekiyor: Resolution Center mesajı çoğu zaman kısa ve genel bir dille yazılır, ama referans verdiği guideline maddesi her zaman spesifiktir. Bu iki katman (kısa mesaj vs. uzun madde metni) arasındaki farkı anlamadan yanıt yazan geliştiriciler aynı reddi tekrar alma riskiyle karşılaşır. Bu yüzden aşağıdaki her bölümde önce maddenin ne dediğini, sonra pratikte nasıl bir hataya karşılık geldiğini ayrı ayrı anlatıyoruz.
En sık red nedenleri (guideline numarasıyla)
Guideline'lar beş ana bölüme ayrılır: Safety, Performance, Business, Design ve Legal. Bu rehberde ele alınan maddeler bu beş bölümden dördünde — Performance (metadata/ekran görüntüsü), Business (abonelik/IAP), Design (kopya/spam) ve Legal (gizlilik) — toplanıyor. Aşağıdaki tablo en sık karşılaşılan maddeleri, kısa gerekçesiyle birlikte listeliyor.
Guideline | Red nedeni | Ne yapmalısın |
|---|---|---|
4.1 | Popüler bir uygulamanın küçük değişikliklerle kopyalanması, isim/UI'ın kendine mal edilmesi | Kendi özgün değer önerini ekranda göster, isim/ikonu farklılaştır |
4.1(b) | Başka bir uygulama veya servisi taklit eden (impersonate) gönderim | Marka/ikon benzerliğini kaldır, resmi ortaklık iddiası varsa belgeyle |
4.3(a) | Aynı uygulamanın konum, spor takımı veya üniversite gibi varyasyonları için ayrı Bundle ID kullanılması | Tek uygulama gönder, varyasyonları uygulama içi satın alma ile sun |
4.3(b) | Zaten doygun bir kategoride benzersiz, yüksek kaliteli bir deneyim sunmayan yeni gönderim | Ekran görüntüsü ve açıklamada somut farkı öne çıkar |
2.3.3 | Ekran görüntülerinin başlık görseli/login/splash ekranından ibaret olması | Gerçek kullanım anlarını göster |
2.3.4 | Önizleme videosunun gerçek ekran kaydı olmaması | Yalnızca uygulamanın kendi ekran kaydını kullan |
2.3.8 | Metadata'nın (ikon, ekran görüntüsü, önizleme) 4+ yaş uygunluğuna aykırı olması | Yüksek yaş derecelendirmeli uygulamalarda bile metadata'yı 4+ seviyede tut |
3.1.1 | Özellik kilidini IAP yerine lisans anahtarı, QR kod veya kripto ile açmak | Kilitleme mantığını StoreKit IAP'e taşı |
3.1.2(a) | Auto-renewable aboneliğin 7 günden kısa olması veya tüm cihazlarda geçerli olmaması | Süreyi ve cihaz kapsamını App Store Connect'te doğru tanımla |
3.1.2(a) | Kullanıcıyı yanlış bahaneyle veya bait-and-switch ile aboneliğe yönlendirmek | Fiyat/içerik vaadini satın alma öncesi net göster |
3.1.2(c) | Abonelik öncesi fiyat/içerik detayının net anlatılmaması | Kaç öğe, ne kadar depolama, hangi erişim — bunları önceden yaz |
5.1.1(i) | App Store Connect metadata'sında veya uygulama içinde gizlilik politikası linkinin eksik olması | Linki hem metadata hem uygulama içinde kolay erişilebilir yap |
5.1.1(ii) | Anonim olsa bile veri toplama için kullanıcı onayı alınmaması, ücretli özelliğin bu izne bağlanması | Onay akışını izinden önce göster, ücretli özelliği izne bağlama |
5.1.1(v) | Hesap oluşturmayı destekleyen uygulamada uygulama içi hesap silme seçeneğinin olmaması | Ayarlar'a doğrudan "Hesabı Sil" akışı ekle |
Bu liste her red nedenini kapsamıyor, ama Resolution Center'da en sık görülen dört kümeyi (kopya/spam, metadata, abonelik, gizlilik) tek tabloda topluyor. Dikkat edilmesi gereken bir nokta: aynı gönderimde birden fazla madde birden tetiklenebilir — örneğin abonelik sunan bir uygulama hem 3.1.2(c) hem de 5.1.1(ii) reddini aynı anda alabilir, çünkü fiyat netliği ve veri onayı genelde aynı ekranda (satın alma öncesi) yaşanan sorunlar. Bu yüzden tek bir maddeyi düzeltip yeniden göndermeden önce, aynı ekranı etkileyen diğer maddeleri de kontrol etmek zaman kazandırır.
Metadata ve ekran görüntüsü reddi
Metadata reddi genelde üç maddeden birine dayanır. 2.3.3, ekran görüntülerinin uygulamanın gerçek kullanımını göstermesini şart koşar — yalnızca başlık görseli, login ekranı veya splash screen yeterli sayılmaz. 2.3.4 aynı mantığı önizleme videosuna uygular: önizleme yalnızca uygulamanın kendi ekran kaydından oluşabilir, dışarıdan prodüksiyon görüntüsü veya animasyon kabul edilmez. 2.3.8 ise farklı bir eksene bakar: ikon, ekran görüntüsü ve önizlemeler her zaman 4+ yaş derecelendirmesine uygun olmalı — uygulamanın kendisi daha yüksek yaşta derecelendirilmiş olsa bile metadata'da şiddet, cinsellik veya uygunsuz içerik göstermemelisin.
Pratikte en sık yapılan hata şu: geliştirici uygulamanın "en havalı" ekranını (genelde onboarding veya splash) ekran görüntüsü olarak seçiyor, ama bu ekran gerçek kullanım anını yansıtmıyor. Uygulamanın gerçek ana ekranlarını çekmek, 2.3.3'ü karşılamanın en garantili yolu.
bash
1# App Store Connect'e yüklemeden önce ekran görüntülerini gerçek cihazdan al2xcrun simctl io booted screenshot ekran-01.pngUniversal Links veya deep link ile açılan sayfaların ekran görüntüsünü de eklemek istiyorsan, önce bu akışın gerçekten çalıştığını doğrulaman gerekir — bu konuyu deep linking ve Universal Links rehberinde ayrıca işledik.
Guideline 4.3: benzerlik ve spam tuzağı
4.1 ve 4.3 sık karıştırılıyor çünkü ikisi de "kopyalama" temalı, ama farklı şeyleri hedefliyor. 4.1 (Copycats) senin başka bir uygulamayı kopyalamandan bahsediyor: en son popüler uygulamanın adını/UI'ını küçük değişikliklerle kendine mal etmek. 4.1(b) bir adım öteye gidiyor ve başka bir uygulama veya servisi taklit eden (impersonate) gönderimleri Developer Code of Conduct ihlali sayıyor; bu tür bir ihlal Apple Developer Program'dan çıkarılmaya kadar gidebilir.
4.3 ise iki alt maddeyle farklı bir sorunu hedefliyor. 4.3(a), aynı uygulamanın konum, spor takımı veya üniversite gibi farklı varyasyonları için birden fazla Bundle ID ile gönderilmesini spam sayıyor — doğrusu, tek bir uygulama gönderip varyasyonları uygulama içi satın alma ile sunmak. 4.3(b) ise zaten doygun bir kategoride benzersiz, yüksek kaliteli bir deneyim sunmayan yeni gönderimleri reddediyor. Kendi kategorinde rakiplerinden somut olarak neyin farklı olduğunu ekran görüntüsü ve açıklamada açıkça belirtmek en güvenli yaklaşım.
Guideline | Neyi hedefler | Ayırt edici soru |
|---|---|---|
4.1 | UI/isim kopyalama | Bu ekran/isim başka bir uygulamadan mı geliyor? |
4.1(b) | Marka/servis taklidi | Kullanıcı bu uygulamayı resmi bir servis sanabilir mi? |
4.3(a) | Aynı uygulamanın çoklu Bundle ID'si | Aynı işlevi tek uygulamada toplayabilir miyim? |
4.3(b) | Doygun kategoride farklılaşma eksikliği | Ekran görüntüsünde somut fark görünüyor mu? |
Abonelik ve satın alma reddi
Abonelik/IAP reddi genelde iki katmanda gerçekleşir: teknik uygulama (StoreKit dışı mekanizma kullanmak) ve sunum (kullanıcıya fiyat/içeriği yanlış veya eksik anlatmak).
3.1.1, özellik veya içerik kilidini açmak için uygulamanın kendi mekanizmasını (lisans anahtarı, QR kod, kripto para veya cüzdan vb.) kullanmasını yasaklıyor — bunun yerine StoreKit üzerinden IAP kullanılmalı. 3.1.2(a) iki ayrı koşul getiriyor: auto-renewable abonelik en az 7 gün sürmeli ve kullanıcının tüm cihazlarında geçerli olmalı; ayrıca kullanıcıyı sahte bahaneyle veya bait-and-switch ile aboneliğe yönlendiren uygulamalar App Store'dan kaldırılıyor. 3.1.2(c) ise satın alma öncesi netliği zorunlu kılıyor: kullanıcıya abone olmasını istemeden önce ne alacağını (kaç sayı/ay, ne kadar depolama, hangi erişim seviyesi) açıkça anlatman gerekiyor.
Satın alma ekranının kendisi de ayrı bir kaynaktan denetleniyor: App Store'un Abonelikler sayfasına göre, satın alma ekranında abonelik adı ve süresi, tam yenileme fiyatı (kullanılabilir para birimlerinde lokalize) ve mevcut abonelerin giriş yapıp satın almalarını geri yükleyebileceği bir yol bulunmalı. Ayrıca faturalandırılacak toplam tutar, satın alma akışındaki en belirgin fiyat unsuru olmalı — küçük yazılmış bir fiyatın yanında büyük puntoyla "ücretsiz dene" yazmak bu kuralı ihlal eder.
swift
1// Restore akışı, aboneliğin kullanıcının tüm cihazlarında erişilebilir olmasının istemci tarafındaki parçasıdır2func restorePurchases() {3 Task {4 try? await AppStore.sync()5 await updateSubscriptionStatus()6 }7}Gelir paylaşımı tarafında hatırlatma: bir abonenin ilk yılında geliştirici gelirin %70'ini, bir yıllık ücretli hizmetten sonra ise %85'ini alıyor — bu oran doğrudan reddi tetiklemez ama fiyatlandırma stratejisi kurarken hesaba katman gerekir. StoreKit 2 ile modern IAP akışını sıfırdan kurmak istiyorsan StoreKit 2 rehberimize bakabilirsin.
Gizlilik, izin ve hesap silme reddi
Bu bölümdeki üç madde birbirini tamamlıyor ve genelde birlikte kontrol ediliyor. 5.1.1(i), tüm uygulamaların hem App Store Connect metadata alanında hem de uygulama içinde kolay erişilebilir bir gizlilik politikası linki bulundurmasını şart koşuyor — yalnızca App Store Connect'e link eklemek yeterli değil, uygulama içinde de (genelde Ayarlar ekranında) bu linke ulaşılabilmeli. 5.1.1(ii), kullanıcı veya kullanım verisi toplayan uygulamaların bu veri anonim sayılsa bile kullanıcı onayı alması gerektiğini belirtiyor; kritik nokta şu — ücretli bir özellik, kullanıcının bu veri erişimine izin vermesine bağlı olamaz. 5.1.1(v) ise hesap oluşturmayı destekleyen her uygulamanın uygulama içinden hesap silme sunmasını zorunlu kılıyor.
İzin isteme akışının kendisi de reddi tetikleyebilir: kullanıcıya neden bu izne ihtiyacın olduğunu açıklamadan sistem izin diyaloğunu göstermek, kullanıcının "İzin Verme"yi seçmesine ve sonradan destek talebine yol açar. İzin isteme akışını farklı bir bağlamda (sağlık verisi) nasıl kurduğumuzu görmek istersen HealthKit entegrasyon rehberimize bakabilirsin. İzin isteme zamanlamasını ve kullanıcıya sunuluş bağlamını optimize etmek istersen push izin oranı rehberimize da bakabilirsin.
xml
1<key>NSCameraUsageDescription</key>2<string>Profil fotoğrafı çekmek için kameraya erişim gerekiyor</string>Hesap silme akışını App içinden erişilebilir tutmak için genelde Ayarlar > Hesap altına doğrudan bir eylem koymak yeterli:
json
1{2 "settingsSection": "Hesap",3 "actions": ["Şifreyi Değiştir", "Verilerimi İndir", "Hesabı Sil"]4}Erişilebilirlik açısından da bu ekranların VoiceOver ve Dynamic Type ile tam çalışması gerekiyor; bu konuyu ayrıca iOS Accessibility rehberinde detaylandırdık.
Red mesajını doğru okumak ve yanıt yazmak
Resolution Center'daki mesaj her zaman bir guideline numarası içerir; ilk adım bu numarayı guidelines sayfasındaki tam madde metniyle eşleştirmek. İkinci adım, yanıtını doğrudan o maddeye referans vererek yazmak — "düzelttim" demek yerine hangi ekranı, hangi metni veya hangi akışı neden değiştirdiğini somut olarak anlatmak, incelemeyi yapan ekibin senin değişikliğini hızlıca doğrulamasını kolaylaştırır. Reddin gerekçesi belirsizse veya yanlış anlaşılmış hissettiriyorsa, Apple geliştiricilere itiraz için bir yol sunuyor; güncel itiraz akışını App Store Connect içindeki Resolution Center ekranından takip etmen en güvenilir yol.
Gönderim öncesi 25 maddelik kontrol listesi
Aşağıdaki liste, yukarıdaki bölümlerde geçen tüm guideline maddelerinin pratik karşılığını tek yerde topluyor. Amaç, build'i App Store Connect'e yüklemeden önceki son 15-20 dakikada tek tek işaretleyebileceğin, teknik değil operasyonel bir kontrol seti oluşturmak. Listedeki her madde, yukarıda anlatılan en az bir guideline numarasına doğrudan karşılık geliyor; bu yüzden bir maddeyi işaretleyemiyorsan hangi bölüme geri dönmen gerektiğini de biliyorsun.
- İkon ve isim: Başka bir uygulamayla karıştırılabilecek kadar benzer değil
- Ekran görüntüleri: Gerçek kullanım anlarını gösteriyor, splash/login değil
- Önizleme videosu: Uygulamanın kendi ekran kaydından oluşuyor
- Metadata yaş uygunluğu: İkon/görsel/önizleme 4+ seviyesinde
- Bundle ID stratejisi: Aynı işlev için birden fazla Bundle ID yok
- Farklılaşma: Kategori doygunsa somut fark ekran görüntüsünde görünüyor
- IAP mekanizması: Kilit açma StoreKit üzerinden, harici lisans/QR/kripto yok
- Abonelik süresi: Auto-renewable en az 7 gün, tüm cihazlarda geçerli
- Abonelik fiyat netliği: Satın alma öncesi içerik/fiyat açıkça anlatılıyor
- Satın alma ekranı: Ad, süre, tam fiyat ve restore seçeneği görünür
- Fiyat önceliği: Faturalandırılacak tutar ekranda en belirgin unsur
- Gizlilik politikası linki: Hem App Store Connect'te hem uygulama içinde
- Veri toplama onayı: İzin öncesi açık onay akışı var
- Ücretli özellik bağımlılığı: Ücretli özellik veri iznine bağlı değil
- Hesap silme: Hesap oluşturma varsa uygulama içi silme de var
- İzin metinleri: Her Info.plist usage description açıklayıcı ve doğru
- Restore purchases: Buton çalışıyor ve test edildi
- Deep link / Universal Link: Gerçek cihazda açılış test edildi
- Erişilebilirlik: VoiceOver ve Dynamic Type temel akışlarda çalışıyor
- Crash-free build: TestFlight'ta en az bir tam kullanıcı akışı crash'siz
- Demo hesap: Girişli özellikler için test hesabı App Review notlarında
- App Review notları: Özel akışlar (abonelik, izin, özel donanım) açıklanmış
- Sürüm notları: Kullanıcıya dönük, teknik jargon içermiyor
- Yasal metinler: Kullanım koşulları/EULA linkleri güncel
- Test cihazı çeşitliliği: En az bir eski ve bir yeni cihazda son kontrol yapılmış
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
Bu bölümde, gönderim öncesi son beş dakikada gözden geçirebileceğin sıkıştırılmış bir kontrol listesi var — yukarıdaki 25 maddenin en sık atlanan alt kümesi. Build'i yüklemeden hemen önce bunları tek tek işaretlemek, en yaygın dört red kümesinden (metadata, spam/benzerlik, abonelik, gizlilik) kaynaklanan reddi büyük ölçüde önler.
SSS
App Store uygulamamı neden reddetti?
Red mesajı Resolution Center'da bir guideline numarasıyla birlikte gelir; en sık nedenler metadata/ekran görüntüsü uyumsuzluğu (2.3.x), abonelik/IAP sunumu (3.1.x) ve gizlilik/hesap silme eksikleri (5.1.1.x) etrafında toplanıyor. İlk yapman gereken, mesajdaki numarayı guidelines sayfasındaki tam madde metniyle karşılaştırmak.
Guideline 4.3 (spam) reddi nasıl aşılır?
4.3(a) için aynı işlevi tek bir uygulamada toplaman gerekir (ör. konum, spor takımı veya üniversite varyasyonlarını ayrı Bundle ID yerine uygulama içi satın alma ile sunmak); ayrı Bundle ID'lerle çoğaltma kabul edilmez. 4.3(b) için ise kategorinde zaten var olan uygulamalardan somut olarak neyin farklı olduğunu ekran görüntüsü ve açıklamada açıkça göstermen gerekiyor — genel "daha iyi" iddiası yeterli değil, farkın görünür olması gerekiyor.
2.3.8 neden yüksek yaş derecelendirmeli uygulamalarda da geçerli?
2.3.8, ikon, ekran görüntüsü ve önizlemelerin her zaman 4+ yaş derecelendirmesine uygun olmasını şart koşuyor — bu kural, uygulamanın kendisi daha yüksek yaşta derecelendirilmiş olsa bile geçerli. Yani metadata'nda şiddet, cinsellik veya uygunsuz içerik gösteremezsin, uygulamanın içeriği App Store'da daha yüksek yaş sınırıyla listelense bile.
3.1.1 hangi kilit açma yöntemlerini yasaklıyor?
3.1.1, özellik veya içerik kilidini açmak için uygulamanın kendi mekanizmasını — lisans anahtarı, QR kod, kripto para veya cüzdan gibi StoreKit dışı yöntemleri — kullanmasını yasaklıyor. Bunun yerine kilitleme mantığının StoreKit üzerinden IAP ile yapılması gerekiyor.
Ekran görüntüsü reddi ile önizleme video reddi aynı şey mi?
Hayır, ayrı maddeler. 2.3.3 statik ekran görüntülerinin gerçek kullanımı göstermesini istiyor; 2.3.4 ise önizleme videosunun uygulamanın kendi ekran kaydından oluşmasını şart koşuyor. İkisi birlikte reddedilebilir ama farklı düzeltmeler gerektirir.
Abonelik reddi ile IAP reddi arasındaki fark ne?
3.1.1 genel IAP kilitleme mekanizmasını (harici lisans/QR/kripto yerine StoreKit) hedefler; 3.1.2 ise özellikle auto-renewable aboneliklerin süresi, cihaz kapsamı ve satın alma öncesi netlik gibi abonelik-özel kurallarını kapsar. Bir uygulama her ikisinden de aynı anda red alabilir.
Red kararına nasıl itiraz edilir?
Reddin gerekçesi belirsizse veya yanlış anlaşılmış hissettiriyorsa, Apple geliştiricilere itiraz için bir yol sunuyor; itiraz akışını App Store Connect içindeki Resolution Center ekranından takip edebilirsin. İtirazını yazarken hangi guideline maddesine neden katılmadığını veya hangi değişikliği yaptığını somut olarak belirtmek, incelemeyi yapan ekibin sürecini hızlandırır.
Güncelleme (Eylül 2026)
Bu yazı 15 Ocak 2025 tarihindeki guideline metnine göre yazıldı; o tarihten sonra red nedenlerini etkileyebilecek birkaç değişiklik oldu:
- 8 Haziran 2026: Guidelines'a metin netleştirme odaklı bir revizyon geldi — 4.3(a) ve 4.3(b) maddelerine örnek eklendi, 4.5.3 Live Activities'in spam/phishing amaçlı kullanılamayacağı netleşti, 1.2'ye geliştirici sorumluluklarını açıklayan yeni bir paragraf eklendi, giriş bölümündeki çocuk/genç güvenliği rehberliği revize edildi. Kaynak: developer.apple.com/news/?id=a233fmpw
- 28 Nisan 2026: iOS 26 SDK ile build alma zorunluluğu yürürlüğe girdi; eski SDK ile yapılan gönderimler artık App Store Connect'e yükleme aşamasında reddediliyor (App Review'a hiç ulaşmıyor). Sıradaki eşik iOS 27 SDK için Nisan 2027 olarak duyuruldu. Kaynak: developer.apple.com/news/?id=ueeok6yw (iOS 26 eşiği) ve developer.apple.com/news/?id=k1mtkt1k (iOS 27 eşiği)
- 29 Ekim 2025: Bağımsız gönderim kapsamı (IAP etkinliği, kritik hata düzeltmesi, Game Center güncellemesi) genişletildi; Custom Product Pages tavanı iki katına çıkarılarak 70'e yükseltildi. Bu değişiklikler doğrudan red nedeni değil ama gönderim stratejisini etkiliyor. Kaynak: developer.apple.com/news/?id=gf6mgrs6
- 27 Nisan 2026: ABD/Singapur dışında 12 aylık taahhütlü aylık abonelik modeli tanıtıldı; bu modeli kullanan uygulamaların 3.1.2 metadata'sını doğru güncellemesi gerekiyor. Kaynak: developer.apple.com/news/?id=agq42lxe
Bu değişikliklerin hiçbiri 2025-01-15 tarihli ana gövdedeki guideline numaralarını geçersiz kılmıyor, sadece kapsamlarını genişletiyor — red aldığında yine ilk kontrol yerin Resolution Center'daki numara olmalı.
Sonuç
App Store reddi genelde dört kümeden birine düşer: metadata/ekran görüntüsü (2.3.x), benzerlik/spam (4.1, 4.3), abonelik/IAP (3.1.x) ve gizlilik/hesap silme (5.1.1.x). Her red mesajı bir guideline numarasıyla gelir; o numarayı guidelines sayfasındaki tam metinle eşleştirmek ve yanıtını doğrudan o maddeye göre yazmak, ikinci bir reddi önlemenin en güvenilir yolu. Abonelik akışını sağlamlaştırmak için StoreKit 2 rehberimize, izin isteme akışını farklı bir bağlamda görmek için HealthKit entegrasyon rehberine, erişilebilirlik kontrolleri için iOS Accessibility rehberine ve deep link testleri için Universal Links rehberine göz atabilirsin. Gönderim öncesi bu yazıdaki 25 maddelik kontrol listesini bir kez daha taramak, çoğu red kümesini gönderim yapmadan önce yakalamana yardımcı olur.
Kaynaklar
- App Store Review Guidelines — 4.1, 4.3, 2.3.x, 3.1.x, 5.1.1.x maddelerinin tam metni
- App Store Subscriptions — satın alma ekranı zorunlulukları ve gelir paylaşımı oranları
- Offering Account Deletion in Your App — 5.1.1(v) hesap silme zorunluluğunun uygulama detayları
- Apple Developer News — Haziran 2026 guideline ve lisans sözleşmesi revizyonu duyurusu
- Apple Developer News — iOS 26 & iPadOS 26 SDK ile build alma zorunluluğu (28 Nisan 2026)
- Apple Developer News — iOS 27 & iPadOS 27 SDK eşiği duyurusu (Nisan 2027)
- Apple Developer News — bağımsız gönderim kapsamı ve Custom Product Pages genişlemesi
- Apple Developer News — 12 aylık taahhütlü aylık abonelik modeli duyurusu
