
Girişimler İçin Mobil Uygulama Kontrol Listesi: MVP'den App Store Onayına 34 Madde (2026)
Apple'ın App Store Review Guideline 5.1.1(v) maddesi, bugüne kadar yayınladığımız her türlü bug'dan daha fazla startup lansman tarihini öldürdü. Demo gününden bir gece önce gönderilen uygulamada eksik bir hesap silme butonu ve tüm takvim bir hafta kayar. Girişimler için bu mobil uygulama kontrol listesi tam da bu yüzden var: bu hata tamamen önlenebilir ve neredeyse hiç kimse buna yol açan yönerge numarasını bir yere not etmez.
Öne çıkanlar:
- Apple, eksik hesap silme akışları ve gizlilik politikası bağlantıları nedeniyle uygulamaları reddeder: Guideline 5.1.1 ve 1.5 bunu açıkça belirtir.
- Google Play, hem uygulama içi hem de herkese açık bir web üzerinden hesap silme yolu gerektirir; 31 Mayıs 2024 uzatma sonrasından itibaren yaptırım uygulanır.
- iOS ve Android gönderim kontrol listeleri farklıdır; ikisini tek bir listede birleştirmek, son dakika lansman gecikmelerinin 1 numaralı nedenidir.
Kod Yazmaya Başlamadan Önce
Tek bir ekran bile tasarlanmadan önce üç şeyin netleşmesi gerekir: MVP'nizin gerçekte ne olduğu, gizlilik politikasına ihtiyacınız olup olmadığı (var) ve kullanıcılarınıza GDPR mı yoksa Türkiye'nin KVKK'sının mı uygulandığı. Bu aşamayı atlamak, kurucuların gönderim yapmak istedikleri hafta yasal sayfalar yazmaya çalışmasının başlıca nedenidir.
MVP, tek cümleyle, temel varsayımınızı gerçek kullanıcılarla test eden en küçük ürün sürümüdür. Tam vizyonunuzun kırpılmış bir versiyonu değildir. Kapsam hâlâ bulanıksa, tek satır kod yazmadan önce projenizin kapsamını doğru belirlemek, geliştirme ortasında özellik kesmekten kurtarır.
Apple'ın kendi yönergeleri gizlilik politikası gereksinimi konusunda nettir: Guideline 5.1.1(i), uygulamaların App Store Connect meta verilerinde ve çoğu durumda uygulamanın içinde "gizlilik politikalarına bir bağlantı içermesi gerektiğini" belirtir. Bu bir öneri değildir. Eksikse gönderimi bloke eden bir maddedir.
- MVP kapsamınızı tek cümleyle tanımlayın
- Gizlilik politikasına ihtiyacınız olduğunu doğrulayın (neredeyse her zaman vardır)
- Bir Destek URL'si hazırlayın (Apple Guideline 1.5 bunu gerektirir)
- AB veya Türkiyeli kullanıcılarınız varsa GDPR/KVKK geçerliliğini kontrol edin
- Native mi yoksa cross-platform stack mi karar verin
MVP Geliştirme Haftası
MVP geliştirme haftası, gerçekte neyin yayınlanacağına ve neyin kesileceğine karar verdiğiniz yerdir ve dürüst cevap şudur: kurucuların beklediğinden çok daha fazlası kesilir. Analitik ve çökme raporlama, yayından sonra değil, geliştirme sırasında eklenir. Lansman sonrasına bırakmak, ilk varsayımınızı doğrulamak için ihtiyaç duyduğunuz verileri kaybetmeniz demektir.
v1 kapsamından gerçekte kestiğimiz şey, çoğu zaman, test edilen tek şey olmayan her şeydir. Push bildirimleri, sosyal giriş, altı anahtarlı bir ayarlar ekranı; hepsi bekleyebilir. Kurucular anlaşılır şekilde buna direnir; yarım kalmış bir şey yayınlamak gibi hissettirir. Zaten yarım kalmıştır. Mesele de budur.
Birden fazla uygulama yayınlamış bir kurucunun dev.to'daki kontrol listesi yazısında dediği gibi, erken aşamada geri bildirim mekanizmasını atlamak "her seferinde pişman olduğu" bir hatadır. Şimdi ekleyin, ilk yorumunuz geldikten sonra değil. Kapsam belirleme sürecinin kendisini hızlandırmak isterseniz, AI ile kapsamlandırmayı hızlandırmak geliştirmeye başlamadan önce göz atmaya değer.
- İlk TestFlight/dahili build'inizden önce analitiği entegre edin
- Çökme raporlamayı bağlayın (Sentry veya Firebase Crashlytics)
- Uygulamanın içine bir geri bildirim mekanizması yerleştirin
- Test ettiğiniz tek şeye doğrudan hizmet etmeyen her özelliği kesin
- İlk sürüm dizenizi yazın (aşağıda versiyonlamaya bakın)
Gönderimden Önceki Hafta
Bu, rakip kontrol listelerinin tamamen atladığı aşamadır ve en önlenebilir gecikmelerin yaşandığı yerdir. Uygulamalar için anlamsal versiyonlama MAJOR.MINOR.BUILD desenini izler (1.0.0, ardından yama için 1.0.1, özellik güncellemesi için 1.1.0). Şimdi bir şema seçin, çünkü tutarsız sürüm numaraları hem uygulama mağazalarını hem de kendi ekibinizi karıştırır.
Kademeli yayınlama (staged rollout), güncellemeyi önce küçük bir kullanıcı yüzdesine (genellikle %1, sonra %10, sonra %50), ardından herkese açar. İncelediğimiz üç rakip kontrol listesinden yalnızca biri bundan bahsediyor, o da sadece bir cümleyle. Bir çökme gözden kaçarsa, kademeli yayınlama hasarın çapını sınırlar; kullanıcıların %100'ünü aynı anda vurmak yerine.
Bir müşterinin gönderimini onaylamadan önce sorduğumuz sorular basittir: kritik yol, şu anda, gerçek bir cihazda uçtan uca çalışıyor mu? Simülatörde değil. Çökmesiz kullanım oranı kabul edilebilir mi? Mağaza listeleme materyalleri gerçekten son halinde mi, yoksa yer tutucu mu?
- Sürüm numaranızın tutarlı bir şemayı izlediğini doğrulayın
- Kritik yolu son bir kez daha uçtan uca test edin
- Mağaza destekliyorsa kademeli yayınlama yüzdenizi hazırlayın
- Gönderimden önce çökmesiz kullanım oranının kabul edilebilir olduğunu doğrulayın
- Tüm mağaza listeleme materyallerinin ekran görüntüsünü alın ve hazırlayın
Gönderim Günü: iOS ve Android
iOS ve Android gönderimleri farklı nedenlerle başarısız olur ve ikisini tek bir kontrol listesi olarak ele almak, gördüğümüz son dakika lansman gecikmelerinin açık ara en büyük nedenidir. Apple'ın App Store İnceleme Yönergeleri ve Google Play'in geliştirici politikaları, her biri belirli, kontrol edilebilir gereksinimler tanımlar ve çoğu kurucu bunları ancak bir reddedilme e-postasından sonra öğrenir.
Kendi uygulama gönderimlerimizde, ilk kez gönderim yapan kurucuları en sık takıldığı iki şey, hesap silme gereksinimi ve ulaşılamayan bir Destek URL'sidir. İkisi de gönderimden önce yakalarsanız tek satırlık düzeltmelerdir. Yakalamazsanız ikisi de otomatik reddedilmeye yol açar.
Apple'ın App Store İnceleme Yönergeleri spesifiktir: Guideline 5.1.1(v), hesap oluşturmayı destekleyen uygulamaların uygulama içi hesap silme de sunmasını gerektirir, Guideline 1.6 Veri Güvenliği açıklamalarını kapsar ve Guideline 1.5 çalışan bir Destek URL'si gerektirir. Android tarafında Google Play geliştirici politikası, hem uygulama içi bir silme yolu HEM DE hesap silme talepleri için herkese açık bir web URL'si gerektirir. Google bu gereksinimi Nisan 2023'te duyurdu, Data safety formunun veri silme soruları için 7 Aralık 2023 son tarihini koydu ve 31 Mayıs 2024'e kadar uzatmalara izin verdi; bu tarihten sonra uyumsuz uygulamalar yaptırımla karşı karşıya kalır. Bu, küçük uygulamalar için muaf tutulmuş eski bir kural değildir; hâlâ geçerlidir.
İki gönderim akışı kağıt üzerinde değil, mekanik olarak da ayrışır. iOS'ta build'i Xcode veya Transporter üzerinden yüklersiniz, App Store Connect işler (bu birkaç dakikadan bir saatin üzerine kadar sürebilir) ve oradan ya TestFlight'a dahili ve harici test kullanıcılarına yönlendirirsiniz ya da doğrudan App Review'a gönderirsiniz. TestFlight isteğe bağlı bir formalite değildir: bir inceleyicinin sizi reddedeceği bug'ları yakalamanız için Apple'ın beklediği yol budur. Android'de Google Play Console tek bir gönderim yerine kanallarla (track) çalışır; dahili test, ardından kapalı veya açık test, ardından production'a ilerler, her birinin kendi kitlesi ve kendi terfi adımı vardır. Kademeli yayınlama yalnızca mevcut bir production sürümünü güncellerken görünür. Google'ın kendi yayınlama dokümantasyonunun dediği gibi, "ilk sürümünüzü yayınlıyorsanız, yayınlama yüzdesi seçme seçeneğini görmezsiniz"; bu yüzden ilk lansmanınızı bir yüzde rampası etrafında planlamayın, o sonra gelir.
Çoğu ilk gönderimi bloke eden şey kod değil, evrak işidir. Apple, yaygın kullanılan üçüncü taraf SDK'ların (reklam ağları, analitik, çökme raporlayıcılar) tanımlı bir listesi için privacy manifest gerektirir ve kendi rehberi, sorumluluğun kimde olduğu konusunda nettir: Apple'ın üçüncü taraf SDK gereksinimleri sayfasına göre, "uygulamanızla birlikte üçüncü taraf bir SDK kullandığınızda, SDK'nin uygulamanıza dahil ettiği tüm koddan siz sorumlusunuz ve veri toplama ile kullanım pratiklerinin farkında olmanız gerekir". Listelenen bir SDK için manifest'i atlarsanız, build'iniz App Store Connect'ten geçmez. Google Play tarafındaki eşdeğer evrak kapısı Data safety formu; yalnızca dahili test build'leri hariç her kanaldaki her uygulama için zorunludur: Google Play Veri güvenliği dokümantasyonuna göre, "Google Play'de yayınlanmış bir uygulaması olan tüm geliştiriciler; kapalı, açık veya production test kanallarındaki uygulamalar dahil, Data safety formunu doldurmalıdır". Hata yaparsanız, Google, beyan edilen ile gerçek uygulama davranışı arasında bir uyumsuzluk ortaya çıktığında "yaptırım dahil uygun işlemleri yapabileceğini" açıkça söyler.
Politika metniyle hiçbir ilgisi olmayan üçüncü bir başarısız modu daha var: inceleyici uygulamanızı kelimenin tam anlamıyla test edemez. Apple'ın Guideline 2.1 maddesi bunu doğrudan söyler: "uygulamanız bir giriş içeriyorsa demo hesap bilgilerini ekleyin (ve arka uç hizmetinizi açık bırakın!)". Çalışan demo bilgileri yoksa, inceleme penceresi sırasında canlı bir arka uç yoksa, ulaşılamayan bir Destek URL'si varsa, hesap silme akışınız ne kadar uyumlu olursa olsun geri çevrilirsiniz. Uygulamanızın herhangi bir bölümü bir ödeme duvarının veya giriş kapısının arkasındaysa, oraya tam olarak nasıl ulaşılacağını açıklayan inceleyici notları yazın. İlk kez gönderim yapan kurucuların sürekli atladığı iki dakikalık bir adımdır.
Aynı konuşmaya Android'e özgü bir kapı daha dahil edilmelidir: hedef API seviyesi. Android'in kendi geliştirici dokümantasyonu, "yeni uygulamaların ve uygulama güncellemelerinin Google Play'e gönderilebilmesi için" mevcut gerekli Android API seviyesini "hedeflemesi gerektiğini" ve "eski uygulamaların, Android'in daha yeni sürümlerini çalıştıran cihazların yeni kullanıcılarına kullanılamaz" olduğunu belirtir. Hesap silme veya Data Safety ile hiçbir ilgisi yoktur, ama bir gönderimi aynı şekilde bloke eder ve her yıl değişen türden bir gereksinimdir; bu yüzden release'inizi oluşturmadan önce güncel rakamı kontrol edin.
| Gereksinim | iOS (App Store) | Android (Google Play) |
|---|---|---|
| Hesap silme | Uygulama içi yol gerekli (Guideline 5.1.1(v)) | Uygulama içi yol VE herkese açık web URL'si gerekli (31 Mayıs 2024 sonrası yaptırım) |
| Gizlilik politikası | Gerekli, bağlantılı (Guideline 5.1.1(i)) | Gerekli, Data Safety formunda bağlantılı |
| Destek iletişimi | Destek URL'si gerekli (Guideline 1.5) | Destek e-postası/URL'si gerekli |
| Veri açıklaması | Data Security bölümü (Guideline 1.6) | Data Safety formu (zorunlu) |
| Kademeli yayınlama | Aşamalı yayın mevcut, katılım isteğe bağlı | Kademeli yayınlama mevcut, katılım isteğe bağlı |
| İnceleme süresi | Bizim gönderimlerimizde genellikle bir-iki gün, işaretlenirse daha uzun | Genellikle Apple'dan hızlı, ama değişir |
Bu arama için en üst sırada yer alan kontrol listelerinin hiçbiri tek bir App Store yönerge numarası bile anmıyor. Biz anıyoruz, çünkü uyumluluk konusunda tahmin yürütmek, lansmanların her seferinde bir hafta ertelenmesinin yoludur. Daha geniş veri işleme duruşunuzu inşa ediyorsanız, yayın öncesi veri işleme kontrol listeniz, burada tekrarlamadığımız güvenlik tarafını kapsar.
iOS gönderim kontrol listesi:
- Gizlilik politikası URL'si yayında ve ulaşılabilir
- Uygulama içi hesap silme yolu yayınlandı (Guideline 5.1.1(v))
- Destek URL'si yayında (Guideline 1.5)
- Data Security açıklamaları tamamlandı (Guideline 1.6)
- Herkese açık gönderimden önce TestFlight build'i onaylandı
Android gönderim kontrol listesi:
- Play Console'da Data Safety formu dolduruldu
- Uygulama içi hesap silme yolu yayınlandı
- Hesap silme talepleri için herkese açık web URL'si yayında (Google Play gereksinimi)
- Kademeli yayınlama yüzdesi ayarlandı
- Hedef API seviyesi mevcut Play gereksinimini karşılıyor
Lansman Günü
Lansman günü, uygulamanızın gerçek kullanıcılara gerçekten açıldığı gündür; günler veya haftalar önce gerçekleşebilen gönderimden ayrıdır ve sonuç olan ilk haftadan ayrıdır. Birinci günde kademeli yayınlama izleme, genişletmeye devam mı yoksa duraklat mı diyeceğinizi size söyleyen şeydir.
İlk 24 saat boyunca App Store Connect veya Play Console panonuzu günlük değil, saatlik izleyin. Çökmesiz kullanım oranınız düşerse, yüz kullanıcı daha aynı bug'a çarptığında ertesi sabah değil, bir saat içinde bilmek istersiniz. Bir geri alma build'ini hazır tutun. AI özellikleri için kullandığımız sıkılaştır-stabilize et-dağıt disiplini burada da aynı şekilde geçerlidir.
- İlk 24 saat boyunca çökmesiz kullanım oranını saatlik izleyin
- Destek kanalınızın personelini hazır bulundurun
- Kademeli yayınlamanın planlandığı gibi genişlediğini doğrulayın
- Kritik bir bug durumunda bir geri alma build'ini hazır tutun
Yayındaki İlk Haftanız
Yayındaki ilk hafta, neredeyse hiç kimse planlamasa da, gerçek işin çoğunun yapıldığı yerdir. Günlük çökme raporu incelemesi ve ilk mağaza yorumlarınıza yanıt vermek, lansman gününde yaptığınız her şeyden daha önemlidir.
Bir kurucunun kendi lansman sonrası kontrol listesinde yazdığı gibi: "Lansmanın kendisi düşündüğünüzden daha az önemlidir. Önemli olan, sonraki haftalarda ne yaptığınızdır." İlk haftanın dürüst versiyonu budur: hızlı yama yapın, kişisel yanıt verin ve gerçek bir kullanıcı sizin yerinize test etmeden önce veri silme akışınızın çalıştığını gerçekten kontrol edin. Şimdi tüm bunların ne kadara mal olduğunu merak ediyorsanız, lansman sonrası bakım ve güncelleme bütçesi tamamlayıcı yazıdır. Bu yazı hazırlığı kapsar; o yazı faturayı.
- İlk hafta boyunca çökme raporlarını günlük inceleyin
- İlk 10 mağaza yorumuna kişisel olarak yanıt verin
- Kritik bir bug'ı 48 saat içinde sınıflandırın ve yamalayın
- Veri silme talebi sürecinizin gerçekten uçtan uca çalıştığını doğrulayın
- Analitiği orijinal MVP hipotezinizle karşılaştırmak için bir düzen belirleyin
Techsy Bu Sürece Nasıl Yaklaşıyor
Gönderim öncesi incelemeyi her müşteri build'i için aynı şekilde ele alırız: bir gönderimi onaylamadan önce, kritik yolun gerçek bir cihazda çalışıp çalışmadığını, çökmesiz kullanım oranının dayanıp dayanmadığını ve yönergeyle zorunlu kılınan her akışın (hesap silme, gizlilik politikası, Destek URL'si) gerçekte çalışıp çalışmadığını sorarız; sadece bir mockup'ta var olup olmadığını değil. Kısa bir listedir, ama bir uygulamanın incelemeden ilk denemede geçip geçmeyeceğini belirleyen listedir.
Gönderiminizi, bu yönergelerde daha önce yol almış birinin üstlenmesini tercih ederseniz, mobil uygulama geliştirme sürecimiz tam da bu gönderim öncesi inceleme adımı etrafında kurulmuştur. Kendi ödevinizi yapmanın yerine geçmez; siz ödevinizi yaptıktan sonra bizim yaptığımızdır.
Sıkça Sorulan Sorular
MVP nedir ve lansman kontrol listesi için neden önemlidir?
MVP, temel bir varsayımı gerçek kullanıcılarla test eden en küçük ürün sürümünüzdür. Burada önemlidir, çünkü bu listedeki her madde kapsamla birlikte büyür; daha sıkı bir MVP, gönderimde yanlış gidebilecek daha az şey ve ilk haftada enstrümante edilecek, izlenecek ve yamalanacak daha az özellik demektir.
Uygulamalar App Store'dan neden reddedilir?
En yaygın önlenebilir nedenler, eksik gizlilik politikası bağlantıları (Guideline 5.1.1(i)), uygulama içi hesap silme olmaması (Guideline 5.1.1(v)) ve ulaşılamayan bir Destek URL'sidir (Guideline 1.5). Bunların hiçbiri düzeltmek için mühendislik çabası gerektirmez; bunlar bug değil, kontrol listesi maddeleridir.
Uygulamama bir hesap silme seçeneği eklemezsem ne olur?
iOS'ta Guideline 5.1.1(v), uygulamanız hesap oluşturmayı destekliyorsa bunu otomatik bir reddedilme nedeni yapar. Android'de Google Play hem uygulama içi hem de herkese açık bir web silme yolu gerektirir; 31 Mayıs 2024 uzatma son tarihinden sonra uyumsuz uygulamalar yaptırımla karşılaşır ve bunu atlamak her iki platformda da gönderimi bloke eder.
Startup'ların bir mobil uygulama için gizlilik politikasına ihtiyacı var mı?
Evet, neredeyse her zaman. Apple, Guideline 5.1.1(i) kapsamında bağlantılı bir gizlilik politikası gerektirir ve Google Play, Data Safety formunun içinde bir tane gerektirir. Herhangi bir kullanıcı verisi topluyorsanız, kayıt için sadece bir e-posta bile olsa, gönderimden önce bir politikanızın olması gerekir.
App Store ve Google Play'e gönderim arasındaki fark nedir?
Apple'ın incelemesi, adlandırılmış maddeler (5.1.1, 1.5, 1.6) ve insan bir inceleyici ile yönerge odaklıdır; Google Play, Data Safety formuna ve otomatik kontrollere dayanır. Hesap silme gereksinimi özünde benzerdir ama mekanikte farklıdır; yukarıdaki karşılaştırma tablosuna bakın.
Uygulama mağazası incelemesi gerçekte ne kadar sürer?
Hiçbir mağaza garanti bir süre yayınlamaz, bu yüzden okuduğunuz her rakamı bir söz değil, yaklaşık bir beklenti olarak ele alın. Kendi müşteri gönderimlerimizde Apple onayları genellikle bir-iki gün içinde geldi; hesap silme veya veri açıklamasına dokunan her şey daha uzun sürdü. Google Play genellikle daha hızlıydı. Lansman tarihinizi her durumda bir esneklik payıyla planlayın.
Kademeli yayınlama (staged rollout) nedir ve kullanmalı mıyım?
Kademeli yayınlama, bir güncellemeyi önce küçük bir kullanıcı yüzdesine yayınlar, ardından kademeli olarak genişletir; aynı anda %100'e göndermek yerine. Mağaza desteklediği sürece kullanın; duraklatıp düzeltebilmenizden önce kaç kullanıcının bir bug'a çarpacağını sınırlar.
Uygulamamı göndermek için bir destek URL'sine ihtiyacım var mı?
Evet. Apple'ın Guideline 1.5 maddesi, gönderimin bir parçası olarak çalışan bir Destek URL'si gerektirir ve Google Play de bir destek iletişimi bekler. Ölü bir bağlantı veya izlenmeyen bir gelen kutusu, kolay ve önlenebilir bir reddedilme nedenidir.
Uygulamamın yayındaki ilk haftasında neyi izlemeliyim?
Çökme raporlarını günlük, ilk on mağaza yorumunuzu ve veri silme talebi sürecinizin gerçekten uçtan uca çalışıp çalışmadığını. Bu aynı zamanda, MVP'nizin test etmek için inşa edildiği varsayıma karşı gerçek kullanım verisini kontrol etmeye başladığınız zamandır.
GDPR veya KVKK küçük bir startup'ın uygulaması için geçerli midir?
AB'de kullanıcılarınız varsa, GDPR şirketinizin büyüklüğüne bakılmaksızın uygulanır. Türkiye'de kullanıcılarınız varsa, KVKK aynı şekilde uygulanır. Hiçbir yasanın küçük startup muafiyeti yoktur; bu yüzden geçerliliği, korumanız gereken gerçek kullanıcı veriniz olduktan sonra değil, kapsam belirleme sırasında kontrol edin.
Yazar Hakkında
Mert Batur, Techsy.io'nun Kurucu Ortağıdır; ekip burada B2B müşteriler için AI ajanları, otomasyon sistemleri ve ses/SDR pipeline'ları geliştirir. Techsy ekibinin production'da gerçekten kullandığı LLM araç yığını hakkında yazar. LinkedIn'den bağlanın.
Sonuç
Girişimler için bir mobil uygulama kontrol listesi, ancak bugün uygulanabilecek kadar spesifikse yerini hak eder: MVP'nizi tek cümleyle tanımlayın, analitiği geliştirmeden önce entegre edin, gönderimden önceki hafta sürüm şemanızı gözden geçirin ve iOS ile Android kontrol listelerinizi tek bir liste olarak ele almak yerine ayırın. Yalnızca hesap silme ve gizlilik politikası maddeleri, gördüğümüz önlenebilir reddedilmelerin çoğunu oluşturur.
Kontrol listesini yazdırın, aşama aşama üzerinden geçin ve yayındaki ilk haftayı atlamayın; her rakip kontrol listesinin dışarıda bıraktığı kısım budur ve lansmanınızın kalıcı olup olmayacağını gerçekte belirleyen kısımdır. Göndermeden önce gönderiminize ikinci bir gözün bakmasını tercih ederseniz, ücretsiz danışmanlık alın →