App Store 2.1 App Completeness reddi: yeniden göndermeden önce sürüm derlemesi test planı (2026)

App Store'un 2.1 App Completeness yönergesi kapsamındaki bir ret, inceleme ekibinin uygulamanızı bir müşterinin kullanacağı gibi kullanamadığı anlamına gelir. Uygulama çökmüş, yer tutucu içerik göstermiş, ekibi giriş ekranında takılı bırakmış ya da bir uygulama içi satın almayı gizlemiş olabilir. Çözüm nadiren tek satırlık bir kod değişikliğidir. Yeniden göndermeden önce sürüm derlemesi (release build) üzerinde, temiz bir kurulumla ve App Review'a verdiğiniz bilgilerin aynısıyla kısa bir test planı uygulayın. Bu yazı o planı adım adım anlatıyor ve diğer geliştiricilerin aynı reddi nasıl çözdüğünü gösteriyor.

App Store yönergesi 2.1 App Completeness neyi kontrol eder?

Yönerge 2.1, gönderdiğiniz derlemenin bitmiş ve çalışan bir uygulama olup olmadığını kontrol eder. Eksiksiz meta veriler, çalışan bağlantılar, bir demo girişi, canlı bir arka uç ve inceleme ekibinin bulup kullanabileceği uygulama içi satın almalar gerekir.

Apple'ın App Review Guidelines belgesi 2.1'i iki bölüme ayırır. 2.1(a), gönderimlerin "gerekli tüm meta verileri ve tamamen çalışan URL'leri içeren nihai sürümler olması gerektiğini" ve yer tutucu metinlerin ve boş web sitelerinin kaldırılması gerektiğini söyler. Ayrıca hatalar ve kararlılık için cihaz üzerinde test yapmanızı ve "uygulamanızda giriş varsa demo hesap bilgilerini eklemenizi (ve arka uç hizmetinizi açmanızı!)" ister. Apple "eksik uygulama paketlerini ve çöken ya da bariz teknik sorunlar gösteren derlemeleri reddeder." 2.1(b) ise uygulama içi satın almaların "eksiksiz, güncel, inceleme ekibine görünür ve çalışır durumda" olması gerektiğini söyler. Yapılandırılmış bir satın alma uygulamada bulunamıyorsa nedenini inceleme notlarınızda açıklayın.

Bu ret yaygındır. Apple'ın Preparing for App Review sayfasında şöyle yazar: "Ortalama olarak çözülmemiş sorunların %40'tan fazlası; çökmeleri, yer tutucu içeriği, eksik bilgileri ve daha fazlasını kapsayan 2.1: App Completeness yönergesiyle ilgilidir."

Debug derlemesini test etmek neden 2.1 sorunlarını yakalamaz?

Debug derlemesi, inceleme ekibinin kopyası gibi çalışmaz. İnceleme ekibi, dağıtım için imzalanmış sürüm derlemesini kayıtlı oturumu ve hata ayıklama kısayolları olmayan temiz bir cihaza kurar.

Simülatörünüzde zaten oturum açıktır. Yerel API'niz hiç kapanmayan bir staging sunucusuna işaret ediyor olabilir. Debug bayrakları ödeme duvarını atlar, özellik bayrakları varsayılan olarak açıktır. İnceleme ekibinde bunların hiçbiri yoktur. Apple'ın inceleme sayfası ayrıca "en son yazılımı çalıştıran cihazlarda kapsamlı test yapmanızı" ister; yani inceleme ekibi test telefonunuzdan daha yeni bir iOS kullanıyor olabilir.

İnceleme ekibinin ortamına en yakın şey TestFlight'tır. TestFlight genel bakış sayfasına göre App Store Connect ekibinizden en fazla 100 dahili test kullanıcısı ve en fazla 10.000 harici test kullanıcısı ekleyebilirsiniz. Bir derlemeyi 90 güne kadar test edebilirsiniz. Göndermeyi planladığınız derlemenin birebir aynısını yükleyin, TestFlight'tan uygulamayı hiç çalıştırmamış bir cihaza kurun ve o kopyayı test edin.

Yeniden göndermeden önce sürüm derlemesi test planı neleri kapsamalı?

Sürüm derlemesi test planı, uygulamayı ilk kez açan bir inceleme ekibinin takılabileceği her noktayı kontrol eder: açılış, izinler, giriş, arka uç, içerik, bağlantılar, satın almalar, ağ hataları ve iPad. Adımları TestFlight derlemesinde sırayla uygulayın ve her sonucu not edin; böylece inceleme notlarınızda bunlara atıf yapabilirsiniz.

