Mobil Uygulama Nasıl Yaptırılır? Teknoloji, Mağaza Süreci ve Fiyat

Mobil uygulama projelerinde en sık yaşanan sürpriz teknik değil idari oluyor. Uygulama biter, test edilir, herkes memnundur; sonra mağaza inceleme aşamasında reddedilir ve proje iki hafta durur. Red gerekçesi de genelde kodla ilgili değildir: eksik bir gizlilik formu, inceleme ekibine verilmemiş bir test hesabı ya da uygulamanın web sitesinin kabuğu gibi görünmesi. Mobil uygulama nasıl yaptırılır sorusunun cevabı da bu yüzden kod yazdırmakla bitmiyor; işin yarısı hesaplar, beyanlar ve mağaza kurallarında geçiyor.

Bu yazı mobil uygulama yaptırmak isteyen tarafın bilmesi gerekenleri anlatıyor. Native ile cross-platform arasındaki kararı, geliştirici hesaplarının nasıl açıldığını, Apple ve Google inceleme süreçlerini, en sık red sebeplerini, gizlilik formlarını, sürüm bakımının neden hiç bitmediğini ve aynı iş için gelen tekliflerin neden birbirinden ayrıştığını kalem kalem yazıyoruz. Uygulamanın gerekip gerekmediği kararını ise ayrı bir yazıda, web sitesi mi mobil uygulama mı karşılaştırmasında ele aldık.

Mobil uygulama nasıl yaptırılır: ilk karar native mi, cross-platform mı

Yaptırma sürecinde imza atılan ilk teknik karar budur ve sonraki her kalemi etkiler. Karar, moda olan teknolojiye göre değil uygulamanın cihazla ne kadar iç içe olacağına göre verilir. Cross-platform yaklaşımda tek kod tabanından iki mağazaya çıkılır; native yaklaşımda her platform kendi diliyle ayrı yazılır.

Pratik kural şu: uygulamanız ağırlıklı olarak veri gösteriyor, form dolduruyor, liste ve detay ekranları içeriyorsa cross-platform doğru karardır ve maliyeti yarıya yakın düşürür. Kamera ile gerçek zamanlı işlem, arka planda sürekli konum takibi, ağır animasyon veya oyun benzeri etkileşim varsa native tarafa geçmek gerekir. Karma model de mümkündür: uygulamanın çoğu cross-platform, kritik bileşen native yazılır.

Başlamadan önce açılması gereken hesaplar

Bu adım ihmal edilince proje sonunda beklenmedik gecikme üretiyor, çünkü hesap açma süreçleri şirket belgesi doğrulaması gerektiriyor ve günlerce sürebiliyor.

