App Store Uygulama Reddi ve Google Play Red Nedenleri

App Store uygulama reddi vakalarının büyük bölümü dört başlıkta toplanır: eksik veya çöken uygulama (Guideline 2.1), spam-kopya içerik (4.3), yetersiz işlevsellik (4.2) ve gizlilik ihlali (5.1.1). Apple 2025'te 2 milyondan fazla başvuruyu geri çevirdi; bunların 443.000'i yalnızca gizlilik gerekçeliydi.

Red mesajı, çoğu ekibin lansman takvimini ilk kez ciddiye aldığı andır. Ekip haftalarca kod yazar, tasarımı defalarca revize eder, sonra tek bir Resolution Center bildirimi tüm planı bir sonraki aya taşır. İyi haber şu: red gerekçelerinin çoğu önceden tahmin edilebilir.

Bu rehberde App Store uygulama reddi ile Google Play politika ihlallerinin gerçek nedenlerini, her biri için somut düzeltme adımlarını, itiraz sürecini ve yayın öncesi kontrol listesini bulacaksınız. Verilerin tamamı Apple ve Google'ın 2025-2026 dönemi resmi açıklamalarına dayanır.

İçindekiler

• Red Nedenleri Bir Bakışta
• Mağazalar 2026'da Neyi Sıkılaştırdı?
• App Store Uygulama Reddi: En Sık Görülen 8 Gerekçe
• Google Play Politika İhlalleri
• Red Bildirimi Geldikten Sonraki İlk 24 Saat
• İtiraz Süreci: Resolution Center ve App Review Board
• Tekrarlanan İhlaller ve Hesap Kapatma Riski
• Yayın Öncesi Kontrol Listesi
• Sıkça Sorulan Sorular

Red Nedenleri Bir Bakışta

Aşağıdaki tablo, iki mağazada en çok karşılaşılan gerekçeleri ve tipik düzeltme yükünü özetler. Süreler, ekibin sorunu doğru teşhis ettiği varsayımıyla verilmiştir.

Tablodaki kalemlerin ortak paydası dikkat çeker: hiçbiri doğrudan kod kalitesine bakmaz. App Store uygulama reddi çoğu zaman mükemmel çalışan bir üründe bile ortaya çıkar, çünkü beyan ile davranış arasındaki en küçük tutarsızlık redle sonuçlanır.

Mağazalar 2026'da Neyi Sıkılaştırdı?

Apple, Haziran 2026'da inceleme kılavuzunu güncelleyerek düşük katma değerli uygulamalara karşı dili sertleştirdi. Flaş ışığı, duvar kağıdı, basit zamanlayıcı, fal ve benzeri doygun kategorilerde yeni başvurular artık "anlamlı biçimde farklı veya geliştirilmiş bir deneyim" sunmadıkça kabul görmüyor. MacRumors'ın aktardığı düzenleme, 4.3 maddesine yayın sonrası kaldırma yetkisi de ekledi.

Apple tarafındaki ölçek, kuralların ne kadar agresif uygulandığını gösteriyor. Şirketin 2025 dolandırıcılık önleme raporuna göre 1,2 milyon yeni uygulama ve yaklaşık 800.000 güncelleme reddedildi. Aynı raporda 371.000 başvuru kopya, spam veya yanıltıcı bulundu; 22.000 başvuru gizli ve belgelenmemiş özellik içerdiği için elendi. Apple ayrıca 193.000 geliştirici hesabını dolandırıcılık şüphesiyle kapattı.

Google cephesinde tablo farklı işliyor ama sonuç benzer. Google'ın 2025 güvenlik değerlendirmesine göre 1,75 milyondan fazla politika ihlalli uygulama yayına giremedi, 80.000'den fazla geliştirici hesabı yasaklandı ve 255.000 uygulama hassas verilere aşırı erişimden engellendi. Google, yayınladığı her uygulama üzerinde 10.000'den fazla güvenlik kontrolü çalıştırdığını ve inceleme sürecine üretken yapay zeka modellerini entegre ettiğini belirtiyor.

