Mobil Uygulama Yayınlama: Reddedilmeden Mağazaya Girmek

Mobil uygulama projelerinde en çok hafife alınan aşama yayınlamadır. Geliştirme biter, ekip rahatlar ve mağaza süreci beklenmedik biçimde haftalar alır. Oysa gecikmelerin çoğu, baştan hazırlanabilecek maddelerden kaynaklanıyor.

Bu yazıda iki mağazanın da beklediği hazırlıkları, en sık red sebeplerini ve yayın sonrası ilk haftada yapılması gerekenleri anlatıyoruz.

Hesap ve kimlik hazırlığı: en uzun süren adım

Kod hazır olsa bile hesap açılmamışsa yayınlayamazsınız ve hesap açma süreci sanılandan uzundur.

Apple tarafında kurumsal hesap için işletmenin doğrulanabilir bir kimliğe sahip olması gerekiyor ve bu doğrulama günler alabiliyor. Google tarafında da geliştirici hesabı doğrulaması ve kurumsal bilgilerin onayı benzer şekilde işliyor.

Pratik tavsiye: hesap açma sürecini geliştirme başlar başlamaz başlatın. Uygulama bittiğinde hesap hazır olsun, tersi değil.

Yayın öncesi hazırlık listesi

Bu listedeki en çok atlanan iki madde, test hesabı ve veri beyanı. Giriş gerektiren bir uygulamaya inceleme ekibi giremezse doğrudan reddedilir. Veri beyanının gerçekle uyuşmaması ise yayından sonra bile kaldırılma sebebi olabilir.

En sık red sebepleri

Eksik işlevsellik. Yarım kalmış ekranlar, çalışmayan butonlar veya "yakında" yazan bölümler red sebebidir. Mağazalar tamamlanmamış uygulamayı kabul etmiyor.

Web sitesinin sarmalanmış hali. Yalnızca bir web sitesini uygulama içinde açan, cihaz özelliklerini hiç kullanmayan uygulamalar özellikle Apple tarafında reddediliyor. Uygulamanın web sitesine göre bir üstünlük sunması bekleniyor.

İzin gerekçesi eksikliği. Konum, kamera veya rehber izni isteniyorsa, neden istendiği kullanıcıya açıklanmalı. Gerekçe metni boş bırakılmış izinler red üretiyor.

Gizlilik politikası sorunları. Bağlantının çalışmaması, sayfanın uygulamayla ilgisiz olması veya toplanan veriyi kapsamaması sık karşılaşılan sorunlar.

Ödeme kuralları. Dijital içerik satışında mağazanın kendi ödeme sistemini atlamak, en kesin red sebeplerinden biri. Kuralların güncel hali App Store inceleme yönergelerinde ve Google Play geliştirici politikalarında yayınlanıyor.

Mağaza görselleri: indirilme oranını belirleyen şey

Kullanıcı uygulamayı indirmeden önce yalnızca ikonu, adı ve ekran görüntülerini görür. Bu üç unsur, indirilme oranının büyük kısmını belirliyor.

Ekran görüntülerinde yaygın hata, uygulamanın ham ekranını olduğu gibi koymak. Daha iyi çalışan yaklaşım, her görselin üstüne o ekranın ne işe yaradığını anlatan kısa bir başlık eklemek. İlk iki görsel en önemlisidir; çoğu kullanıcı gerisini kaydırmaz.

İkon tasarımında tek kural: küçük boyutta ayırt edilebilir olmak. Detaylı çizimler telefon ekranında lekeye dönüşüyor.

ASO: mağaza içi arama

Uygulama mağazalarında da arama var ve kendi optimizasyon mantığı işliyor. Uygulama adı ve kısa açıklama, arama sonuçlarında en ağırlıklı alanlar.

Ad seçerken marka adıyla birlikte ne yaptığınızı söyleyen bir ek kullanmak işe yarıyor: "Nezaman: Online Randevu" gibi. Yalnızca marka adı kullanmak, markayı bilmeyen kullanıcıya ulaşmayı imkansızlaştırır.

Değerlendirmeler hem sıralamayı hem indirilme oranını doğrudan etkiliyor. Değerlendirme isteme zamanlaması önemli: kullanıcı uygulamada olumlu bir işi tamamladıktan sonra sorun, açılışta değil.

Test dağıtımı: yayından önceki son kontrol

İki mağaza da yayın öncesi test dağıtımı imkanı sunuyor. Bu adımı atlamak, hataları ilk kullanıcıların bulmasına yol açıyor.

