App Store ve Google Play Onay Süreci ve Ret Durumu

Apple, gönderimlerin büyük bölümünü 24-48 saat içinde inceler; karmaşık uygulamalarda süre birkaç güne uzayabilir. Google Play'de ilk yayın genellikle birkaç saat ile birkaç gün arasında sonuçlanır; yeni açılmış geliştirici hesaplarında 7 güne kadar çıkabilir. Yoğun dönemlerde, özellikle yıl sonu tatil sezonunda, iki mağazada da inceleme yavaşlar; lansman tarihini en az bir haftalık payla planlamak gerekir.

Başı çeken sebepler iki mağazada da benzer: inceleme sırasında çöken veya boş ekran veren sürümler, eksik ya da tutarsız gizlilik beyanı, inceleme ekibinin giriş yapamadığı demo hesaplar, gerekçesiz istenen izinler ve uygulama içeriğiyle örtüşmeyen mağaza listelemesi. Google tarafında Data Safety formu ile gerçek veri trafiğinin uyuşmaması, Apple tarafında hesap silme akışının bulunmaması son yılların en sık ret gerekçeleri arasına girdi.

Önce geliştirici konsolundaki inceleme notu okunur; Apple ve Google hangi yönerge maddesine dayandığını, çoğu zaman ekran görüntüsüyle birlikte paylaşır. Sorun düzeltilip sürüm yeniden gönderilir; bunun için ek ücret ödenmez. Kararın hatalı olduğunu düşünüyorsanız Apple'da App Review Board'a, Google'da politika ekibine itiraz açabilirsiniz; gerekçeli ve kanıtlı itirazlar özellikle yanlış tespitlerde sonuç verir. Çoğu durumda gerekçeyi karşılayıp yeniden göndermek, itirazdan daha hızlıdır. Edge Bilişim'de ret notu geldiğinde önce ilgili yönerge maddesi ile uygulamadaki karşılığı yan yana yazılır, düzeltme aynı sürüm numarası üzerinde değil ayrı bir build ile yapılır ve yeniden gönderim öncesi o akış temiz bir cihazda baştan test edilir; böylece ikinci turda farklı bir gerekçeyle ret alma ihtimali azalır.

Uygulamanızda giriş gerektiren bölümler varsa evet. Apple, App Review bilgileri alanına çalışan bir kullanıcı adı ve şifre girilmesini zorunlu tutar; Google da erişim bilgisi ister. Demo hesabın süresinin dolması, şifresinin değişmesi veya kilitlenmesi en sık ret sebeplerinden biridir. SMS doğrulaması gibi inceleme ekibinin aşamayacağı adımlar varsa, demo hesap için bu doğrulamayı atlayan bir yol tanımlanmalıdır.

Evet. Uygulama içinde hesap oluşturma varsa Apple, kullanıcının hesabını yine uygulama içinden kalıcı olarak silebilmesini şart koşar; yalnızca 'bize e-posta gönderin' yönlendirmesi kabul edilmez. Google Play de hesap ve veri silme talebi için bir yol (uygulama içi akış veya web bağlantısı) beyan edilmesini ister. Bu akış KVKK'daki silme talebi hakkıyla örtüşür; tek tasarımla iki gereklilik birden karşılanır.

İkisi de uygulamanızın hangi veriyi toplayıp nasıl kullandığını standart formatta beyan ettiğiniz zorunlu bölümlerdir: Google Play'de Data Safety, App Store'da App Privacy etiketi. Beyanın uygulamanın gerçek veri trafiğiyle uyuşması gerekir; analitik veya reklam SDK'larının arka planda topladığı veriyi beyan etmemek, formu hiç doldurmamak kadar risklidir. Gönderim öncesi SDK envanteri çıkarıp beyanları buna göre doldurmak en güvenli yoldur.

Google, bireysel olarak açılan yeni geliştirici hesaplarında, uygulama üretime alınmadan önce belirli sayıda gerçek kullanıcıyla 14 gün kesintisiz kapalı test yürütülmesini şart koşar; güncel şart en az 12 test kullanıcısıdır ve Google bu sayıyı zaman zaman günceller. Şirket hesaplarında bu zorunluluk yoktur. Test kullanıcılarını önceden örgütlemeyen projeler bu şart yüzünden lansmanı genellikle 2-3 hafta kaçırır.

Apple Developer Program yıllık 99 ABD doları, Google Play Console tek seferlik 25 ABD dolarıdır; şirket adına Apple hesabı için ücretsiz temin edilen D-U-N-S numarası da gerekir. Uygulama reddedilse bile bu ücretler iade edilmez, ancak yeniden gönderim için ek ücret de alınmaz. Mağaza ücretleri toplam sahip olma maliyetinin küçük bir kalemidir; sunucu, domain ve bildirim altyapısıyla birlikte tam tabloyu yazılımın gizli maliyetleri rehberinde bulabilirsiniz.