Pratik sonuç şu: otomatik tarama katmanı büyüdükçe, "geçen sefer sorun çıkmamıştı" savunması işlevini yitiriyor. Aynı binary, altı ay sonra yeni bir tarama kuralına takılabiliyor.

App Store Uygulama Reddi: En Sık Görülen 8 Gerekçe

Apple'ın red mesajları kılavuz numarasıyla gelir. Numarayı doğru okumak, düzeltmenin yarısıdır — çünkü her madde farklı bir kanıt bekler. App Review Guidelines belgesinin ilgili maddesini açmadan yanıt yazmayın.

Guideline 2.1 — Uygulama Eksik veya Çöküyor

En yaygın gerekçe budur ve genellikle en kolay düzeltilenidir. İnceleme uzmanı uygulamayı açar, bir yerde takılır ve süreci sonlandırır. Çökme, boş liste ekranı, sonsuz yüklenme animasyonu ve çalışmayan demo hesabı bu maddenin klasik tetikleyicileridir.

Düzeltme için üç şeyi garanti altına alın. Birincisi, süresi dolmayan bir demo hesabı verin ve şifreyi App Store Connect'teki inceleme notlarına yazın. İkincisi, o hesabın içini gerçekçi veriyle doldurun; boş bir panel "eksik uygulama" izlenimi yaratır. Üçüncüsü, ödemeli veya davetle açılan bölümler varsa erişim yolunu adım adım tarif edin.

Uygulamanız donanım, konum veya operatör bağımlı çalışıyorsa bunu da yazın. İnceleme ekibi Kaliforniya'daki bir cihazdan bakar; Türkiye'ye özel bir doğrulama akışı orada sessizce başarısız olabilir.

Guideline 4.3 — Spam ve Kopya Uygulama

4.3(a) maddesi, birbirinin neredeyse aynısı olan çoklu gönderimleri hedefler. Klasik örnek, aynı şablonun her şehir veya her bayi için ayrı bundle ID ile yayınlanmasıdır. Türkiye'de bu kalıba özellikle zincir işletme ve emlak ofisi projelerinde rastlanır.

4.3(b) ise doygun kategorilerdeki tekdüze başvuruları kapsar. Bu maddeye takılan bir uygulamayı kurtarmanın tek yolu, gerçekten farklı bir işlev katmanı eklemektir. Yeni bir ikon veya renk paleti yeterli gelmez.

Çoklu marka ihtiyacı olan işletmeler için doğru yaklaşım tek uygulama ve hesap bazlı içeriktir. Kullanıcı giriş yapar, kendi şubesinin verisini görür; mağazada tek kayıt durur. Bu mimari hem 4.3 riskini bitirir hem de güncelleme yükünü tek koda indirir.

Guideline 4.2 — Yetersiz İşlevsellik

Bu madde, web sitesini WebView içine koyup mağazaya gönderen projeleri durdurur. Apple'ın standart ifadesi nettir: deneyim, Safari'de gezinmekten yeterince farklı değildir. Yalnızca push bildirimi eklemek de bu eşiği aşmaz.

Kurtarma reçetesi native katmanı gerçekten kurmaktan geçer. Native sekme çubuğu, çevrimdışı durum yönetimi, cihaz kamerası veya biyometrik giriş gibi tarayıcının yapamayacağı işler devreye girmelidir. Ürün ekibiyle birlikte "bu uygulama tarayıcıda neden çalışmaz?" sorusuna tek cümlelik bir yanıt üretemiyorsanız, 4.2 riski sürüyor demektir.

Web tabanlı bir ürünü mobile taşıma kararını verirken mobil uygulama geliştirme yaklaşımını en baştan native hedeflerle kurgulamak, sonradan yapılacak kapsamlı revizyondan çok daha ucuza gelir.

Guideline 5.1.1 — Veri Toplama ve Gizlilik

Apple, çekirdek işlevle ilgisi olmayan kişisel veriyi zorunlu tutmanızı yasaklar. Vitrin uygulamasında zorunlu telefon doğrulaması, tarif uygulamasında zorunlu doğum tarihi bu maddeye takılır. Kayıt olmadan da denenebilen bir "misafir" akışı çoğu vakayı çözer.

