İmzalanmış bir kapsamdan mağazadaki bir uygulamaya altı ila on hafta kulağa hızlı geliyor. Hızlı; ama ilk sürüm gerçekten bir ilk sürüm olarak tasarlandığı sürece aynı zamanda gerçekçi. Aylarca uzayan projelerin çoğu, üçüncü sürümü ilk sürüm olarak yayınlamaya çalıştığı için uzar.
Bu takvimin gerçekte nasıl işlediğini ve sonrasında neler geldiğini anlatıyoruz.
İlk sürümün ne için olduğuna karar verin
MVP (minimum uygulanabilir ürün), tam fikrinizin daha ucuz ve daha kötü bir sürümü değildir. En önemli sorunuzu yanıtlayabilecek en küçük üründür: insanlar bunu kullanacak mı, geri dönecek mi ve zamanla para ödeyecek mi?
Bu, kapsamı nasıl daralttığınızı değiştirir. "Neyi çıkarabiliriz?" yerine "kullanıcının mutlaka tamamlayabilmesi gereken tek yolculuk ne?" diye sorun. Bir randevu uygulaması için bu, boş bir saat bulup randevu almaktır. Bir oyun için, temel döngünün arka arkaya iki kez eğlenceli olmasıdır. Bu yolculuğa hizmet etmeyen her şey ikinci sürümü bekler:
- Yönetim panelleri çoğu zaman basit bir iç araç ya da bir tabloyla başlayabilir.
- Beş farklı giriş seçeneği ikiyle başlayabilir.
- Ayar ekranları, temalar ve uç durum özellikleri gerçek kullanıcı geri bildirimini bekleyebilir.
İyi bir test: Bir özellik, birinin uygulamayı yarın kullanıp kullanmayacağını değiştirmiyorsa, ilk sürüme ait değildir.
Hafta hafta takvim
Hafta 0: tanışma görüşmesi
Fikri, kullanıcıları ve kısıtları anlamak ve uyum konusunda dürüst olmak için otuz dakika. Bazı projelere farklı bir yaklaşım ya da farklı bir ekip daha iyi hizmet eder.
Hafta 1: sabit ve yazılı kapsam
İlk sürümün tam olarak ne yaptığını, hangi platformlarda çalıştığını, neyin açıkça kapsam dışında olduğunu ve sabit bir fiyatı listeleyen bir belge. Projenin en değerli haftası budur; burada harcanan her saat sonradan birkaç saat kazandırır.
Hafta 2–3: tasarım
Önce kullanıcı akışları, sonra kendi telefonunuzda açabileceğiniz tıklanabilir bir prototip. Prototipte bir ekranı değiştirmek dakikalar sürer; geliştirildikten sonra değiştirmek günler. En talepkâr olmanız gereken yer burası.
Hafta 4–9: geliştirme
Uygulama ve sunucu tarafı haftalık adımlarla geliştirilir ve her hafta kurabileceğiniz yeni bir derleme alırsınız: iPhone'da TestFlight, Android'de bir test kanalı. Bir ilerleme raporunu değil, ürünün büyümesini izlersiniz. Küçük ayarlamalar yol boyunca yapılır; büyük yeni fikirler, tarih tutsun diye ikinci sürüm listesine yazılır.
Yayın
Mağaza sayfaları, ekran görüntüleri ve gizlilik yanıtları hazırlanır, uygulama incelemeye gönderilir ve kendi geliştirici hesaplarınız altında yayına girer.
Mağazalar yayından önce neyi kontrol eder?
Apple da Google da uygulamaları yayınlamadan önce inceler ve ikisi de önceden bilindiğinde tamamen önlenebilecek sebeplerle uygulama reddeder. İlk yayınlarda sık karşılaşılanlardan birkaçı:
- Gizlilik beyanları. Apple'ın App Privacy bölümü ve Google Play'in Veri güvenliği formu, uygulamanın ve içindeki her SDK'nın (analitik ve reklamlar dahil) gerçekte topladığı verilerle birebir örtüşmelidir.
- Hesap silme. Kullanıcılar uygulamanızda hesap oluşturabiliyorsa Apple, hesabı silme işlemini de uygulamanın içinden başlatabilmelerini şart koşar; Google Play de silme talebinin yapılabileceği bir web bağlantısı ister.
- Dijital satın almalar. Uygulama içinde satılan dijital ürünler ve abonelikler genellikle mağazanın kendi uygulama içi satın alma sisteminden geçmek zorundadır.
- Eksiksizlik. Yer tutucu içerik, kırık bağlantılar, çalışmayan demo hesaplar ya da inceleyiciye verilmemiş bir giriş gerektiren özellikler sık görülen ret sebepleridir.
- Yeni hesaplar için Google Play testi. Bu yazı yazılırken, yeni açılmış kişisel geliştirici hesapları üretime yayın yapabilmek için en az 12 test kullanıcısıyla 14 gün süren kapalı bir test yürütmek zorunda. Bunu takvime dahil edin.
Apple'ın incelemesi çoğu zaman bir iki gün içinde sonuçlanır. Ret bir felaket değil, bir mesajdır: yanıtlar, düzeltir ve yeniden gönderirsiniz. Kuralları baştan bilmek, işin nadiren oraya varması demektir.
Yayından sonra: uygulamayı ayakta tutan iş
Yayın günü, uygulamanızın hayatındaki en öğretici dönemin başlangıcıdır. İlk kez gerçek insanların ne yaptığını görürsünüz; ne yapacaklarını varsaydığınızı değil. Ardından gelen iş, büyüyen uygulamaları sessizce sönenlerden ayıran iştir:
- Çökme ve performans takibi. Gerçek cihazlar ve gerçek ağlar, hiçbir test setinin bulamadığı sorunları bulur. İlk haftalar genellikle bir tur hızlı düzeltme getirir.
- Yorumları ve analitiği okumak. İnsanlar nerede bırakıyor? Ne istiyorlar? İkinci sürümün ham maddesi budur.
- Mağaza optimizasyonu (ASO). Mağaza sayfasının başlığı, alt başlığı, ekran görüntüleri ve yerelleştirmesi, uygulamayı bulanlardan kaçının onu kuracağını belirler.
- Her yıl gelen platform değişiklikleri. Apple, yeni gönderimlerin hangi SDK sürümüyle derlenmesi gerektiğini yükseltir; Google Play de güncelleme yayınlamaya devam edebilmek için yakın tarihli bir Android sürümünü hedeflemenizi ister. Bir yıl boyunca dokunulmayan bir uygulama, bir düzeltmeyi bile yayınlayamaz hale gelebilir.
- Gelir altyapısı. Uygulama içi satın almalar, abonelikler ve reklamlar sürekli özen ister: fiyat testleri, yeni ürünler, reklam ağlarının politika değişiklikleri.
Yayından sonra neden yanınızda kalıyoruz?
Bunların hepsini önce kendi uygulamalarımızda öğrendik. Vokap; App Review'dan, 27 dilde mağaza sayfasından, sunucu tarafında doğrulanan ödüllü reklamlardan ve OTA güncellemelerden, bunların hiçbirini bir müşteriye sunmadan çok önce geçti. Projelerimizin "gönderildi" diye bitmemesinin sebebi bu: incelemeyi biz yönetiyor, ilk güncellemelerde yanınızda kalıyor ve uygulamasına işe alım yapmadan düzgün bakılmasını isteyen ekipler için aylık bir destek paketi sunuyoruz.
Burada anlatılana benzer bir ilk sürüme uyan bir fikriniz varsa, ne gerektirdiğini öğrenmenin en hızlı yolu bize bir proje özeti göndermek. Onu kimin geliştirmesi gerektiğine hâlâ karar veriyorsanız, önce stüdyo, freelancer mı, kendi ekibiniz mi yazısını okuyun.