Uygulamamız mağazadan döndü: App Store ve Google Play yayın süreci nasıl işler?

Uygulamanız mağazadan döndüyse sorun büyük ihtimalle kodda değil. Redlerin çoğu üç yerden çıkar: inceleyenin uygulamaya giremediği bir giriş ekranı, mağazanın istediği ama üründe hiç yapılmamış bir işlev (hesap silme, ödeme yöntemi, veri beyanı), ya da geçirilmiş bir platform tarihi. Yani yayın, kodu bitirdikten sonra yapılan bir yükleme işi değil; kendi takvimi, kendi sahibi ve kendi bakım maliyeti olan ayrı bir iş kalemi. Apple'ın kendi rakamları ölçeği veriyor: 2025'te inceleme ekibi 9,1 milyondan fazla gönderimi değerlendirdi ve bunların 2 milyondan fazlasını reddetti. Reddedilenlerin 1,2 milyonu yeni uygulama, 800 bine yakını ise güncellemeydi.

Takvim kodun bitişinde değil, hesabın açılışında başlar

Kurumsal hesap açmak bir öğleden sonralık iş değil. Apple Developer Program üyeliği yılda 99 dolar ve kurumsal başvuru için Apple üç şey arıyor: şirketin D-U-N-S numarası, sözleşme yapabilen gerçek bir tüzel kişilik (ticari unvan veya şube kabul edilmiyor) ve kendi alan adınızda, çalışır durumda halka açık bir web sitesi. Başvuruyu yapan kişinin de şirketi hukuken bağlama yetkisi olması gerekiyor. Şirket adı ayrıca App Store'da satıcı adı olarak görünür, o yüzden hangi tüzel kişilikle başvurduğunuz pazarlama kararıdır da.

Google Play tarafında kayıt ücreti 25 dolar ve tek seferlik. Kuruluş hesabı açacaksanız orada da D-U-N-S numarası ve kimlik doğrulama var. D-U-N-S numarası ücretsiz alınır ama başvurunun sonuçlanması günler, bazen haftalar sürer. Uygulamanın yayın tarihine iki hafta kala bunu fark etmek istemezsiniz.

Play'de kişisel hesap açtıysanız yayın iki hafta geç başlar

Google'ın az bilinen ama en çok takvim bozan kuralı bu. 13 Kasım 2023'ten sonra açılmış kişisel geliştirici hesapları, uygulamayı üretime alabilmek için önce kapalı test yapmak zorunda: en az 12 test kullanıcısı, en az 14 gün boyunca kesintisiz olarak kayıtlı kalmalı. Kayıt kopması olursa 14 gün baştan sayılır. Süre dolduğunda Play Console'da üretim erişimi için başvurursunuz; başvuruda testten ne öğrendiğinizi, hedef kitleyi ve üretime hazırlık gerekçenizi yazmanız istenir. Google bu başvurunun incelemesinin genelde yedi günü bulduğunu, bazen daha uzun sürebileceğini söylüyor.

Kuruluş hesapları bu kuralın dışında. Şirket olarak uygulama yayınlayacaksanız baştan kuruluş hesabı açın, geliştiricinin kişisel hesabına yayın yapıp sonra devretmeye çalışmayın. Hesabın kimin adına olduğu, kodun kimde durduğu kadar önemli bir mülkiyet sorusudur.

En sık red: inceleyen uygulamanın içine giremedi

Apple'ın 2.1 maddesi "eksik bilgi" başlığıyla döner ve pratikte çoğu zaman şu anlama gelir: verdiğiniz demo hesap çalışmıyor, backend kapalı, ya da giriş SMS doğrulaması istiyor ve inceleyen o SMS'i alamıyor. Türkiye'de sık görülen bir kombinasyon bu, çünkü pek çok uygulamada giriş cep telefonu doğrulamasına bağlı.

Çözüm inceleme öncesi hazırlanacak küçük bir pakettir. Kalıcı bir demo hesabı açın, inceleme süresince şifresini değiştirmeyin ve o hesabın verisi dolu olsun. Telefon doğrulaması varsa inceleme hesabı için sabit bir test kodu tanımlayın. App Store Connect'teki "Notes for Review" alanına inceleyenin izleyeceği adımları tek tek yazın; Apple 2.3.1 maddesinde yeni işlevlerin bu alanda özel olarak anlatılmasını istiyor, genel geçer açıklamalar reddedilebiliyor. Donanım, saha erişimi veya özel bir bayi hesabı gerektiren akışlar varsa bunu da açıkça belirtin.

Mağazanın ürüne ekletmek istediği işlevler

Bazı kurallar metadata değil, geliştirme işi. En çok atlanan ikisi hesap silme ve ödeme.