İkinci sık hata izin metinlerindedir. Konum, kamera veya rehber izni isterken gösterdiğiniz purpose string, verinin ne için kullanıldığını açıkça yazmalıdır. "Uygulamanın çalışması için gereklidir" cümlesi kabul görmez.

Üçüncü kalem gizlilik politikasıdır. Politika URL'si çalışmalı, hangi verinin toplandığını, kimlerle paylaşıldığını ve kullanıcının silme talebini nasıl ileteceğini yazmalıdır. Türkiye'den yayın yapan ekipler için buraya KVKK aydınlatma metnini de eklemek, hem mağaza hem yerel mevzuat tarafını aynı anda kapatır.

Guideline 2.3 — Yanıltıcı Metadata

Bu red türü binary'ye dokunmaz; mağaza kaydını düzeltip aynı sürümü yeniden gönderirsiniz. Ekran görüntüsünde var olmayan bir özelliğin gösterilmesi, açıklamada geçen "yapay zeka destekli" ifadesinin karşılığının bulunmaması ya da görsellerde başka mağaza logolarının yer alması tipik tetikleyicilerdir.

Ekran görüntüleri uygulamanın gerçek arayüzünü göstermelidir. Açılış ekranı, giriş formu veya tasarım konsepti mockup'ları bu şartı karşılamaz. Metin ile ürün arasındaki her abartı, incelemede maliyet doğurur.

Guideline 3.1.1 — Uygulama İçi Satın Alma

Dijital içerik, abonelik ve uygulama içi para birimi Apple'ın satın alma altyapısını gerektirir. Fiziksel ürün ve gerçek dünya hizmeti ise tam tersine kendi ödeme altyapınızı ister. Türkiye'deki e-ticaret ekipleri için ayrım pratikte şöyle işler: mağazanızdan ayakkabı satıyorsanız iyzico veya PayTR akışınız sorunsuz geçer, aynı uygulamada premium üyelik satıyorsanız o kalem IAP'ye taşınmalıdır.

Mayıs 2025'teki mahkeme kararının ardından ABD vitrininde harici satın alma bağlantılarına izin verildi. Ancak bu istisna bölgeseldir. Bölge kontrolü koymadan tüm vitrinlerde harici bağlantı gösteren uygulamalar hâlâ reddediliyor.

Guideline 4.8 — Giriş Servisleri

Uygulamanız Google, Facebook veya benzeri bir üçüncü taraf girişi sunuyorsa, eşdeğer bir seçenek olarak Sign in with Apple da bulunmalıdır. Eşdeğerlik şartı teknik ayrıntı içerir: alternatif yöntem yalnızca ad ve e-posta toplamalı, kullanıcıya e-postasını gizleme imkânı vermeli ve rıza olmadan reklam amaçlı veri toplamamalıdır.

Yalnızca kendi e-posta/şifre sisteminizi sunuyorsanız bu madde devreye girmez. Buton yerleşimi ve stilinin Apple'ın tasarım şartlarına uyması da ayrıca denetlenir.

Guideline 5.2 — Fikri Mülkiyet

Marka, logo, karakter veya lisanslı içerik kullanıyorsanız yetki belgesini önceden hazırlayın. İnceleme ekibi bu maddede genellikle kanıt ister; belge geldiğinde süreç hızlı kapanır. Belge yoksa itiraz da işe yaramaz.

Kurumsal projelerde sık görülen bir tuzak, uygulamayı ajans hesabından yayınlarken marka sahibinin farklı bir tüzel kişi olmasıdır. Bu durumda marka sahibinden alınmış yazılı izin, red riskini baştan siler.

Google Play Politika İhlalleri

Google'ın süreci Apple'dan iki noktada ayrılır. Birincisi, ilk gönderimde red oranı daha düşüktür ama yayın sonrası denetim çok daha serttir; uygulamanız aylar sonra kaldırılabilir. İkincisi, bildirimler kılavuz numarası yerine politika adıyla gelir.

Veri Güvenliği Formu Uyuşmazlığı

