App Store Uygulamamı Reddetti: Sık Red Sebepleri ve Çözümleri (2026)

Kısa cevap: App Store'dan gelen red maili, uygulamanızın kötü olduğu anlamına gelmez. Redlerin çoğu birkaç tekrarlayan kuraldan çıkar: abonelik bilgisinin eksik olması, belirsiz bir izin metni, satın alma ekranındaki küçük bir davranış ya da boş kalmış bir form. Bunların önemli bir kısmı yeni sürüm bile gerektirmez; mağaza sayfasındaki bilgiyi düzeltip yeniden göndermek yeter.

Bu yazıyı kendi uygulamalarımızı App Store ve Google Play'de yayınlarken aldığımız redlerden derledik. Aşağıdaki sekiz App Store sorununun ve Google Play takılmalarının hepsini kendimiz yaşadık ve çözdük. Yaşamadıklarımızı ayrıca belirttik.

Red maili ne söylüyor?

Apple'ın inceleme ekibi reddi App Store Connect'teki mesaj alanına (Resolution Center) yazar. Mesajda bir yönerge numarası (örneğin 3.1.2 ya da 5.1.1) ve kısa bir açıklama bulunur. Numara, sorunun hangi kurala girdiğini gösterir; tam metni Apple'ın App Store İnceleme Yönergeleri sayfasında okuyabilirsiniz.

İlk soru şu: sorun mağaza bilgisinde mi, kodda mı? Mağaza bilgisi (metadata) açıklama, linkler ve ekran görüntüleri gibi alanlardır; aynı gün düzelir. Kod sorunu ise yeni bir build ister. Build, mağazaya yüklenen derlenmiş uygulama dosyasıdır; yenisi yüklenince inceleme baştan başlar.

Yaşadığımız App Store redleri: özet

1. Abonelikte Kullanım Koşulları linki yok

Mesaj: Uygulama otomatik yenilenen abonelik sunuyor ama mağaza bilgisinde çalışan bir Kullanım Koşulları (EULA, son kullanıcı lisans sözleşmesi) linki yok. Bu reddi QRistro'da aldık; abonelik ve satın alma redlerinin çoğu bu üründe yaşandı.

Neden: Yönerge 3.1.2, kullanıcının abone olmadan önce ne aldığını, kaç para ödediğini ve hangi koşullara bağlandığını açıkça görmesini istiyor.

Çözüm: App Store açıklamasına şunları ekleyin: Apple'ın standart EULA linki ya da kendi koşullarınız, gizlilik politikası linki, aboneliğin adı, süresi ve fiyatı, otomatik yenilendiği ve nasıl iptal edileceği. Sürüm reddedilmiş durumdayken açıklama düzenlenebiliyor; yeni build gerekmedi. Artık bu metni ilk gönderimde koyuyoruz.

2. Kullanıcı vazgeçince "Satın alma tamamlanamadı"

Mesaj: İnceleme ekibi abonelik butonuna basıp Apple'ın ödeme penceresini kapattı; uygulama "Satın alma tamamlanamadı" uyarısı gösterdi. Apple bunu çalışmayan bir satın alma olarak raporladı.

Neden: Kullandığımız satın alma altyapısı, kullanıcının vazgeçmesini teknik olarak hata kanalından bildiriyordu; uygulama da bunu gerçek hatadan ayırmıyordu.

Çözüm: Vazgeçmek hata değildir. Pencere sessizce kapanmalı, kullanıcı kaldığı ekrana dönmeli; uyarı yalnız gerçek bir ödeme sorununda çıkmalı. Kod değişikliği olduğu için yeni build gerekti.

3. "Satın alımları geri yükle" butonu yok

Yönerge 3.1.1, geri yüklenebilir satın alımlar (abonelik, kalıcı kilit açma gibi) için bir geri yükleme yolu istiyor. Telefonunu değiştiren ya da uygulamayı silip yeniden kuran kullanıcı, ödediği hakkı geri alabilmeli. Çözüm, ödeme ya da ayarlar ekranına bu butonu koymak. Daha sağlamı, hakkı sunucuda kullanıcının hesabına bağlamak: aynı hesapla giriş yapan kullanıcının aboneliği kendiliğinden döner. Yeni build ister.

4. İzin metni yetersiz bulundu

