App Store uygulamayı neden reddeder? En sık 10 neden

App Store bir uygulamayı, Apple’ın App Review Guidelines belgesindeki bir maddeye uymadığında reddeder. Apple’ın kendi açıklamasına göre çözülmemiş sorunların ortalama yüzde 40’tan fazlası tek bir maddeyle, 2.1 Uygulama Bütünlüğü ile ilgilidir: çökme, yer tutucu içerik, eksik bilgi. Kalan nedenlerin çoğu mağaza metni, gizlilik ve satın alma kurallarından gelir.

Yayın sürecinin tamamını, yani geliştirici hesabından TestFlight’a kadar olan adımları App Store’a uygulama yükleme yazımızda anlattık. Bu yazı başka bir soruya odaklanıyor: ret mektubu geldiğinde hangi madde ne anlama gelir ve bir dahaki sefere nasıl önlenir? Madde numaralarını Ekim 2026’da Apple’ın yayımladığı sürümden doğruladık.

Ret mektubu nasıl okunur?

Ret mektubu her zaman bir madde numarasıyla başlar; önce o numarayı bulun. App Store Connect’teki ret mesajında “Guideline 2.1 - Performance - App Completeness” gibi bir satır, ardından inceleyenin gördüğü sorun ve çoğu zaman bir ekran görüntüsü yer alır.

Bir ret geldiğinde üç şeye bakmanızı öneririz:

1. Madde numarası. Sorunun hangi kural ailesine ait olduğunu söyler. 2.x performans ve mağaza bilgisi, 3.x iş modeli, 4.x tasarım, 5.x gizlilik ve hukuktur.
2. İnceleyenin cihazı ve adımları. Ret çoğu zaman belirli bir iPad modelinde ya da belirli bir akışta görülen sorundur. Aynı adımları aynı cihaz türünde tekrarlamadan düzeltmeye girişmemek gerekir.
3. Düzeltme mi, açıklama mı? Bazen uygulama doğrudur ama inceleyen bir özelliği bulamamıştır. Bu durumda kodu değiştirmek yerine inceleme notunu düzeltmek yeterlidir.

Apple’ın App Review sayfasına göre başvuruların en az yarısı 24 saatten kısa sürede, yüzde 90’ı 48 saatten kısa sürede incelenir. Yani doğru okunmuş bir ret, genellikle birkaç gün içinde kapanır.

En sık 10 ret nedeni ve madde numaraları

Aşağıdaki liste, Apple’ın “sık karşılaşılan sorunlar” başlığı altında saydığı konulara ve yönergelerdeki ilgili maddelere dayanıyor. Sıralama, Apple’ın verdiği oranı ve bizim bakışımızı yansıtıyor.

1. Çöken ya da yarım kalmış uygulama (2.1)

2.1(a) maddesi, incelemeye gönderilen sürümün “son sürüm” olmasını, yer tutucu metinlerin ve geçici içeriğin temizlenmiş olmasını ister. “Yakında” yazan bir buton, boş bir ekran ya da inceleyenin cihazında bir çökme bu maddeye girer. Apple’a göre ret nedenlerinin en büyük payı buradadır.

2. Demo hesap verilmemesi (2.1)

Uygulama giriş gerektiriyorsa, inceleyenin kullanabileceği bir demo hesap ve çalışan bir sunucu gerekir. Hesap yoksa ya da şifre çalışmıyorsa inceleme orada durur. Hesap istemeyen bir uygulamada bu madde hiç doğmaz. Tako’yu böyle kurmamızın nedenlerinden birini ayrı bir atölye notunda anlattık.

3. İnceleyenin bulamadığı satın alma (2.1(b))

Uygulama içi satın almalar inceleme sırasında görünür ve çalışır olmalıdır. Satın alma ekranı bir ayarın arkasındaysa ya da yalnız belli bir koşulda açılıyorsa, inceleme notunda nasıl ulaşılacağını yazmak gerekir.

4. Belirsiz inceleme notu (2.3.1(a))

Yeni özellikler, inceleme notunda “özgül biçimde” anlatılmalıdır; Apple genel açıklamaların reddedileceğini açıkça yazar. “Hata düzeltmeleri ve iyileştirmeler” notu, büyük bir güncellemede sorun çıkarabilir.

5. Uygulamayı göstermeyen ekran görüntüleri (2.3.3)

Ekran görüntüleri uygulamayı kullanılırken göstermelidir; yalnız logo, giriş ya da açılış ekranı yetmez. Görüntüleri çerçevelemek ve üzerine başlık yazmak serbesttir. Gösterilen ekran ise uygulamada gerçekten bulunmalıdır.

6. Ad ve anahtar kelime doldurma (2.3.7)