Play Console'daki Veri güvenliği formu, uygulamanın gerçek davranışıyla birebir örtüşmelidir. Google binary'yi tarar ve beyanla karşılaştırır. En sık atlanan nokta üçüncü taraf SDK'lardır: analiz, reklam veya çökme raporlama kütüphanesi veri topluyorsa bunu siz toplamış sayılırsınız.

Formu doldurmadan önce SDK envanterinizi çıkarın. Her kütüphanenin hangi veri kategorisine dokunduğunu listeleyin, gizlilik politikanızı bu listeyle eşleyin. Form, politika metni ve uygulamanın izin talepleri üçlüsü aynı hikâyeyi anlatmalıdır.

Hassas İzinler ve Arka Plan Konumu

Arka plan konumu, SMS, çağrı kaydı ve tüm yüklü uygulamaları listeleme izni kısıtlı kategoridedir. Her biri için Play Console'da izin beyan formu doldurulur ve iznin çekirdek işlev için neden zorunlu olduğu açıklanır. Gizlilik dostu bir alternatifin neden yetmediğini de yazmanız gerekir.

Bu formlarda en etkili kanıt, izin akışını gösteren kısa bir demo videosudur. Video, kullanıcının hangi ekranda hangi faydayı gördüğünü kanıtlar ve inceleme turlarını kısaltır.

Bozuk İşlevsellik ve Kilitlenmeler

Google'ın "Broken Functionality" politikası, temel akışı tamamlamayan uygulamaları kapsar. Yüklenmeyen ekran, geri dönmeyen buton, boş kalan liste ve ilk açılışta kapanan uygulama bu başlığa girer. Pre-launch report'u okumadan yayına göndermek, bu redde davetiye çıkarır.

Hedef API Seviyesi ve Kapalı Test

Google'ın hedef API seviyesi şartına göre 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler Android 16 (API 36) hedeflemelidir. Mevcut uygulamalar için eşik Android 15 (API 35). Ek süreye ihtiyaç duyan ekipler 1 Kasım 2026'ya kadar tek seferlik uzatma talep edebilir.

13 Kasım 2023'ten sonra açılmış kişisel geliştirici hesapları için ayrı bir şart daha geçerli. Play Console'un test kuralı uyarınca üretim erişimi öncesinde en az 12 test kullanıcısının 14 gün boyunca kesintisiz kapalı testte kalması gerekiyor. Kurumsal (organization) hesaplar bu şartın dışında. Türkiye'den yayın yapan çoğu işletme için doğru hamle, en baştan şirket hesabı açmak ve D-U-N-S numarasını erkenden temin etmektir.

Bu adımların tamamını sırasıyla görmek isterseniz mobil uygulama nasıl yayınlanır rehberimiz hesap açılışından mağaza onayına kadar süreci anlatıyor.

Red Bildirimi Geldikten Sonraki İlk 24 Saat

Panik, red maliyetini artıran tek unsurdur. Aşağıdaki sıra, gereksiz tur sayısını azaltır.

1. Mesajı sonuna kadar okuyun. Apple genellikle ekran görüntüsü veya video ekler. Ekteki kanıt, sorunun hangi ekranda çıktığını doğrudan gösterir.
2. Kılavuz numarasını açın. Aynı numaranın alt maddeleri farklı çözümler ister; 2.3.3 ile 2.3.10 arasındaki fark, ekran görüntüsü ile platform ismi kadar uzaktır.
3. Redin türünü belirleyin. Metadata reddi ise yeni binary gerekmez; mağaza kaydını düzeltip aynı sürümü yeniden gönderirsiniz. Binary reddi yeni bir yükleme ve yeni bir inceleme turu demektir.
4. Tek seferde tam düzeltme yapın. Yarım çözümle dönmek, ikinci turda ek maddelerin açılmasına yol açar.
5. Resolution Center'a somut yanıt yazın. Neyi değiştirdiğinizi madde madde yazın, ekran görüntüsü ekleyin, gerekiyorsa 30 saniyelik ekran kaydı paylaşın.
6. Yayın tarihini yeniden planlayın. Apple ortalamada başvuruların yüzde 90'ını 24 saatten kısa sürede inceler, ancak yeniden gönderim yeni bir inceleme penceresi açar. Reklam ve basın takvimini buna göre kaydırın.