Kamera izni istenirken telefonda çıkan açıklama "Fotoğraf çekmek için kamera izni gerekir." idi. Apple bunu yönerge 5.1.1(ii) kapsamında reddetti: metin iznin adını tekrar ediyor, verinin ne için kullanılacağını söylemiyor. Yönerge, izin metninin veri kullanımını açık ve eksiksiz anlatmasını istiyor.

İyi bir metin üç şey içerir: uygulamanın işlevi, verinin ne için kullanıldığı ve bir örnek. Örnek metin: "Kameranızla çektiğiniz fotoğraf, seçtiğiniz stile dönüştürülmek üzere sunucumuza gönderilir; saklanmaz. Örneğin bir selfie çekip çizgi film karakterine çevirebilirsiniz." Bu metinler uygulamanın içine gömülü olduğu için yeni build gerekti. Kamera, fotoğraf arşivi, konum ya da mikrofon: hangi izni istiyorsanız aynı kural geçerli.

5. İlk abonelik tek başına gönderilemiyor

Red değil ama sık takılınan bir kural: uygulamanın ilk aboneliği, yeni bir uygulama sürümüyle aynı gönderimde incelemeye girmek zorunda. Apple'ın App Store Connect yardım sayfası da bunu böyle anlatıyor; ilk abonelik onaylandıktan sonra eklenenler sürümsüz gönderilebiliyor. Pratikte aboneliği hazırlamak yetmiyor, sürümün gönderim ekranında ona eklenmesi gerekiyor.

6. İnceleme ekibi ücretli içeriğe ulaşamıyor

Yönerge 2.1, giriş gerektiren uygulamalarda demo hesap bilgisi verilmesini ve uygulama içi satın alımların inceleme ekibine görünür ve çalışır olmasını istiyor. Biz demo hesabı sunucu tarafında kalıcı olarak ücretli plana alıyoruz; ekip satın almadan bütün özellikleri görebiliyor. Satın alma akışı da Apple'ın para çekmeyen test ortamında (sandbox) çalışmalı, çünkü ekip onu da deniyor. Demo hesap gönderim formuna yazıldığı için genelde yeni build gerekmez.

7. "İncelemeye eklenemedi": sessiz eksikler

Bu bir red değil; gönderim butonu çalışmıyor. Sebep çoğu zaman boş kalmış zorunlu bir alan ve uyarı her zaman hangi alan olduğunu açıkça söylemiyor. Bizim takıldıklarımız:

• Copyright alanı boş. Yıl ve sahip adı yazılmalı.
• App Privacy (gizlilik etiketi) doldurulmamış. Mağaza sayfasında görünen "hangi veriyi topluyoruz" beyanı. Reklamsız, ücretsiz bir uygulamada bile zorunlu; doldurduktan sonra ayrıca yayınlamak gerekiyor.
• Ekran görüntüleri yalnız bir dilde. Mağaza sayfası birden çok dilde açıldıysa görüntüler her dile yüklenmeli; ana dil boş kalırsa sürüm gönderilemiyor.
• Destek URL'si yok. Kullanıcının size ulaşabileceği çalışan bir sayfa şart.

Ekran görüntülerini nasıl hazırlamanız gerektiğini ASO rehberimizde anlattık.

8. Güncellemede aynı sürüm numarası

Yayındaki uygulamaya güncelleme gönderirken yeni dosya yayındaki sürümle aynı numarayı taşıyorsa (ikisi de 1.0.0 gibi) App Store kabul etmiyor. Üstelik yükleme aracı bunu açıklayıcı bir mesajla değil, genel bir hatayla bildirebiliyor. Çözüm: sürüm numarasını artırıp (1.0.1) yeniden derlemek. Google Play'de iç sürüm kodunun artması yetiyor.

Google Play tarafı

Google'da takılmalar daha çok formlardan ve izinlerden geliyor:

