Uygulamanı App Store'a Çıkarmadan Önce Bilmen Gereken Teknik Adımlar

İki hafta sonra lansman var. Uygulama çalışıyor, ekip haftalardır test ediyor, pazarlama takvimi hazır, mağaza sayfası metni yazıldı. Apple'a submission'ı attın, otuz altı saat sonra dönen cevap tek satır: "Guideline 2.1 – App Completeness" reddi. Hangi ekranı kastettiği net değil, hangi cihazda sorun yaşandığı da yazmıyor. Lansman tarihi artık iki hafta değil, belirsiz. Bu senaryo tanıdıksa, sorun genelde kodun kalitesinde değil; uygulamanı app store'a çıkarmadan önce kontrol edilmesi gereken, bilinen ama çoğu ekibin ilk reddedilince öğrendiği küçük ve kesin bir teknik listede.

##Uygulamanı App Store'a Çıkarmadan Önce Tamamlanması Gereken Teknik Adımlar

Apple ve Google'ın reddettiği uygulamaların büyük kısmı, karmaşık bug'lar yüzünden değil, atlanan ve aslında dokümante edilmiş küçük gerekliliklerden dönüyor: canlı bir gizlilik politikası URL'si, her izin isteği için insan dilinde açıklama, login gerektiren ekranlar için reviewer'a verilmiş bir demo hesap, mağaza metninin ekran görüntüleriyle tam örtüşmesi, hesap silme akışının "bize e-posta at" değil uygulama içinde gerçekten var olması. Bunların hiçbiri zor değil; sadece kod yazarken değil, submission formunu doldururken fark ediliyor — ve genelde lansmana bir hafta kala. Bu yazı o listeyi, neden var olduğunu ve ilk reddedilmeden önce nasıl geçileceğini anlatıyor. Üstelik liste sadece ilk gönderim için geçerli değil; her yeni sürüm submission'ında aynı maddeler tekrar gözden geçirilmeli, çünkü tek bir SDK güncellemesi veya eklenen bir ekran bu listenin bir maddesini sessizce bozabiliyor.

##Apple App Store ve Google Play Arasındaki Kritik Farklar

İki mağaza aynı mantıkla çalışmıyor ve bu farkı bilmemek, ikinci bir sürpriz reddi garantiliyor. Apple'da inceleme hem otomatik tarama hem de bir insan reviewer'ın uygulamayı gerçekten açıp gezmesiyle ilerliyor; ödeme, hesap ya da sağlık verisi işleyen uygulamalarda bu inceleme daha da dikkatli oluyor. Google Play'de ilk geçiş daha çok otomatik sistemlere dayanıyor ve genelde daha hızlı sonuçlanıyor, ama asıl fark yayından sonra başlıyor: Play, uygulamanı onayladıktan günler veya haftalar sonra bile politika taramasını sürdürüyor ve bir ihlal bulduğunda uygulamayı askıya alabiliyor. Yani Apple'da zorluk "geçmek", Play'de zorluk "geçtikten sonra da uyumlu kalmak". Ödeme tarafında da ayrışıyorlar: dijital ürün veya hizmet satıyorsan Apple'da kendi ödeme linkini koyamıyorsun, In-App Purchase zorunlu oluyor (bazı istisnalar dışında); Play'de bu konuda biraz daha esneklik var ama Data Safety formu eksik veya gerçek veri toplama davranışıyla uyuşmuyorsa askıya alınma riski aynı şekilde geçerli. Metadata reddi de sık görülen bir başka sebep: ekran görüntülerinde gösterilen ama uygulamada henüz bulunmayan bir özellik, ya da mağaza açıklamasında geçen ve test edilemeyen bir iddia, her iki mağazada da hızlı bir ret gerekçesi oluyor.

Aşağıdaki farklar, bir submission hazırlığında en çok gözden kaçan noktalar:

• ▸Apple: insan + otomatik inceleme, ortalama 24–48 saat; ödeme, hesap veya sağlık verisi içeren uygulamalarda ek manuel kontrol ve daha uzun süre
• ▸Google Play: daha çok otomatik inceleme, genelde daha hızlı onay; ama yayından SONRA da politika taraması sürüyor, askıya alınma riski devam ediyor
• ▸Apple: dijital ürün/hizmet satan uygulamalarda In-App Purchase zorunlu, kendi ödeme linkini koyamazsın
• ▸Google Play: kendi ödeme altyapını kullanma konusunda biraz daha esnek, ama Data Safety formu uygulamanın gerçek veri davranışıyla eşleşmek zorunda
• ▸Her ikisinde de: canlı bir gizlilik politikası URL'si, izinler için spesifik kullanım açıklaması ve login gerektiren uygulamalarda reviewer için demo hesap zorunlu