1. En son iOS'ta temiz kurulum. Önceki kopyaları silin, TestFlight'tan kurun ve kayıtlı durum olmadan açın. Uygulamayı üç kez soğuk başlatın ve onboarding'in çökmediğini doğrulayın.
2. Her izin istemini bir kez reddedin. Bildirimleri, konumu, kamerayı ve izlemeyi reddedin. Uygulama yine de kullanılabilir bir ekrana ulaşmalıdır. Ayrıca Info.plist'te, uygulamanın veya SDK'larının kullandığı her korumalı kaynak için bir kullanım açıklaması olduğunu doğrulayın.
3. Birebir aynı demo bilgileriyle giriş yapın. Bilgileri parola yöneticinizden değil, App Store Connect'ten kopyalayın. Hesapta gerçekçi veriler bulunmalı, e-posta doğrulaması gerekmemeli ve kendi telefonunuza bağlı iki faktörlü kimlik doğrulama kullanılmamalıdır.
4. Arka ucun üretim ortamı olduğunu ve canlı olduğunu doğrulayın. Derleme üretim uç noktalarına işaret etmelidir. Hız sınırları, IP izin listeleri ve coğrafi engellemeler inceleme ekibini dışarıda bırakmamalıdır. Yönerge 2.1(a), arka uç hizmetinizi açmanızı söyler.
5. Her sekmeyi ve ekranı gezin. Lorem ipsum metinlerini, "Çok yakında" ekranlarını, açıklaması olmayan boş durumları, test görsellerini ve hiçbir şey yapmayan düğmeleri arayın.
6. Her bağlantıya dokunun. Gizlilik politikası, destek, kullanım koşulları ve tüm web görünümleri buna dahildir. Apple şöyle der: "Tüm uygulamalar için güncel iletişim bilgilerini içeren bir kullanıcı desteği bağlantısı ve gizlilik politikanıza bir bağlantı zorunludur."
7. Her uygulama içi satın almayı açın. Yeni bir hesapla giriş yapın. Sürümle birlikte gönderilen her ürünün fiyatıyla birlikte göründüğünü, sandbox'ta satın alınabildiğini ve Restore Purchases'ın (satın alımları geri yükleme) çalıştığını kontrol edin.
8. Yavaş veya kopuk bir ağda test edin. Bir akışın ortasında uçak modunu açın. Anlaşılır bir hata mesajı sorun değildir. Hiç durmayan bir yükleme göstergesi ya da çökme ise sorundur.
9. Destekliyorsanız iPad'i kontrol edin. Uygulama iPad'de çalışıyorsa orada da açın ve düzenin kullanıcıyı bir yerde sıkıştırmadığından emin olun.

3. adımdaki demo hesabı, diğer tüm adımlardan daha fazla tekrarlanan redde yol açar. App Store inceleme demo hesabı kurulumu rehberimiz, uzun süre sorunsuz çalışacak bir hesabın nasıl oluşturulacağını anlatıyor.

Bir 2.1 ret mesajını doğru düzeltmeyle nasıl eşleştirirsiniz?

Bir 2.1 reddini düzeltmeyle eşleştirmek için yönerge numarasından sonra gelen cümleyi okuyun. Bu cümle belirtiyi adlandırır ve her belirti test planındaki bir adıma karşılık gelir.

Bir alışkanlık takip uygulamasının "Uygulama açılışta çöktüğü için inceleyemedik" mesajıyla reddedildiğini varsayalım. İkinci bir not da inceleme ekibinin uygulama içi satın almaları bulamadığını söylüyor. Aşağıdaki tablo yaygın belirtileri bir neden, bir test ve bir düzeltmeyle eşleştiriyor.

Herhangi bir ret mesajını okumaya yönelik daha kapsamlı bir yöntem için App Store reddi: yönerge yönerge nasıl düzeltilir yazımıza bakın.

Diğer geliştiricilerin 2.1 retleri nasıl görünüyordu?

Herkese açık 2.1 vakaları aynı kalıbı izler. Uygulama geliştiricinin ortamında çalışır ve yalnızca temiz bir kurulumun ya da yabancı birinin girişinin ortaya çıkaracağı bir nedenle inceleme ekibinde başarısız olur.

• Eksik kullanım açıklamasından kaynaklanan çökme. Solar2D forumlarında bir geliştiriciye, uygulama TestFlight'ta çalışmasına rağmen iOS 18.3.2 çalıştıran bir iPhone 13 mini'de "Uygulama açılışta çöktüğü için inceleyemedik" denmişti. Başka bir üye, ekli çökme günlüğünde şunu buldu: "Bu uygulama, kullanım açıklaması olmadan gizliliğe duyarlı verilere erişmeye çalıştığı için çöktü." Geliştirici şöyle bildirdi: "NSUserTrackingUsageDescription ekledikten sonra onaylandı."
• İnceleme ekibinin kullanamadığı sosyal girişler. Apple Developer Forums'ta bir geliştirici, inceleme ekibi "sosyal girişleri kullanamadığı" için art arda 2.1 reddi aldığını bildirdi. Apple ve Google demo hesapları sağlamıştı, ancak Apple ID girişi geliştiricinin telefonuna gönderilen bir doğrulama kodu gerektiriyordu. Apple çalışanları, App Review'un kendisiyle doğrudan iletişime geçeceğini yanıtladı. Herkese açık bir çözüm paylaşılmadı.
• Uygulama içi satın almalar "gönderilen derlemede bulunamadı." Bir RevenueCat topluluk başlığında, sandbox satın almaları çalışmasına rağmen aylık bir plan derlemede bulunamadığı için reddedilen bir geliştirici vardı. Yardım eden biri, benzer bir reddin ödeme duvarına giden her yolu ayrıntılı biçimde anlatan bir açıklama ve ekran görüntüleriyle yanıt verilerek çözüldüğünü söyledi. RevenueCat çalışanları, gönderilen her ürünü varsayılan ödeme duvarında göstermeyi ve StoreKit test dosyalarını Archive şemasının dışında tutmayı önerdi.