• Veri güvenliği (Data safety) formu. Hiç veri toplamayan uygulamalar dahil herkes doldurmak zorunda. Beyan uygulamanın gerçek davranışıyla örtüşmeli; Google bir uyumsuzluk fark ederse güncellemeleri engellemeye ya da uygulamayı kaldırmaya varan yaptırım uygulayabiliyor (Play Console Yardım, Ekim 2026). Bizim kuralımız: bu form, iOS gizlilik etiketi ve gizlilik politikası birebir aynı şeyi söyler.
• Hesap silme sayfası. Uygulamada hesap oluşturuluyorsa hem uygulama içinden silme yolu hem de uygulamayı açmadan erişilebilen bir web sayfası zorunlu (Google Play hesap silme şartları). Sayfa, silme adımlarını ve hangi verinin silindiğini anlatmalı.
• Geniş fotoğraf izni. Kullanıcının tek fotoğraf seçtiği bir uygulamamızda tüm galeriye erişim izni (READ_MEDIA_IMAGES) tanımlıydı ve Google gerekçe istedi. Politikaya göre sistemin fotoğraf seçicisi yetiyorsa bu izin istenemez. Çözüm izni kaldırmaktı; yeni build gerekti.
• "Uygulama içeriği" (App content) formları. Gizlilik politikası linki, içerik derecelendirmesi, hedef kitle ve reklam beyanı doldurulmadan yayın incelemesi başlamıyor.
• Kapalı test şartı. 13 Kasım 2023'ten sonra açılan kişisel geliştirici hesaplarında, yayına başvurmadan önce en az 12 test kullanıcısıyla, kesintisiz en az 14 gün süren kapalı test gerekiyor (Play Console Yardım, Ekim 2026). Şart kişisel hesaplar için tanımlı; kurum hesabımızda uygulamaları doğrudan yayına gönderebiliyoruz.

Yaşamadığımız ama sık duyulan iki red

Bu ikisini kendi ürünlerimizde almadık; yine de sık karşılaşılan redler:

• Uygulama içinden hesap silme (5.1.1(v)). Hesap oluşturulabilen her uygulama, hesabı silme imkânını da uygulamanın içinde sunmak zorunda.
• Web sitesini uygulama kabuğuna sarmak (4.2). Yönerge, uygulamanın "yeniden paketlenmiş bir web sitesinin" ötesine geçen özellik, içerik ve arayüz sunmasını istiyor. Sitenizi olduğu gibi gösteren bir uygulama bu maddeden dönme riski taşır.

Göndermeden önce kontrol listesi

• Abonelik varsa açıklamada EULA ve gizlilik linkleri ile abonelik koşulları var.
• Satın almadan vazgeçmek hata mesajı göstermiyor.
• "Satın alımları geri yükle" butonu var; hak sunucuda hesaba bağlı.
• Her izin metni verinin ne için kullanıldığını bir örnekle anlatıyor.
• İlk abonelik, uygulama sürümüyle aynı gönderimde.
• Demo hesap ve inceleme notu yazıldı; test ortamında satın alma çalışıyor.
• Copyright, yayınlanmış gizlilik etiketi, destek URL'si ve her dilde ekran görüntüsü tamam.
• Güncellemede sürüm numarası artırıldı.
• Hesap oluşturuluyorsa uygulama içinden silme ve web'den silme sayfası var.
• Google'da veri güvenliği formu iOS etiketiyle aynı, uygulama içeriği formları dolu, gereksiz izin yok.

Uygulamayı yaptırırken firmaya sorulacak 3 soru

1. Mağaza hesapları kimin adına açılacak? Apple ve Google geliştirici hesapları şirketiniz adına olmalı. Uygulama firmanın hesabından yayınlanırsa, ileride taşımak zahmetli olur. Google'da hesabın kişisel mi kurumsal mı açıldığı, kapalı test şartı yüzünden yayın tarihini de etkiler.
2. Red gelirse süreci kim yönetiyor? Red mailine cevap yazmak, düzeltmeyi yapmak ve yeniden göndermek teklifin içinde mi, yoksa "yayınlamayı siz yaparsınız" mı deniyor?
3. Kaç uygulamayı mağazadan geçirdiniz? Yayındaki uygulamaların linkini isteyin. Bu redleri daha önce yaşamış bir ekip, çoğunu ilk gönderimden önce eler.

Firma seçiminin diğer kriterlerini mobil uygulama firması seçim rehberinde, sürecin tamamını mobil uygulama yaptırma rehberinde bulabilirsiniz.

Sonuç

Red maili bir hüküm değil, bir düzeltme listesi. Önce sorunun mağaza bilgisinde mi kodda mı olduğunu ayırın: mağaza bilgisindeyse aynı gün düzelir, koddaysa yeni build gerekir. Redlerin çoğu aynı birkaç kuraldan geldiği için en ucuz çözüm, onları gönderimden önce bir kontrol listesiyle elemek.

Uygulamanızın mağaza sürecini baştan birlikte planlamak isterseniz mobil uygulama geliştirme sayfamıza göz atabilirsiniz.