• Apple Developer Program. Yıllık yenilenen ücretli bir üyelik (yazının yazıldığı dönemde 99 ABD doları/yıl; güncel tutar Apple'ın sayfasından teyit edilmeli). Şirket adına açılacaksa D-U-N-S numarası istenir; numaranız yoksa başvurup beklemeniz gerekir.
• Google Play Console. Tek seferlik kayıt ücreti alınır (yazının yazıldığı dönemde 25 ABD doları). Kuruluş hesapları için de kimlik ve adres doğrulaması yapılır.
• Hesaplar sizin adınıza açılmalı. Ajansın kendi hesabından yayınlanan uygulamalar, ilişki bittiğinde devir sorunu üretir. Uygulama sizin geliştirici hesabınızda yayınlansın; geliştiriciye ekip üyesi olarak yetki verin.
• İmzalama anahtarları. Android tarafında uygulama imzalama anahtarının, iOS tarafında sertifika ve profillerin kimde durduğu ve nasıl yedeklendiği yazılı olsun. Kaybedilen imzalama anahtarı, uygulamayı güncelleyememek demektir.

Mobil uygulama nasıl yaptırılır: süreç hangi adımlardan geçer

Süreç, web projesinden bir noktada ayrılıyor: yayınlanan sürümü geri alamazsınız. Web'de hatalı bir değişikliği dakikalar içinde geri alabilirsiniz; mağazada yayınlanmış bir sürüm kullanıcının cihazındadır ve düzeltme yeni bir sürüm ve yeni bir inceleme gerektirir. Süreç bu gerçeğe göre kurulur.

1. Kapsam ve akış tasarımı. Hangi ekranlar, hangi sırayla ve hangi veriyi gösterecek. Mobilde ekran alanı kısıtlı olduğu için kapsam disiplini web'den daha önemlidir.
2. Tasarım ve tıklanabilir prototip. Akış cihazda denenmeden koda geçilmemeli; telefonda parmakla denendiğinde masaüstünde fark edilmeyen sorunlar ortaya çıkar.
3. Geliştirme ve dağıtımlı test. Sürümler TestFlight ve Play test kanalları üzerinden gerçek cihazlara dağıtılır. Simülatörde görünmeyen izin, bildirim ve performans sorunları burada çıkar.
4. Mağaza hazırlığı. Uygulama adı, açıklama, ekran görüntüleri, kategori, yaş sınırı, gizlilik politikası bağlantısı ve gizlilik formları.
5. İnceleme ve yayın. İki mağazaya ayrı ayrı gönderilir, ayrı ayrı incelenir.
6. Yayın sonrası izleme. Çökme raporları, sürüm bazlı hata takibi ve mağaza yorumlarına yanıt.

Mağaza yayın süreci: Apple ve Google incelemesi

App Store tarafı

Apple, her sürümü insan incelemesinden geçirir ve kuralları App Store İnceleme Yönergeleri'nde yayımlar. İncelemeyi hızlandıran şey teknik mükemmellik değil, inceleme ekibinin uygulamayı sorunsuz kullanabilmesidir. Bunun için gönderim notlarına çalışan bir test hesabı, gerekiyorsa doğrulama kodunun nasıl alınacağı ve özel bir donanım gerekiyorsa açıklaması eklenir. Test hesabı verilmemiş uygulamalar, uygulamada hiçbir sorun olmasa bile reddedilir.

Google Play tarafı

Google Play tarafında inceleme daha çok otomatik kontrollerle başlar, ancak politika ihlali şüphesinde manuel incelemeye düşer. Play'in kendine özgü iki başlığı var: uygulamanın belirli bir güncellikte hedef API seviyesine uyması ve yeni açılan bireysel geliştirici hesaplarında üretime geçmeden önce kapalı test şartının karşılanması. Bu şart, belirli sayıda test kullanıcısıyla belirli bir süre kesintisiz test yapılmasını gerektirir; kuruluş hesaplarında uygulanmaz. Şirket adına başvuruyorsanız hesabı bireysel değil kuruluş olarak açmak proje takvimini korur.

En sık red sebepleri

Aşağıdaki liste, mobil projelerde tekrar tekrar karşımıza çıkan gerekçeler. Neredeyse tamamı geliştirmeden önce önlenebilir.

• Uygulama, web sitesinin kabuğu gibi çalışıyor. İçeriği bir tarayıcı penceresinde gösteren, cihazın hiçbir yeteneğini kullanmayan uygulamalar asgari işlevsellik gerekçesiyle reddedilir. Bu, e-ticaret uygulamalarında en sık düşülen tuzaktır.
• Test hesabı verilmemiş veya çalışmıyor. Giriş gerektiren uygulamalarda incelemeci içeri giremezse süreç orada biter.
• Yer tutucu içerik. Örnek metin, boş kategori, çalışmayan buton veya "yakında" yazan ekranlar tamamlanmamışlık sayılır.
• Hesap silme seçeneğinin bulunmaması. Uygulama içinde hesap oluşturulabiliyorsa, hesabın uygulama içinden silinebilmesi de gerekir. Yalnızca "bize e-posta atın" demek yeterli değildir.
• Gereksiz izin istemek. Kullanılmayan bir yeteneğin izni isteniyorsa ya da izin isteme gerekçesi açıklanmıyorsa red gelir. Her izin, ne için istendiğini anlatan bir metinle birlikte istenmelidir.
• Dijital içerik satışında mağaza ödeme kuralları. Uygulama içinde tüketilen dijital içerik ve abonelikler mağazanın ödeme sistemini gerektirir. Fiziksel ürün ve uygulama dışında tüketilen hizmet satışı bu kuralın dışındadır; e-ticaret uygulamalarının kendi ödeme altyapısını kullanabilmesinin sebebi budur.
• Meta veri uyumsuzluğu. Ekran görüntülerinin uygulamada olmayan özellikleri göstermesi ya da açıklamanın gerçeği yansıtmaması.
• Gizlilik beyanı ile uygulamanın davranışının uyuşmaması. Formda toplanmadığı söylenen bir verinin toplandığının görülmesi en sert gerekçelerden biridir.

Gizlilik formları ve izinler

İki mağaza da uygulamanın hangi veriyi topladığını beyan etmenizi istiyor: App Store tarafında uygulama gizlilik bilgileri, Play tarafında veri güvenliği formu. Bu formlar tek seferlik bir işlem gibi görünse de, uygulamaya sonradan eklenen her analiz aracı, reklam kütüphanesi veya destek widget'ı beyanı değiştirebilir. Bu yüzden formu geliştirici değil, uygulamada hangi üçüncü taraf araçların bulunduğunu bilen taraf onaylamalı.

Ek olarak iOS tarafında, uygulamanın ve kullandığı hazır bileşenlerin gizlilik bildirimi dosyası taşıması ve belirli sistem çağrılarının kullanım gerekçesinin beyan edilmesi isteniyor. Reklam ölçümü için kullanıcıyı farklı uygulamalar arasında takip etmek istiyorsanız ayrıca izleme izni sorulması gerekiyor; kullanıcı izin vermezse ölçüm sınırlı kalır ve bu, reklam planınızı doğrudan etkiler.

Bildirim izni tarafında da iki platform ayrışıyor: iOS'ta bildirim izni her zaman kullanıcıdan açıkça istenir, Android'de ise güncel sürümlerde ayrı bir bildirim izni sorulur. İznin ne zaman ve nasıl sorulacağı, bildirim stratejisinin en belirleyici kararıdır; bunu push bildirim yazısında ayrıntısıyla anlattık.

Sürüm bakımı neden hiç bitmiyor

Mobil uygulamada "bitti" diye bir durum yok; çünkü uygulamanın altındaki zemin sizden bağımsız değişiyor. Hiç yeni özellik istemeseniz bile şu işler gelir:

• Yıllık işletim sistemi sürümleri. Her sonbahar yeni iOS ve Android sürümü çıkar; arayüzde bozulma, izin davranışında değişiklik veya kullanımdan kaldırılmış çağrılar ortaya çıkabilir.
• Mağaza politikası güncellemeleri. Hedef API seviyesi zorunlulukları ve yeni beyan gereklilikleri, güncelleme yayınlayabilmenizin ön şartı hâline gelir.
• Sertifika ve anahtar yenileme. Süresi dolan sertifikalar bildirim gönderimini veya yeni sürüm yayınlamayı durdurabilir.
• Bağımlılık güncellemeleri. Kullanılan kütüphanelerin güvenlik yamaları ve sürüm atlamaları.
• Cihaz çeşitliliği. Yeni ekran oranları ve yeni cihaz sınıfları, düzenin test edilmesini gerektirir.

Bakımsız bırakılan uygulamalarda tipik sonuç şudur: bir yıl sorunsuz çalışır, sonra bir işletim sistemi sürümüyle açılışta çöker ya da mağaza politikası sebebiyle güncelleme kabul edilmez. İkinci durum daha kötüdür, çünkü hatayı düzeltmek için gereken güncellemeyi de yayınlayamazsınız. Bu yüzden bakım anlaşması, mobilde web'e göre daha kritik bir kalemdir.

Test süreci: simülatörde görünmeyenler

Mobil projelerde teslim kalitesini belirleyen şey, testin gerçek cihazda yapılıp yapılmadığı. Geliştirici bilgisayarındaki simülatör hızlı ve temiz bir ortamdır; kullanıcının telefonu değildir. Gerçek cihazda ortaya çıkan ve simülatörde neredeyse hiç görünmeyen başlıklar şunlar:

• İzin akışları. Bildirim, konum, kamera ve fotoğraf erişimi izinlerinin reddedildiği durumda uygulamanın ne yaptığı. Reddedilen izinle çöken uygulamalar bu yüzden yayına çıkıyor.
• Zayıf ve kesintili bağlantı. Asansörde kopan bağlantı, yavaş mobil veri, uçak modundan dönüş. Uygulamanın bu durumlarda kullanıcıya ne söylediği, teknik kalitenin en görünür göstergesi.
• Farklı ekran oranları ve yazı tipi boyutları. Kullanıcı sistem yazı boyutunu büyütmüşse düzenin bozulup bozulmadığı.
• Pil ve ısınma. Arka planda çalışan konum veya sürekli ağ isteği yapan ekranlar, cihazı ısıtır ve kullanıcı bunu fark eder.
• Bildirimden açılış. Uygulama tamamen kapalıyken gelen bildirime tıklanınca doğru ekrana gidip gitmediği; bu senaryo test edilmediği için sık atlanıyor.
• Güncelleme senaryosu. Eski sürümü yüklü bir cihazda yeni sürüme geçildiğinde yerel verinin bozulup bozulmadığı. Temiz kurulumda çalışan uygulamalar bu senaryoda çökebiliyor.

Bu listeyi kabul testine dahil edin ve testi kendi ekibinizin telefonlarıyla, farklı marka ve işletim sistemi sürümleriyle yapın. Test kanallarına (TestFlight ve Play test kanalları) birkaç gerçek kullanıcı eklemek, mağaza incelemesine gitmeden önce yakalanan hata sayısını belirgin biçimde artırıyor.

Teklif isterken hangi kalemleri tarif etmelisiniz

Aynı brief için gelen teklifler firmadan firmaya kat kat değişebiliyor. Sebebi keyfîlik değil, kapsamın her tarafta farklı okunması: biri sadece iki mağazaya çıkmayı anlıyor, diğeri sunucu tarafını ve bakımı da içeri alıyor. Maliyet kalemlerinin ayrıntılı dökümünü ve neyin neye dahil olduğunu mobil uygulama geliştirme sayfamızda topladık; buradaki liste ise farklı firmalardan gelen teklifleri aynı ölçekte kıyaslayabilmek için kendi brief'inizde tarif etmeniz gereken başlıklar. Aşağıdaki her satır, açık bırakıldığında teklifler arasındaki farkın kaynağına dönüşüyor:

Bu on satırı kendi projeniz için işaretleyip firmalara aynı listeyle sorarsanız rakamlar kıyaslanabilir hâle gelir. Teklif karşılaştırma yöntemini ve sözleşmede aranacak maddeleri yazılım projesi yaptırma rehberinde yazdık.

Yayınlamak bitiş değil, başlangıç

Uygulamanın mağazada olması indirileceği anlamına gelmiyor. Yayın sonrası ilk ayda kurulması gereken üç şey var: çökme ve hata izleme, sürüm bazlı kullanım ölçümü ve mağaza yorumlarına yanıt verme alışkanlığı. Üçüncüsü en çok atlanan ve en ucuz olanı; yorumlara verilen yanıtlar hem mağaza sayfasının güvenilirliğini artırır hem de hatanın hangi cihazlarda yaşandığını öğrenmenin en hızlı yoludur.

Bir de indirilme sayısı yerine bakılması gereken bir şey var: ilk açılıştan sonra geri dönen kullanıcı oranı. İndirme reklamla artırılabilir, geri dönüş artırılamaz; uygulamanın gerçekten bir işe yarayıp yaramadığını gösteren ölçü budur.

Biz nasıl çalışıyoruz

Mobil tarafta iki ayrı iş yürütüyoruz. Birincisi sıfırdan isteğe özel uygulamalar: randevu, saha, sadakat, iç operasyon ya da tamamen yeni bir ürün fikri. İkincisi mevcut e-ticaret sitesine tam entegre mağaza uygulamaları; burada üyeler, sepet ve siparişler siteyle ortak çalışır ve ikinci bir müşteri veritabanı oluşmaz. İkinci başlığı ayrı bir yazıda, e-ticaret mobil uygulaması yazısında ayrıntılı anlattık.

Geliştirici hesaplarını sizin adınıza açıyor, imzalama anahtarlarının sizde kalmasını sağlıyor ve mağaza gönderimlerini biz yürütüyoruz. Kapsam ve süreç için mobil uygulama geliştirme sayfamıza bakabilir, projenizi konuşmak için iletişim sayfasından yazabilirsiniz.