Apple'ın 5.1.1(v) maddesi, kullanıcı hesabı oluşturulabilen her uygulamada uygulama içinden hesap silme yolu şart koşuyor. Google Play daha ileri gidiyor: uygulama içi silme yolunun yanında, kullanıcının uygulamayı tekrar kurmadan talep edebileceği bir web bağlantısı da istiyor, üstelik bunu Veri güvenliği formundaki veri silme sorularında beyan etmenizi zorunlu tutuyor. Bu bilgi mağaza sayfanızda görünür. Formu eksik bıraktığınızda yeni sürüm yayınlayamazsınız.

Silme düğmesi koymak da yeterli değil; arkasında bir karar var. Hangi veri gerçekten silinecek, hangisi yasal saklama yükümlülüğü nedeniyle kalacak, kalan kayıtlar nasıl anonimleştirilecek, muhasebe ve fatura verisiyle ilişki nasıl kopacak? Bunu iki günde çözülecek bir iş sanıp sürüm haftasına bırakan ekipler her seferinde gecikiyor.

Dijital içerik satıyorsanız ödeme kuralını baştan okuyun

Apple'ın 3.1.1 maddesi net: uygulama içindeki özellik, abonelik, dijital içerik veya "tam sürüm" açılımı satıyorsanız bunu uygulama içi satın alma ile yapmanız gerekiyor. Lisans anahtarı, QR kod veya kendi ödeme sayfanıza yönlendirme kabul edilmiyor. Fiziksel ürün ve uygulama dışında tüketilen hizmetler bu kuralın dışında; bir e-ticaret uygulaması kendi ödeme altyapısını kullanmaya devam eder.

Sınırın nereden geçtiği ürün kararını doğrudan etkiler, çünkü platform komisyonu iş modelinizin marjını değiştirir. SaaS ürününüzün mobil aboneliğini fiyatlarken bunu hesaba katın. Ödemenin teknik tarafındaki asıl zorluklara ödeme entegrasyonu ve mutabakat yazısında girmiştik.

Web sitesini paketleyip mağazaya koymak çalışmıyor

Apple'ın 4.2 maddesi, uygulamanın "yeniden paketlenmiş bir web sitesinin ötesine geçen" özellik ve arayüz içermesini istiyor; esas olarak pazarlama malzemesi, web kırpıntısı, bağlantı listesi veya içerik toplayıcı olan uygulamalar dışarıda kalıyor. 4.3 maddesi ise aynı uygulamanın farklı paket kimlikleriyle çoğaltılmasını ve piyasadakinden ayırt edilemeyen uygulamaları hedefliyor. Apple 2025'te 371 binden fazla gönderimi kopyalama, spam veya kullanıcıyı yanıltma gerekçesiyle reddettiğini açıkladı.

Bu yüzden mobil kararı yayın kararından önce gelir. Mağazada bir uygulamaya gerçekten ihtiyacınız var mı, yoksa mobil uyumlu web yeterli mi? Karar ölçütlerini native mi cross-platform mı yazısında ele almıştık.

Her yıl tekrarlayan tarihler: bakım kalemi burası

Mağaza kuralları sabit değil, yıllık bir ritmi var ve bu ritim bütçeye yazılmadığında uygulama sessizce güncellenemez hale geliyor.

• Google Play hedef API seviyesi. 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler Android 16'yı (API 36) hedeflemek zorunda. Mevcut uygulamaların da yeni kullanıcılara görünmeye devam edebilmesi için en az API 35'i hedeflemesi gerekiyor; altında kalan uygulama yalnızca kendi hedef seviyesindeki ve daha eski cihazlarda bulunabiliyor. Google, ek süreye ihtiyacı olanlar için 1 Kasım 2026'ya kadar uzatma başvurusuna izin veriyor.
• Apple SDK tabanı. 28 Nisan 2026'dan beri App Store Connect'e yüklenen iOS uygulamalarının Xcode 26 ve iOS 26 SDK (ya da daha yenisi) ile derlenmiş olması gerekiyor. Bu, uygulamanın eski cihazlarda çalışmasını engellemez, sadece derleme ortamınızı günceller.
• Yaş sınırı soruları. Apple 31 Ocak 2026 itibarıyla güncellenmiş yaş derecelendirme sorularının yanıtlanmasını istiyor; yanıtlanmadığında gönderim kesintiye uğruyor.
• Gizlilik manifestoları. 1 Mayıs 2024'ten beri, belirlenmiş API'lerin kullanımı için onaylı gerekçe beyanı zorunlu ve bu üçüncü taraf SDK'ları da kapsıyor. Uygulamanıza giren her reklam, analitik veya çökme raporlama kütüphanesi sizin sorumluluğunuzda. Yazılım tedarik zinciri güvenliği yazısındaki bağımlılık disiplini mobilde doğrudan yayın engeline dönüşebiliyor.