Mutlaka sizin veya şirketinizin adına. Mağazadaki uygulamanın sahibi, yüklendiği geliştirici hesabıdır; ajansın kendi hesabında yayınlanan uygulama, iş ilişkisi bittiğinde taşınması zor bir mülkiyet sorununa dönüşür. Sözleşmenize hesapların size ait olacağını ve tüm erişim bilgilerinin teslim edileceğini yazdırın. Apple'da uygulama devri (app transfer) mümkün olsa da bazı durumlarda kısıtlıdır; en temiz çözüm baştan doğru hesapta yayınlamaktır. Edge Bilişim yürüttüğü mağaza yayınlarında hesapları müşterinin kendi kurumsal e-posta adresiyle açtırır, geliştirici erişimini yalnızca gerekli rollerle (App Manager / Release Manager) alır ve proje kapanışında bu yetkileri konsoldan kaldırır; sözleşme ve gizlilik tarafını kurmak isteyenler için NDA ve fikir koruma rehberi tamamlayıcı bir kaynaktır.

Apple'ın incelemesi tasarım, gizlilik ve ödeme kurallarında daha öngörülebilir biçimde titizdir; her sürüm insan eliyle denetlenir ve sınırda kalan konularda ret olasılığı yüksektir. Google'ın süreci daha otomatiktir ve ilk yayında daha hoşgörülü görünebilir; ancak politika ihlallerinde uygulamayı yayından kaldırma ve hesabı askıya alma kararlarını daha sert uygular. Doğru yaklaşım, birine göre değil ikisinin ortak paydasına göre hazırlanmaktır.

Dijital içerik ve abonelik satan uygulamalar App Store'da Apple'ın ödeme sistemini kullanmak zorundadır; komisyon standartta yüzde 30, Small Business Program kapsamındaki (yıllık geliri 1 milyon doların altındaki) geliştiricilerde yüzde 15'tir. Google Play'de benzer kural ve oranlar geçerlidir. Fiziksel ürün veya yerinde hizmet satışında kendi ödeme altyapınızı kullanabilirsiniz. Kullanıcıyı mağaza dışı ödemeye yönlendiren gizli bağlantılar klasik ret sebebidir.

Apple, yönergenin 4.3 (Design: Spam) maddesiyle piyasadaki benzerlerinden ayrışmayan, şablondan üretilmiş görünen uygulamaları reddeder; aynı kod tabanından çok sayıda benzer uygulama çıkaran hesaplar da kapsama girer. Önlemek için uygulamanın çözdüğü sorunu netleştirmek, arayüzü hazır tema görünümünden çıkarmak ve mağaza açıklamasında özgün değeri anlatmak gerekir. Hazır paketlerden uygulama üreten sistemlerde bu ret riski belirgin biçimde yüksektir.

Hayır. Güncelleme reddedildiğinde mağazadaki mevcut sürüm çalışmaya devam eder; kullanıcılarınız süreçten haberdar bile olmaz. Ret gerekçesi giderildikten sonra düzeltilmiş güncelleme yeniden gönderilir ve onaylanınca eski sürümün yerini alır. Bu yüzden kritik hata düzeltmeleri dışında güncellemeleri aceleyle değil, gönderim öncesi kontrol listesi tamamlanarak göndermek daha güvenlidir.

Dolaylı ama güçlü biçimde. Mağazalar KVKK'yı doğrudan denetlemez; ancak aydınlatma metni, açık rıza ve veri silme hakkı gibi KVKK gereklilikleri, mağazaların gizlilik politikası, veri beyanı ve hesap silme şartlarıyla büyük ölçüde örtüşür. KVKK'ya uygun kurgulanan bir uygulama, gizlilik kaynaklı mağaza retlerinin çoğunu kendiliğinden aşar; tersi durumda hem ret hem idari yaptırım riski aynı anda doğar.

En etkili hızlandırıcı, hatasız ve eksiksiz bir ilk gönderimdir; retle geçen her tur en az bir inceleme süresi kaybettirir. Bunun dışında Apple, lansman tarihi veya kritik hata düzeltmesi gibi durumlarda gerekçeli 'expedited review' talebini kabul edebilir; bu istisnai bir kolaylıktır, rutin kullanılamaz. Google'da resmi bir hızlandırma yolu yoktur; yeni hesaplardaki kapalı test şartını erken başlatmak takvimi en çok rahatlatan adımdır.

En baştan. Mağaza kuralları izin mimarisini, ödeme modelini ve veri akışını etkilediği için tasarım kararlarıyla birlikte ele alınmalıdır; sona bırakılırsa yeniden geliştirme maliyeti doğurur. Fikrinizi somutlaştırmak için nereden başlamalıyım rehberi, platform kararı için web sitesi mi mobil uygulama mı karşılaştırması, bütçe planı için maliyet hesaplama rehberi iyi bir başlangıç setidir.