İtiraz Süreci: Resolution Center ve App Review Board

Vakaların büyük çoğunluğu itiraz gerektirmez. Reviewer haklıysa düzeltip yeniden göndermek her zaman daha hızlıdır. İtiraz, yalnızca kılavuzun yanlış uygulandığını düşündüğünüzde anlamlıdır.

Apple'ın resmi akışı iki katmanlıdır. Önce Resolution Center üzerinden yanıt verirsiniz; buradaki yazışma çoğu yanlış anlaşılmayı çözer. Sonuç alamazsanız App Review Board'a başvurabilirsiniz. Apple, her başarısız gönderim için tek itiraz hakkı tanır ve ek bilgi taleplerine yanıt vermeden itiraz açılmamasını ister.

İtiraz metninde üç unsur bulunmalıdır: kılavuz maddesinin numarası, uygulamanın bu maddeye neden uyduğunun olgusal açıklaması ve kanıt. Kanıt olarak ekran kaydı, lisans belgesi, mimari şema veya kullanıcı akış diyagramı kullanabilirsiniz. Duygusal dil ve ticari kayıp vurgusu sonucu değiştirmez.

Google tarafında itiraz, Play Console içindeki uygulama durumu ekranından yapılır. Politika ihlali bildirimindeki bağlantı doğrudan itiraz formuna gider. Burada da en güçlü argüman, ihlal iddiasını çürüten teknik kanıttır.

Tekrarlanan İhlaller ve Hesap Kapatma Riski

Tekil red, geliştirici hesabınıza kalıcı bir iz bırakmaz. Tekrarlayan ve aynı konudaki ihlaller ise farklı bir kategoridedir. Apple 2025'te 193.000 geliştirici hesabını kapattı, Google ise 80.000'den fazla hesabı yasakladı. Bu rakamların ardında ağırlıklı olarak kasıtlı ve tekrarlanan ihlaller yatıyor.

Riski yöneten en basit kural, red mesajını bir müzakere daveti gibi görmemektir. Aynı gerekçeyle üst üste gönderim yapmak, otomatik sistemlerde kalıp olarak işaretlenir. Kılavuzun sınırında dolaşan bir özellik varsa, o özelliği yayına almadan önce Apple'a soru sormak her zaman daha ucuzdur.

Ajans üzerinden yayın yapan işletmeler için ek bir öneri: mağaza hesabının sahipliği daima marka tarafında kalsın. Hesap kapanması riskini paylaşmamak, uzun vadede ticari sürekliliğinizi korur.

Yayın Öncesi Kontrol Listesi

Aşağıdaki başlıklar, ilk gönderimde onay alma oranını belirgin biçimde yükseltir.

• Demo hesabı: Süresi dolmayan, içi dolu, tüm rollere erişim veren bir hesap hazırlayın.
• Çökme testi: TestFlight ve pre-launch report üzerinden farklı cihaz ve OS sürümlerinde tarama yapın.
• Gizlilik politikası: Erişilebilir URL, toplanan veri listesi, paylaşım tarafları ve silme talebi yolu.
• İzin metinleri: Her purpose string kullanıcıya somut fayda anlatsın.
• Veri güvenliği formu: SDK envanteriyle satır satır eşleşsin.
• Ekran görüntüleri: Yalnızca gerçek arayüz, yalnızca var olan özellikler.
• Ödeme mimarisi: Dijital içerik IAP tarafında, fiziksel ürün kendi altyapınızda.
• Giriş yöntemleri: Üçüncü taraf girişi varsa Sign in with Apple da listede.
• Hedef API: targetSdk güncel eşikte veya üzerinde.
• Test şartı: Kişisel Play hesabıysa 12 kullanıcı ve 14 gün tamamlanmış.