Uygulama adı en fazla 30 karakterdir ve marka adları, popüler uygulama adları ya da fiyat bilgisiyle doldurulamaz. 2.3.10 da başka mobil platformların adını ve görselini mağaza metninde kullanmayı yasaklar. “Android’de de var” cümlesi bu maddeye takılır.

7. Eksik ya da yanlış gizlilik politikası (5.1.1(i))

Gizlilik politikası hem App Store Connect’te hem uygulamanın içinde bağlantı olarak bulunmalıdır. Hangi verinin toplandığını, üçüncü taraflarla paylaşılıp paylaşılmadığını, ne kadar saklandığını ve nasıl silineceğini anlatmalıdır. Reklam ya da analitik kütüphanesi eklendiğinde politika güncellenmezse beyan ile uygulama ayrışır.

8. Gerekçesiz izin istekleri (5.1.1(ii) ve (iv))

Kamera, konum ya da kişiler izni istenirken açıklama metni verinin ne için kullanılacağını açıkça söylemelidir. İzni reddeden kullanıcıya alternatif sunmak da beklenir. Kullanıcı uygulamalar arasında takip ediliyorsa 5.1.2 gereği App Tracking Transparency penceresi gösterilmelidir.

9. Hesap oluşturuluyor ama silinemiyor (5.1.1(v))

Uygulama hesap oluşturmaya izin veriyorsa, hesap silme de uygulamanın içinden yapılabilmelidir. Aynı madde, hesaba dayalı önemli bir özellik yoksa uygulamanın girişsiz kullanılmasını ister. Bu madde sık atlanır; çünkü hesap silme çoğu zaman sunucu tarafında ayrı bir iş demektir.

10. Asgari işlev ve benzer uygulamalar (4.2, 4.3)

4.2.2 maddesi, uygulamanın esas olarak pazarlama malzemesi, web sitesi kesiti ya da bağlantı derlemesi olmamasını ister. 4.3 ise aynı uygulamayı farklı paket kimlikleriyle defalarca göndermeyi spam sayar. Şablonla üretilmiş, birbirine çok benzeyen uygulamalar bu maddeye takılır.

Hangi maddeyi nasıl önlersiniz?

Her ret nedeninin bir önlemi vardır ve çoğu başvurudan önce on dakikalık bir kontrolle yakalanır. Aşağıdaki tabloyu başvurudan önce bir kontrol listesi olarak kullanmanızı öneririz.

Madde	Ret gerekçesi	Başvurudan önce önlem
2.1(a)	Çökme, yer tutucu içerik	Temiz kurulumla gerçek cihazda baştan sona deneme
2.1	Demo hesap yok	İnceleme notuna kullanıcı adı, şifre ve kısa yönerge
2.1(b)	Satın alma bulunamadı	Satın alma ekranına giden yolu nota yazmak
2.3.1(a)	Genel inceleme notu	Yeni her özelliği tek tek adıyla anlatmak
2.3.3	Uygulamayı göstermeyen görüntü	Görüntüleri güncel sürümden almak
2.3.7, 2.3.10	Ad ve anahtar kelime doldurma	Adı 30 karakterde tutmak, başka platform adı kullanmamak
5.1.1(i)	Gizlilik politikası eksik	Politikayı her yeni kütüphaneyle birlikte güncellemek
5.1.1(ii)	Gerekçesiz izin	Her izin için açık bir amaç metni
5.1.1(v)	Hesap silinemiyor	Hesap silmeyi ilk sürümde kurmak ya da hesabı kaldırmak
4.2, 4.3	Asgari işlev, kopya	Mobile özgü değeri tek cümleyle yazabilmek

Abonelik ya da dijital içerik satıyorsanız 3.1.1 ve 3.1.2 maddeleri de devreye girer. Satın alınan şeyin geri yüklenebilmesi, aboneliğin ne verdiğinin açıkça yazılması bunlardan ikisi. Konuyu uygulama içi satın alma ve abonelik yazısında ayrıca ele alıyoruz.

Sağlık ve finans uygulamalarında ek bir koşul

5.1.1(ix) maddesi, bankacılık, finans, sağlık, kumar ve benzeri düzenlenmiş alanlarda hizmet veren uygulamaların bireysel geliştirici tarafından değil, o hizmeti veren tüzel kişi tarafından gönderilmesini ister. Apple bunu “yanlış kişi tarafından gönderilmiş” sorunu olarak listeler.

Bu yüzden bir klinik ya da finans kuruluşu için uygulama geliştirilecekse, geliştirici hesabının kurum adına açılmasını en başta konuşmanızı öneririz. Hesap açılışı ve kurumsal doğrulama zaman aldığından, bu adımı tasarımla paralel yürütmek takvimi korur. Bütçe ve takvim planlamasına etkisini mobil uygulama maliyetini belirleyen faktörler yazısında anlattık.