Üç vakada da geliştiricinin kendi testleri başarılıydı. Hata yalnızca inceleme ekibinin başlangıç noktasından ortaya çıktı: 2FA telefonu yok, önceki oturum yok ve ödeme duvarının nerede olduğuna dair bilgi yok. Yukarıdaki test planı tam olarak bu başlangıç noktasını yeniden oluşturur.

2.1 reddinden sonra App Review notlarında ne yazmalı?

2.1 reddinden sonraki inceleme notları çalışan demo bilgilerini vermeli, reddedilen derlemeden bu yana nelerin değiştiğini listelemeli ve uygulama içi satın almaların ve kolay fark edilmeyen özelliklerin tam olarak nerede olduğunu belirtmelidir.

Apple'ın inceleme sayfası, hesap bilgilerini ve özel yapılandırmaları App Review Information bölümüne yazmanızı söyler. Bir özellik kurulumu zor bir donanım veya ortam gerektiriyorsa "bir demo videosu ya da donanımın kendisini sağlamaya hazır olun." Yönerge 2.3.1(a) ayrıca yeni özelliklerin Notes for Review bölümünde "ayrıntılı biçimde" açıklanması gerektiğini ve "genel açıklamaların reddedileceğini" ekler. Kısa ve yapılandırılmış bir not işe yarar:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Yasal veya güvenlik yükümlülükleri bir demo hesabını imkânsız kılıyorsa, yönerge 2.1(a) uygulamaya yerleşik bir demo moduna izin verir, ancak yalnızca Apple'ın önceden onayıyla; bu mod da uygulamanın tüm özelliklerini ve işlevselliğini göstermelidir. Bu onayı almadan demo moduna geçmeyin.

2.1 reddinden sonra nasıl yeniden gönderir veya itiraz edersiniz?

2.1 reddinden sonra yeniden göndermek için test ettiğiniz derlemeyi yükleyin veya seçin, App Store Connect'te App Review'a neleri değiştirdiğinizi yazarak yanıt verin, inceleme notlarını güncelleyin ve tekrar gönderin. Yalnızca inceleme ekibinin uygulamayı yanlış anladığını düşünüyorsanız itiraz edin.

1. App Store Connect'te sürüme bağlı derleme numarasının, test ettiğiniz TestFlight derlemesiyle aynı olduğunu kontrol edin.
2. Ret mesajına her düzeltmenin kısa bir özetiyle yanıt verin. Satın alma veya gezinme sorunlarında adım adım yönergeler ve ekran görüntüleri ekleyin.
3. App Review Information bölümünü güncel giriş bilgileri ve notlarla güncelleyin.
4. İncelemeye gönderin. Ekim 2026 itibarıyla Apple, genellikle "gönderimlerin en az %50'sini 24 saatten kısa, %90'ını 48 saatten kısa sürede" incelediğini belirtiyor.

Apple'ın hata yaptığını düşünüyorsanız App Review sayfası üzerinden App Review Board'a itiraz edebilirsiniz. Uygulamanın neden kurallara uyduğuna dair somut gerekçeler sunun ve "incelemeyi geçemeyen her gönderim için yalnızca bir itiraz gönderin." Yine de bir 2.1 reddinde sorunu temiz bir cihazda yeniden üretmek genellikle tartışmaktan daha hızlıdır. Yeniden gönderimi başkasına bırakmayı tercih ederseniz App Store gönderim hizmetimiz, her iki mağaza için inceleme hazırlığını ve ret geri bildirimlerini $599 karşılığında kapsar; geliştirici hesabı ücretleri buna dahil değildir.

2.1 sorunları sonraki güncellemelerde sıklıkla geri gelir: yeni bir özellik bayrağı, değiştirilmiş bir API anahtarı ya da süresi dolmuş bir demo hesabı. Bu test planını App Store gönderim kontrol listesiyle birlikte sürüm rutininize ekleyin. Güncellemelerde aşamalı yayın (phased release), gözden kaçan bir hatanın ulaşacağı kullanıcı sayısını sınırlar. Reddedilen bir derleme için ikinci bir görüş almak isterseniz ret mesajıyla birlikte yagyeshsrbobde@gmail.com adresine e-posta gönderin.