Bu maddeleri ekip içinde tek tek işaretleyerek ilerlemek isterseniz uygulama yayın kontrol listesi aracımız aynı akışı adım adım takip etmenizi sağlar. Platforma özel ayrıntılar için iOS uygulama geliştirme ve Android uygulama yaptırma yazılarımızdaki yayın bölümleri de işinizi kolaylaştırır.

Sıkça Sorulan Sorular

App Store uygulama reddi ne kadar sürede çözülür?

Metadata kaynaklı redler çoğunlukla aynı gün kapanır, çünkü yeni binary gerekmez. Guideline 2.1 ve 5.1.1 gibi teknik redler 1-5 gün alır. Guideline 4.2 ve 4.3 redleri ise ürün kapsamını değiştirmeyi gerektirdiği için 2-6 haftaya yayılabilir.

Reddedilen uygulamayı yeniden gönderince inceleme sırası başa mı döner?

Yeni bir binary yüklediğinizde uygulama "Waiting for Review" durumuna geri döner ve yeni bir inceleme turu başlar. Bu bir ceza değil, standart akıştır. Metadata reddinde ise aynı sürümü yeniden göndermeniz yeterlidir.

App Store uygulama reddi geliştirici hesabıma zarar verir mi?

Tekil redler hesabınıza kalıcı bir olumsuz etki bırakmaz. Risk, aynı ihlalin tekrarlanmasıyla doğar. Kasıtlı ve sürekli ihlaller hesap kapatmaya kadar gidebilir.

Guideline 4.3 spam reddini nasıl aşarım?

Uygulamanın rakiplerinden hangi somut işlevle ayrıştığını yazılı olarak anlatın ve bu işlevi üründe gösterin. Çok markalı yapıları tek uygulama ve hesap bazlı içerik mimarisine taşıyın. Yalnızca görsel değişiklik yapmak bu maddeyi geçmenizi sağlamaz.

Web sitemi uygulamaya çevirirsem reddedilir miyim?

Sadece siteyi WebView'a sararsanız Guideline 4.2 riski çok yüksektir. Native gezinme, çevrimdışı davranış, cihaz özellikleri ve bildirim mimarisi eklendiğinde uygulama bu eşiği geçebilir. Karar noktası, tarayıcının yapamayacağı bir işin varlığıdır.

Google Play'de uygulamam neden yayına çıkmıyor?

Yeni kişisel hesaplarda en sık neden, 12 test kullanıcısı ve 14 günlük kapalı test şartının tamamlanmamış olmasıdır. İkinci sık neden, veri güvenliği formu ile SDK davranışı arasındaki uyuşmazlıktır. Üçüncüsü hedef API seviyesinin güncel eşiğin altında kalmasıdır.

İtiraz etmek uygulamamı riske atar mı?

İtiraz, uygulamanız için ek bir yaptırım doğurmaz. Ancak sonucu beklerken yayın takviminiz uzar. Reviewer'ın haklı olduğu durumlarda düzeltip yeniden göndermek her zaman daha hızlı sonuç verir.

Türkiye'den yayın yaparken ek belge gerekiyor mu?

Kurumsal Play hesabı için D-U-N-S numarası ve şirket web sitesi doğrulaması istenir; D-U-N-S başvurusu birkaç haftayı bulabilir. Apple tarafında tüzel kişi başvurularında da benzer bir doğrulama yapılır. Gizlilik politikanızın KVKK aydınlatma yükümlülüğünü de karşılaması, yerel denetim tarafını kapatır.

App Store uygulama reddi bir başarısızlık raporu değil, eksik kalan beyanların listesidir. Kılavuz maddesini doğru okuyan, kanıtını hazırlayan ve tek turda tam düzeltme yapan ekipler bu süreci birkaç güne indirir. Asıl fark, sorunları yayın öncesinde yakalayan bir kontrol disiplininde ortaya çıkar.

Uygulamanız reddedildiyse ya da yayın öncesinde bağımsız bir gözle kontrol ettirmek istiyorsanız, süreci birlikte gözden geçirelim. Teklif ve iletişim sayfamızdan projenizin ayrıntılarını paylaşın; mağaza uyumluluğu, red gerekçeleri ve yayın takvimi için net bir yol haritası çıkaralım.