Ret geldiğinde ne yapılır?

Ret kalıcı değildir; düzeltip yeniden gönderebilir ya da itiraz edebilirsiniz. Önerdiğimiz sıra şu:

1. Ret mesajını ve ekran görüntüsünü madde numarasıyla birlikte okuyun.
2. Sorunu, inceleyenin kullandığı cihaz türünde tekrarlayın.
3. Sorun gerçekse düzeltin; yeni sürümün inceleme notunda neyi değiştirdiğinizi yazın.
4. Sorun bir yanlış anlamaysa App Store Connect üzerinden inceleme ekibine kısa ve somut bir açıklama gönderin.
5. Gerekçeye hâlâ katılmıyorsanız App Review Board’a itiraz edin. Apple, her ret için tek itiraz ve uygulamanın yönergelere neden uyduğuna dair somut gerekçe ister.

Uygulaması zaten yayında olan geliştiriciler için bir kolaylık da var. Apple, yasal ya da güvenlik sorunu yoksa hata düzeltme sürümlerini yönerge ihlali yüzünden bekletmez. Bunun için inceleme ekibine sorunu bir sonraki sürümde gidereceğinizi bildirmeniz gerekir.

Başvurudan önce neye bakılmalı?

Bizim bakışımız şu: ret nedenlerinin çoğu hazırlıkla ilgili olduğu için kontrol, kod bitince değil, tasarım aşamasında başlamalı. Hesap gerekecek mi, hangi izinler istenecek, satın alma nerede duracak? Bu üç sorunun cevabı, sonradan çıkacak ret nedenlerinin yarısını belirliyor.

Tako ve Mümin 360 başvurularında bu sorulara erken cevap vermek işimizi sadeleştirdi. Tako hesap istemediği için demo hesap ve hesap silme maddeleri hiç gündeme gelmedi. Güncellemelerde de inceleme notunu sürüm notundan ayrı, özellik özellik yazmanızı öneririz. İlk başvuru öncesi için tam kontrol listesini yayın süreci yazımızda bulabilirsiniz.

Sık sorulan sorular

App Store en çok hangi nedenle reddediyor?

Apple’ın açıkladığı verilere göre çözülmemiş sorunların ortalama yüzde 40’tan fazlası 2.1 Uygulama Bütünlüğü maddesiyle ilgilidir. Çökmeler, yer tutucu içerik ve eksik bilgi bu maddenin kapsamındadır. Temiz kurulumla gerçek cihazda yapılan bir deneme, bu nedenlerin çoğunu yakalar.

Ret, uygulamanın bir daha kabul edilmeyeceği anlamına gelir mi?

Hayır. Ret mesajındaki sorunu giderip aynı uygulamayı yeniden gönderebilirsiniz. Gerekçeye katılmıyorsanız önce inceleme ekibine açıklama yapabilir, ardından App Review Board’a itiraz edebilirsiniz. Aynı maddeden art arda gelen retler ise sonraki incelemeleri uzatabilir.

Hesap gerektirmeyen bir uygulama daha kolay mı onaylanır?

Onay garantisi yoktur; ama birkaç ret nedeni hiç doğmaz. Demo hesap verme ve uygulama içinden hesap silme yükümlülükleri yalnız hesap oluşturan uygulamalar için geçerlidir. 5.1.1(v) maddesi de hesaba dayalı önemli bir özellik yoksa girişsiz kullanımı ister.

Ekran görüntülerinde tasarım ve yazı kullanabilir miyim?

Kullanabilirsiniz. 2.3.3 maddesi, görüntülerin uygulamayı kullanılırken göstermesini ister; çerçeve, arka plan ve kısa başlıklar buna engel değildir. Gösterilen ekranın uygulamanın güncel sürümünde bulunması gerekir.

Güncellemeler de reddedilebilir mi?

Evet, her yeni sürüm incelemeden geçer. Bu yüzden ilk başvurudaki kontrolleri her güncellemede tekrarlamanızı öneririz. Uygulama yayındaysa ve sorun yasal ya da güvenlikle ilgili değilse, Apple hata düzeltme sürümlerini bekletmeme yolunu da sunar.

Uygulamanızı App Store’a hazırlarken mağaza kurallarını baştan hesaba katan bir ekip arıyorsanız, nasıl çalıştığımızı mobil uygulama geliştirme sayfamızda bulabilir ya da bize yazabilirsiniz. Platform seçimi henüz netleşmediyse iOS mu Android mi yazısı iyi bir başlangıç.