Avrupa'ya yayın yapıyorsanız bir kalem daha var: Dijital Hizmetler Yasası kapsamında App Store'da tacir (trader) statüsü beyanı zorunlu. Apple 16 Ekim 2024'ten itibaren bu beyanı gönderim şartı yaptı ve 17 Şubat 2025'ten sonra beyanı doğrulanmamış uygulamaları AB App Store'undan kaldırdı. Beyan ettiğiniz iletişim bilgileri mağaza sayfasında herkese görünür.

Yayın günü değil, yayın penceresi planlayın

Apple tarafında inceleme çoğu zaman bir iki gün sürer ama garantisi yoktur; Google tarafında yeni hesaplar ve hassas kategoriler daha uzun incelenir. Buna göre iki pratik kural: lansman iletişimini incelemeden çıkmış bir sürüme bağlayın, tarihi baştan duyurmayın. Ve sürümü kademeli açın.

İki mağazanın da aracı var. Apple'ın aşamalı sürüm özelliği, otomatik güncelleme açık kullanıcılara yeni sürümü yedi güne yayarak dağıtır (birinci gün yüzde 1, sonra 2, 5, 10, 20, 50 ve yüzde 100) ve gerekirse sürümü 30 güne kadar duraklatabilirsiniz. Google Play'in kademeli yayını da yüzde bazlıdır ve durdurulabilir. Play Console'daki yönetilen yayınlama ise incelemesi biten değişikliklerin ne zaman canlıya çıkacağını sizin kontrolünüze verir.

Test tarafında TestFlight'ta 100 iç test kullanıcısı ve 10.000 dış test kullanıcısı hakkınız var. Dış testte ilk yapının beta incelemesinden geçmesi gerektiğini not edin, o da bir günlük gecikme demek olabilir.

Mağaza geri alma düğmesi vermez

Mobilde en pahalı fark bu. Web'de bozuk bir sürümü on dakikada geri alırsınız. Mağazada eski sürüme dönmek diye bir şey yok: düzeltilmiş yeni bir yapı gönderir, incelemeyi tekrar beklersiniz. Kullanıcıların bir bölümü bu arada bozuk sürümde kalır.

Bu yüzden mobilde özellik bayrağı bir konfor değil, geri dönüş planının kendisidir. Riskli bir özelliği sunucudan kapatabiliyorsanız, hatalı sürüm bir felaket değil bir bakım işidir. Özellik bayrakları ve kademeli yayın yazısı bu mekanizmayı anlatıyor. Aynı mantıkla, zorunlu sürüm yükseltme kontrolünü (uygulamanın açılışta sunucuya minimum sürüm sorması) ilk sürüme koyun; sonradan eklemek istediğinizde onu ekleyecek güncellemeyi zaten alamayan kullanıcılara ulaşamazsınız.

Göndermeden önceki son yarım saat

Kabul testini bitirdikten sonra, gönderim düğmesine basmadan önce şu listeyi bir kişi baştan sona geçsin: demo hesap çalışıyor mu ve backend açık mı, inceleme notunda adımlar yazılı mı, hesap silme akışı uygulama içinden ve web'den çalışıyor mu, Veri güvenliği formu ve gizlilik etiketleri uygulamanın gerçekten topladığı veriyle uyumlu mu, ekran görüntüleri güncel sürümün ekranları mı, uygulama adı ve açıklama yanıltıcı ifade içeriyor mu, hedef API seviyesi ve SDK sürümü güncel mi, test sunucusu adresleri yapının içinde kalmış mı?

Bunların çoğu sürüm hattında otomatikleşir. Sürüm derlemesi, imzalama, mağazaya yükleme ve sürüm notu üretimini elle yapıyorsanız insan hatası kaçınılmaz; küçük ekipler için CI/CD yazısındaki mantık mobil sürümler için de aynen geçerli. Kabul sürecinin kendisini nasıl kuracağınıza ise kabul testi ve devreye alma yazısından bakabilirsiniz.

Uygulamanız reddedildiyse ilk adım kızmak değil, ret mesajındaki madde numarasını okumaktır. Apple Resolution Center üzerinden soru sorma imkanı verir ve kararı haksız buluyorsanız App Review Board'a itiraz edebilirsiniz; çoğu durumda ise istenen şey küçük bir düzeltmedir ve aynı gün içinde tekrar gönderilebilir. Asıl mesele bu turu bir daha yaşamamaktır: yukarıdaki tarihleri takvime, kontrol listesini de sürüm sürecine yazın.