##Gerçek Bir Senaryo: İlk Submission Neden Reddedilir, Nasıl Düzelir

Küçük bir ekip, randevu/rezervasyon uygulamasını ilk kez Apple'a gönderiyor. 48 saat sonra iki ayrı red geliyor: Guideline 5.1.1 — uygulamada hesap silme seçeneği yok, destek sayfasında sadece "silmek için bize e-posta atın" yazıyor; Guideline 2.1 — reviewer'ın test ettiği iPad'de, onboarding carousel'i ikinci ekranda donup çöküyor. Ekip panikliyor çünkü kendi simülatörlerinde hiçbir sorun görmemişler. Kök neden basit: carousel animasyonu yalnızca küçük ekranlı simülatörlerde test edilmiş, gerçek bir iPad'de ve eski bir iPadOS sürümünde hiç denenmemiş; hesap silme gerekliliği ise 2022'deki politika güncellemesiyle geldiği için ekip bunu kaçırmış, çünkü uygulama o tarihten önce tasarlanmıştı. Çözüm iki parçalı: ayarlar menüsüne gerçek bir "hesabı sil" akışı eklendi (e-posta değil, uygulama içi onay ve geri alınamaz silme), carousel bileşeni gerçek, eski bir cihazda test edilip bellek sızıntısı düzeltildi. İkinci gönderimde reviewer notlarına ne değiştiğini açıkça yazdılar ve 18 saat içinde onay geldi. Takvimde net etki: lansman dört gün kaydı, ama checklist tamamen tarandığı için üçüncü bir red hiç yaşanmadı — çoğu ekip için asıl kayıp, tek bir reddin kendisi değil, art arda gelen tahmin edilemeyen redlerin biriktirdiği zamandır. Ekip ayrıca pazarlama takvimini güncelleyip paydaşlara dört günlük gecikmeyi erkenden haber verdi, böylece sosyal medya ve reklam planı da sessizce yeniden ayarlanabildi.

##Reddedilmeyi Önleyen Teknik Kontrol Listesi

Submission'dan önce aşağıdaki maddelerin hepsi gerçekten doğrulanmış olmalı — "muhtemelen tamam" yetmiyor:

• ▸Gizlilik politikası canlı bir URL'de yayında ve uygulama içinden tıklanabilir bir linkle erişilebiliyor
• ▸Kamera, konum, bildirim gibi her izin isteği için insan dilinde, o isteğe özel açıklama metni yazıldı (genel "verilerinizi kullanıyoruz" yeterli değil)
• ▸Login gerektiren her ekran için reviewer'ın girebileceği, çalışan bir demo hesap bilgisi app review notlarına eklendi
• ▸Hesap ve veri silme akışı uygulama içinde gerçekten var, destek e-postasına yönlendirme değil
• ▸Gerçek cihazda test yapıldı: en az desteklenen en eski OS sürümü ve en yeni sürüm olmak üzere iki uçta
• ▸Uygulama içi satın alma varsa restore purchase akışı ayrı olarak test edildi
• ▸Yaş derecelendirme anketi, uygulamanın gerçek içeriğiyle (şiddet, kullanıcı üretimi içerik, sosyal özellikler) tutarlı dolduruldu
• ▸Ekran görüntüleri ve mağaza açıklaması, uygulamanın şu an gerçekten yaptığı şeyi gösteriyor — henüz gelmemiş bir özelliği öne çıkarmıyor
• ▸Crash ve analytics SDK'ları, gizlilik beyanına (Apple'da privacy nutrition label, Play'de Data Safety) tek tek eklendi
• ▸Derin bağlantılar ve push bildirim izin akışı, gerçek bir cihazda uçtan uca denendi

Bir de hiçbir zaman çöküş gibi görünmeyen, bu yüzden sürekli atlanan iki madde var. Apple'ın Export Compliance sorusu — uygulama şifreleme kullanıyor mu, HTTPS bile teknik olarak buna girer ama genelde istisna kapsamında sayılır — her sürümde yeniden soruluyor; sürümler arasında tutarsız cevaplar o anki incelemeyi reddettirmez ama sonraki bir incelemede soru işaretine dönüşebiliyor. Benzer şekilde, uygulama içi satın almalar gerçek kartla değil sandbox hesabıyla test edilmeli — restore ve iptal akışlarının ikisinin de gerçek para hiç devreye girmeden çalıştığı doğrulanmalı. İkisi de görünür bir hata üretmiyor; sessizce bir-iki sürüm sonra sorun çıkarıyor.

