Bir mobil uygulamanın mağazada “yayında” göründüğü gün, proje ekibi için genellikle bir bitiş çizgisi gibi hissedilir. Oysa kullanıcı açısından o gün her şeyin başladığı gündür: Uygulama ilk kez yüzlerce farklı cihazda, farklı ağlarda ve beklenmedik kullanım biçimleriyle karşılaşır. Masa başında görülmeyen hatalar ortaya çıkar, ilk yorumlar gelir, ilk değişiklik istekleri birikir.
Bu yazıda uygulama yayına çıktıktan sonra neler olduğunu, mağaza süreçlerinin nasıl işlediğini, bakımın neden kaçınılmaz olduğunu ve bakım kapsamını nasıl yazıya dökebileceğinizi adım adım anlatıyoruz.
Mağazaya çıkmadan önce hazırlanması gerekenler
App Store ve Google Play, uygulamayı yalnız dosya olarak değil, bir ürün sayfası olarak ister. Başvurudan önce hazır olması gerekenler kabaca şunlardır:
- Geliştirici hesapları: uygulamanın yayımlanacağı hesaplar ve bu hesaplara kimlerin erişeceği.
- Mağaza sayfası: uygulama adı, kısa ve uzun açıklama, ekran görüntüleri, simge.
- Gizlilik bilgileri: uygulamanın hangi veriyi topladığı ve neden kullandığı; gizlilik politikasının adresi.
- Deneme bilgileri: inceleme ekibinin uygulamayı açıp deneyebilmesi için gereken hesap ve açıklamalar.
- Destek kanalı: kullanıcının sorun bildirebileceği bir iletişim adresi.
Gizlilik bilgileri özellikle dikkat ister. Mağazalar, uygulamanın topladığı verinin beyan edilmesini ve beyanın uygulamanın gerçek davranışıyla uyuşmasını bekler. Türkiye’deki kullanıcılar için ayrıca 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamındaki aydınlatma yükümlülükleri değerlendirilmelidir; güncelini resmi kaynaktan ve hukuk danışmanınızdan doğrulayın.
İnceleme süreci ve red ihtimali
Her yeni uygulama ve her güncelleme mağazaların incelemesinden geçer. İnceleme süreleri ve kuralları mağazalara bağlıdır ve zaman zaman değişir. Bu yüzden yayın planına inceleme için pay bırakmak, özellikle bir kampanya ya da lansman tarihine bağlı yayınlarda önemlidir.
Uygulamalar en çok şu tür sebeplerle geri çevrilir: inceleme ekibinin giriş yapamaması ya da bir özelliğe ulaşamaması, eksik ya da uygulamayla çelişen gizlilik beyanı, çalışmayan bağlantılar ve boş ekranlar, uygulamanın bir web sitesini sarmalamaktan öteye geçmemesi, kullanıcı hesabı oluşturulabilen uygulamalarda hesabı silme imkânının olmaması gibi. Red, genellikle bir açıklamayla gelir; çoğu zaman gerekli düzeltme yapılıp yeniden gönderilerek çözülür. Mağaza kuralları sık güncellendiği için güncelini mağazaların kendi geliştirici kaynaklarından takip etmek gerekir.
Kademeli yayın ve sürüm planı
Yeni bir sürümü bütün kullanıcılara aynı anda açmak zorunda değilsiniz. Mağazalar, güncellemenin önce kullanıcıların bir kısmına ulaşmasına ve sorun görülmezse genişletilmesine imkân tanır. Bu yöntem, gözden kaçmış bir hatanın herkesi aynı anda etkilemesini önler.
Sürümleri rastgele değil, bir plana göre çıkarmak da işi kolaylaştırır. Acil hata düzeltmeleri hızlıca, yeni özellikler ise birikip denenmiş paketler hâlinde yayınlanır. Her sürümde neyin değiştiğinin kısa bir notla kayda geçmesi, hem ekibinizin hem de destek veren tarafın işini kolaylaştırır.
Sürüm planı bağlı sistemlerin takvimiyle de uyumlu olmalıdır. Sitenizde, mağazanızda ya da ERP’nizde büyük bir değişiklik planlanıyorsa, uygulamanın buna hazır sürümü önceden yayınlanmalıdır. Aksi hâlde sunucu tarafı değiştiği anda kullanıcıların elindeki uygulama beklenmedik biçimde davranabilir. Kampanya dönemleri, yoğun satış günleri ve tatil öncesi gibi zamanlarda büyük güncellemelerden kaçınmak da riskleri azaltır.
Güncellemenin türleri
“Uygulama zaten çalışıyor, neden güncellensin?” sorusu sık sorulur. Cevap, güncellemenin tek bir sebebi olmamasıdır:
| Tür | Neden gerekir? |
|---|---|
| Hata düzeltme | Sahada ortaya çıkan sorunlar |
| İşletim sistemi uyumu | iOS ve Android’in yeni sürümleri |
| Mağaza kuralları | Değişen yayın şartları |
| Güvenlik | Kullanılan kütüphanelerdeki açıklar |
| Bağlı sistemler | Site, ERP ya da ödeme tarafındaki değişiklik |
| Yeni özellik | Kullanıcı ve iş ihtiyacı |
Bu listenin ilk beşi sizin isteğinizden bağımsız olarak gelir. Hiç yeni özellik eklemeseniz bile, uygulamanın çalışır ve mağazada kalabilir durumda tutulması için düzenli bir bakım emeği gerekir.
Bu emeği bütçelemek, uygulamanın ömrünü uzatmanın en sağlam yoludur. Yayından sonra bakım için kaynak ayrılmayan uygulamalar genellikle bir süre sorunsuz çalışır, sonra bir işletim sistemi güncellemesiyle aniden bozulur; o noktada yapılması gereken iş, düzenli bakımın toplamından çok daha büyük olabilir.
Eski sürümde kalan kullanıcılar
Web sitesinde bir değişiklik yaptığınızda bütün ziyaretçiler anında yeni hâli görür. Mobil uygulamada durum farklıdır: Güncellemeyi yüklemeyen kullanıcılar uzun süre eski sürümle devam edebilir. Bu, uygulamanın konuştuğu sunucu tarafını da etkiler; sunucu tarafında yapılan bir değişiklik eski sürümleri bozmamalıdır.
Bunun için iki yaklaşım birlikte kullanılır. Birincisi, sunucu tarafının belirli bir süre boyunca eski sürümleri de destekleyecek şekilde tasarlanmasıdır. İkincisi, artık desteklenemeyecek kadar eski sürümler için kullanıcıya güncelleme yapmasını söyleyen bir uyarı ya da zorunlu güncelleme ekranıdır. Bu ekran ilk sürümden itibaren uygulamada bulunmalıdır; sonradan eklenmesi, onu hiç almamış eski sürümlere ulaşmaz.
Hata ve çökme takibi
Kullanıcıların çoğu bir hatayla karşılaştığında bunu bildirmez; uygulamayı kapatır ve belki bir daha açmaz. Bu yüzden hataların kullanıcı şikâyetiyle değil, uygulamanın kendisinden öğrenilmesi gerekir. Çökme raporları, hangi cihazda, hangi işletim sistemi sürümünde ve hangi ekranda sorun yaşandığını gösterir ve düzeltmeyi hızlandırır.
Bu raporlar da kişisel veri içerebilir; hangi bilgilerin toplandığı gizlilik beyanıyla uyumlu olmalı ve yalnız hatayı çözmek için gereken kadar bilgi alınmalıdır.
Uygulamanın arkasındaki sunucu da bakım ister
Telefondaki uygulama çoğu zaman tek başına çalışmaz; siparişleri, randevuları, kullanıcı hesaplarını ve bildirimleri yöneten bir sunucu tarafıyla konuşur. Bakım denince yalnız mağazadaki uygulamayı düşünmek, bu yarıyı gözden kaçırmak demektir. Sunucu tarafındaki yazılımın güvenlik güncellemeleri, yedekleri, bildirim servislerinin ayarları ve bağlantı kurduğu diğer sistemlerdeki değişiklikler de düzenli takip ister.
Örneğin bildirim servislerinin kimlik bilgileri ya da sertifikaları belirli aralıklarla yenilenmezse, uygulama sorunsuz görünürken bildirimler sessizce gitmemeye başlayabilir. Bu tür sorunların kullanıcı şikâyetinden önce fark edilmesi için sunucu tarafının da izlenmesi ve bir sorun olduğunda ilgili kişiye haber vermesi gerekir.
Yorumlar ve puanlar
Mağaza yorumları, uygulamanın vitrinidir. Yeni bir kullanıcı uygulamayı indirmeden önce puanlara ve son yorumlara bakar. Cevapsız bırakılan şikâyetler, uygulamanın terk edildiği izlenimini verir.
Yorumlara kısa ve somut cevaplar vermek, sorunu çözdükten sonra kullanıcıya bunu bildirmek ve tekrar eden şikâyetleri bir sonraki sürümün listesine almak iyi bir alışkanlıktır. Yorumlar aynı zamanda ücretsiz bir kullanıcı araştırmasıdır: Kullanıcıların neyi aradığını, neyi bulamadığını ve nerede zorlandığını doğrudan söyler.
Memnun kullanıcıdan puan istemek de bir yöntemdir; ama zamanlaması önemlidir. Bir işlemi başarıyla tamamlamış, örneğin siparişi teslim alınmış ya da randevusu onaylanmış kullanıcıya uygun bir anda sorulan değerlendirme isteği, uygulamayı ilk açtığı anda karşısına çıkan bir pencereden çok daha iyi karşılanır. Mağazaların bu tür istekler için kendi kuralları ve araçları vardır; uygulama bunlara uygun kurulmalıdır.
Sahiplik: Hesaplar, kod ve anahtarlar
Bakımın en çok ihmal edilen tarafı sahipliktir. Uygulama başka birinin geliştirici hesabından yayımlanmışsa, kaynak kodu sizde değilse ya da uygulamayı imzalamak için kullanılan anahtarlar kaybolmuşsa, ileride geliştirici değiştirmek ya da güncelleme çıkarmak çok zorlaşır. Bazı durumlarda uygulamayı yeni bir kayıtla, sıfır yorumla yeniden yayımlamak gerekebilir.
Bu yüzden şu bilgilerin sizde olduğundan emin olun: mağaza hesaplarının yönetici erişimi, kaynak kodun güncel kopyası, uygulamayı imzalama anahtarları ve bildirim, harita ya da ödeme gibi bağlı servislerin hesapları.
Bakım kapsamını yazıya dökmek
“Bakım” kelimesi herkes için farklı bir şey ifade eder. Sonradan anlaşmazlık yaşamamak için kapsam yayından önce yazılı olarak netleşmelidir:
- İşletim sistemi ve mağaza kuralı değişikliklerine uyum dahil mi?
- Hata bildirimi nasıl yapılır, hangi kanaldan ve nasıl önceliklendirilir?
- Bağlı sistemlerdeki değişikliklerden doğan uyarlamalar kimin sorumluluğunda?
- Yeni özellik istekleri bakımın içinde mi, ayrı bir iş olarak mı değerlendirilir?
- Mağaza yorumlarının takibi ve sürüm notları kimde?
Bunny Soft yayın ve bakımı nasıl yürütüyor?
App Store ve Google Play hesaplarının hazırlanmasından mağaza açıklamalarına ve başvuruya kadar yayın sürecini biz yürütüyoruz. İnceleme süreleri ve kuralları mağazalara bağlı olduğu için yayın planını bunu hesaba katarak yapıyor, mağazalardan gelen geri bildirimlere göre gerekli düzenlemeleri üstleniyoruz.
Bakımın kapsamını yayından önce sizinle netleştiriyoruz. Yayından sonra işletim sistemi güncellemelerine uyum, hata düzeltme ve yeni özellikler için yanınızdayız; kullanım geri bildirimlerine göre uygulamayı güncel tutuyor, mağazalarda çalışır kalmasını takip ediyoruz. Daha önce yaptırdığınız uygulama güncellenmediği için eskidiyse, durumunu birlikte değerlendirebiliriz.
Yayından sonra da güncel ve çalışır kalan bir uygulama için mobil uygulama geliştirme sayfamızda kapsamı ve süreci bulabilirsiniz.