Test sürecinde toplanması gereken üç şey var: farklı cihaz ve işletim sistemi sürümlerinde çökme kayıtları, ilk açılış akışının anlaşılır olup olmadığı, ve izin isteme anlarında kullanıcının ne hissettiği.

Özellikle sonuncusu değerli. Uygulamayı açar açmaz konum izni isteyen bir uygulamada red oranı yüksek oluyor; aynı izin, kullanıcı o özelliği kullanmaya çalıştığında istendiğinde kabul oranı belirgin biçimde artıyor.

Bildirim izni: bir kez sorulur

Bildirim izni, kullanıcı bir kez reddettiğinde tekrar sormanın çok zor olduğu bir izindir. Bu yüzden ne zaman sorulacağı stratejik bir karardır.

Yaygın hata, ilk açılışta sormak. Kullanıcı henüz uygulamanın ne işe yaradığını bilmiyorken bildirim izni vermek için sebebi yoktur.

İşe yarayan kalıp: kullanıcı bildirimden fayda görecek bir eyleme geldiğinde, önce kendi arayüzünüzde neden istediğinizi açıklayın, sonra sistem iznini tetikleyin. Bu ön açıklama adımı, kabul oranını gözle görülür biçimde yükseltiyor.

Uygulama boyutu

Uygulama boyutu, indirilme oranını doğrudan etkiliyor; özellikle mobil veriyle indiren kullanıcılarda. Büyük uygulamalar "sonra indiririm" denip unutuluyor.

Boyutu şişiren tipik kalemler: farklı çözünürlükler için ayrı ayrı paketlenmiş görseller, kullanılmayan kütüphaneler ve sıkıştırılmamış yazı tipi dosyaları. Her iki mağaza da cihaza özel paket üretme imkanı sunuyor; bu özelliğin kullanılması boyutu belirgin biçimde düşürüyor.

Sürüm yönetimi ve güncelleme ritmi

İlk sürümü mükemmelleştirmeye çalışmak yaygın bir hata. Mağaza süreçleri gecikmeli olduğu için, kapsamı büyüttükçe yayın tarihi uzuyor ve geri bildirim almadan geliştirme yapılmış oluyor.

Daha iyi yaklaşım: çekirdek işlevle yayınlayıp düzenli güncelleme yapmak. Düzenli güncellenen uygulamalar mağaza tarafında da daha olumlu değerlendiriliyor.

Güncelleme notlarını "hata düzeltmeleri ve iyileştirmeler" diye geçmeyin. Ne değiştiğini yazmak, mevcut kullanıcıyı uygulamaya geri getiriyor.

Hangi teknolojiyle geliştirildiği yayını etkiler mi

Mağazalar teknoloji seçimine karışmıyor; kurallara uyan her uygulama kabul ediliyor. Ancak hibrit yaklaşımlarda dikkat edilmesi gereken bir nokta var: uygulamanın yalnızca web içeriği göstermemesi.

Cihaz özelliklerini kullanan, çevrimdışı çalışabilen ve yerel bildirim gönderebilen bir hibrit uygulama sorunsuz kabul ediliyor. Teknoloji karşılaştırması için Flutter ve PWA yazılarımıza bakabilirsiniz.

Red aldıysanız ne yapmalı

Red bir felaket değil, sıradan bir adım. Önemli olan tepki biçimi.

Red mesajı hangi kuralın ihlal edildiğini belirtir. O kuralı okuyun, düzeltmeyi yapın ve yeniden gönderirken not alanına neyi nasıl düzelttiğinizi açıkça yazın. İnceleme ekibiyle iletişimde savunmacı değil açıklayıcı olmak, süreci belirgin biçimde kısaltıyor.

Kararın yanlış olduğunu düşünüyorsanız itiraz mekanizması var, ancak itiraz süreci düzeltip yeniden göndermekten uzun sürüyor. Düzeltme mümkünse önce onu deneyin.

Yayın sonrası ilk hafta

Yayın, projenin bitişi değil ölçümün başlangıcı. İlk hafta izlenmesi gerekenler: çökme oranı, ilk açılış sonrası devam eden kullanıcı oranı, ve ilk değerlendirmeler.

Çökme oranı ilk günlerde en yüksektir çünkü gerçek cihaz çeşitliliği test ortamından fazladır. Hızlı bir düzeltme sürümü hazır bulundurun.

Yayın sürecini uçtan uca yönetmemizi isterseniz uygulama yayını hizmetimiz hesap açılışından mağaza görsellerine kadar bu adımları kapsıyor. Bize yazın.