Çoklu dilde yayın yapıyorsan bir incelik daha var: her lokalize mağaza sayfası — başlık, açıklama, ekran görüntüleri — kendi dilinde tutarlı olmalı. Bir dildeki ekran görüntüsü güncellenip diğer diller unutulursa, bazı incelemeler bunu metadata uyumsuzluğu olarak işaretleyip o dildeki sürümü reddedebiliyor. Küçük bir ekip için en güvenli yöntem, yeni bir özelliği yayınlamadan önce tüm aktif dillerin ekran görüntüsü setini aynı anda güncellemek; tek dilde unutup diğerlerini eski haliyle bırakmamak.

##Ortalama İnceleme Süreleri ve Gecikme Aralıkları

##Store Sonrası: Versiyonlama, Güncelleme Hızı ve Kriz Anında Ne Yapılır

Onay almak işin bitişi değil, sadece bir sonraki riskin başlangıcı. Google Play'de kademeli yayın (staged rollout) kullanıp yeni sürümü önce kullanıcıların küçük bir yüzdesine açmak, kritik bir hatayı yüzde yüze yayılmadan yakalamanın en ucuz yolu. Apple'da bu seçenek yok ama kritik bir güvenlik açığı veya çöküş tespit edildiğinde expedited review talep edilebiliyor — normal kuyruğu atlayıp saatler içinde incelemeye girebiliyor, ancak bu hak her sürümde değil, gerçek kriz anlarında kullanılmalı. Sürüm numaralarını (semantic versioning) ciddiye almak, bir crash raporunun hangi koda ait olduğunu dakikalar içinde bulmayı sağlıyor; eski build'lerin sembol dosyalarını (dSYM, mapping.txt) saklamak, canlıda çöken bir sürümü üç gün sonra bile debug edebilmek için gerekiyor. Son olarak: bir önceki sürümün build'ini elinin altında tutmak, kritik bir sorunda rollback kararını dakikalar içinde verebilmenin tek garantisi.

##Sık Sorulan Sorular

>App Store review'u ortalama ne kadar sürer?

İlk gönderimde genelde 24–48 saat arasında bir sonuç geliyor; ödeme, hesap veya sağlık verisi işleyen uygulamalarda ek manuel kontrol nedeniyle bu süre uzayabiliyor. Resubmission'larda süre benzer kalıyor, bazen reviewer önceki notları gördüğü için biraz daha hızlı sonuçlanıyor.

>Google Play'de uygulama onaylandıktan sonra neden askıya alınabiliyor?

Çünkü Play'in politika taraması yayından sonra da sürüyor. Data Safety formunda beyan edilen veri toplama davranışı, uygulamanın gerçekte yaptığıyla uyuşmuyorsa — ya da bir SDK güncellemesiyle yeni bir veri toplama davranışı eklenip form güncellenmezse — sistem bunu günler veya haftalar sonra yakalayıp uygulamayı askıya alabiliyor. Bu yüzden Data Safety formunu tek seferlik bir checkbox değil, her sürümde kontrol edilmesi gereken canlı bir belge gibi görmek gerekiyor.

>Reddedilen bir uygulamayı tekrar göndermek, kuyruğu sıfırdan mı başlatıyor?

Genelde hayır. Reviewer çoğunlukla önceki red notlarını görebiliyor, bu da düzeltilen noktayı doğrulamayı hızlandırabiliyor. Ama resubmission hâlâ aynı inceleme hattından geçiyor, yani yukarıdaki süre aralıklarının dışında bir hızlı şerit garantisi yok — tek fark, neyin düzeltildiğinin açıkça yazılmış olması incelemeyi kolaylaştırıyor.

>Demo hesabı olmadan login gerektiren bir uygulamayı nasıl submit ederim?

Pratikte submit edemezsin — daha doğrusu edersin ama reviewer giriş ekranına girip ilerleyemediği için neredeyse kesin olarak Guideline 2.1 reddi alırsın. Doğru yol, app review notlarına çalışan bir kullanıcı adı/şifre (veya demo giriş linki) eklemek; bazı ekipler bunun için sadece reviewer'ların kullandığı, gerçek verilerden izole bir test hesabı tutuyor.

Bu kontrol listesinin çoğu, ürünü geliştirirken değil, launch'a bir hafta kala submission formunu doldururken fark ediliyor. Uygulamanın store'a gerçekten hazır olup olmadığını teknik olarak gözden geçirmek veya lansman sürecini birlikte planlamak istersen /contact üzerinden yazabilirsin; nasıl çalıştığım ve süreç detayları /process-pricing sayfasında, benzer bir launch sonrası bakım konusunu /blog/software-maintenance-retainer-cost-after-launch yazısında ele almıştım. Gözden geçirme hem iOS hem Android tarafını, hem mağaza metnini hem gizlilik beyanlarını kapsayabilir.