Mobil Uygulama Geliştirme Süreci: Fikirden App Store ve Google Play'e

Mobil uygulama yaptırmak isteyenlerin çoğu süreci ekran tasarımı ve kodlama olarak düşünür. Oysa yayındaki bir uygulamanın arkasında doğrulanmış bir fikir, net bir kapsam, bir sunucu altyapısı, iki farklı mağazanın kuralları ve yayından sonra da süren bir bakım işi vardır. Aşağıda bu aşamaları, her birinde verilmesi gereken kararlarla birlikte sırayla ele alıyoruz.

1. Fikir doğrulama ve MVP kapsamı

İlk soru teknik değil: Bu uygulamayı kim, hangi sorunu çözmek için ve neden mevcut alternatiflerin yerine kullanacak? Hedef kullanıcılarla kısa görüşmeler yapmak, rakip uygulamaların mağaza yorumlarını okumak ve basit bir tanıtım sayfasıyla ilgiyi ölçmek, aylar sürecek bir geliştirmeden önce çok ucuza önemli bilgiler verir.

Ardından MVP (minimum uygulanabilir ürün) kapsamı belirlenir. MVP, özellikleri kırpılmış yarım bir ürün değil; temel değeri eksiksiz sunan en küçük sürümdür. Pratik bir yöntem, istenen tüm özellikleri listeleyip her birini olmazsa olmaz, ilk güncellemede ve belki sonra olarak üç gruba ayırmaktır. İlk sürüme yalnız birinci grup girer. Kapsamı dar tutmak hem yayına çıkış süresini kısaltır hem de gerçek kullanıcı davranışına göre yön değiştirmeyi kolaylaştırır.

2. Keşif ve gereksinim dokümanı

Keşif aşamasında fikir, geliştirme ekibinin üzerinde fiyat ve takvim konuşabileceği somut bir dokümana dönüşür. İyi bir gereksinim dokümanı en az şunları içerir:

• Kullanıcı rolleri (ör. müşteri, hizmet veren, yönetici) ve her rolün yapabildikleri
• Ana kullanıcı akışları: kayıt, giriş, temel işlem, ödeme, profil ve hesap silme
• Ekran listesi ve ekranlar arası geçişler
• Hedef platformlar ve desteklenecek en düşük işletim sistemi sürümleri
• Dış entegrasyonlar: ödeme sağlayıcısı, harita, SMS, e-posta, mevcut ERP ya da CRM sistemleri
• Çevrimdışı çalışma, çoklu dil, erişilebilirlik gibi işlevsel olmayan gereksinimler
• Toplanacak kişisel veriler ve KVKK açısından nasıl işleneceği

Bu doküman olmadan alınan teklifler birbiriyle karşılaştırılamaz; çünkü her ekip belirsiz noktaları farklı varsayımlarla doldurur.

3. Native mi, cross-platform mu?

Native geliştirmede iOS için Swift, Android için Kotlin ile iki ayrı uygulama yazılır. Cross-platform yaklaşımda ise Flutter ya da React Native gibi bir çatıyla tek kod tabanından iki platform için uygulama üretilir. İkisi de yayında milyonlarca kullanıcıya hizmet veren uygulamalarda kullanılıyor; doğru seçim projenin ihtiyacına bağlı.

Pratikte, bütçesi sınırlı ve iki platformda aynı anda çıkmak isteyen projelerin önemli bir kısmı için cross-platform mantıklı bir başlangıçtır. Uygulamanın özü cihaz donanımına derinden bağlıysa ya da tek platformda en iyi deneyim hedefleniyorsa native öne çıkar. Seçimde ekibin gerçek deneyimini de hesaba katın: iyi bilinen bir teknoloji, kâğıt üzerinde daha uygun görünen ama ekibin yeni öğreneceği bir teknolojiden daha az risk taşır.

4. UX/UI tasarımı ve prototip

Tasarım önce tel çerçeve (wireframe) ile akışları, sonra görsel tasarımla marka dilini ele alır. Tıklanabilir bir prototip, tek satır kod yazılmadan hedef kullanıcılarla test edilebilir; bu aşamada fark edilen bir akış hatası, geliştirme sonrasına göre çok daha ucuza düzeltilir. Tasarımda iOS Human Interface Guidelines ve Android Material Design alışkanlıklarını gözetmek, kullanıcının uygulamayı öğrenme eforunu azaltır. Dokunma alanlarının boyutu, metin kontrastı, dinamik yazı boyutu ve karanlık mod desteği baştan planlanmalıdır.

5. Backend, API ve yönetim paneli

Kullanıcı hesapları, içerik, siparişler ya da mesajlar içeren her uygulama bir sunucu tarafına ihtiyaç duyar. Bu katman üç parçadan oluşur: veriyi saklayan veritabanı, uygulamanın veriyle konuştuğu API ve işletmenin içeriği, kullanıcıları ve işlemleri yönettiği yönetim paneli. Yönetim paneli sık unutulan bir kalemdir; olmadığında her içerik değişikliği için geliştiriciye ihtiyaç duyulur.

Hazır backend servisleri (BaaS) başlangıcı hızlandırır, ancak ölçeklendikçe maliyet ve esneklik açısından sınırlara takılabilir. İş kuralları karmaşık, mevcut sistemlerle entegrasyon gerektiren projelerde siteye özel bir backend daha sağlıklıdır; bu tür altyapıları özel yazılım projeleri kapsamında geliştiriyoruz. Hangi yol seçilirse seçilsin API sürümlemesini baştan planlayın: mağazadaki eski sürümü kullanan kullanıcılar, sunucu güncellendiğinde uygulamanın çalışmaya devam etmesini bekler.

6. Bildirim, ödeme, analitik ve diğer bileşenler

• Anlık bildirimler: iOS'ta APNs, Android'de Firebase Cloud Messaging üzerinden çalışır. Bildirim izni istemenin zamanlaması önemlidir; ilk açılışta değil, kullanıcı değerini gördükten sonra istemek izin oranını artırır.
• Ödeme: Fiziksel ürün ve hizmet satışında ödeme kuruluşu entegrasyonu gerekir; dijital içerikte ise aşağıdaki mağaza kuralları devreye girer.
• Analitik: Hangi ekranların kullanıldığını, kullanıcıların nerede vazgeçtiğini ölçmeden ürün kararı vermek tahmine dayanır. Olay (event) planını geliştirmeden önce belirleyin.
• Hata raporlama: Çökme raporları ilk sürümden itibaren entegre olmalı.
• Kimlik doğrulama: E-posta, telefon ya da sosyal giriş. iOS'ta üçüncü taraf sosyal giriş sunan uygulamalar için Apple'ın ek giriş seçeneği koşullarını kontrol edin.
• Akıllı özellikler: Öneri, sınıflandırma, metin ya da görüntü işleme gibi ihtiyaçlar için yapay zekâ çözümleri uygulamaya API üzerinden eklenebilir; burada da kişisel verinin nereye gönderildiği netleşmelidir.

7. Uygulama içi satın alma kuralları

Uygulama içinde dijital içerik ya da özellik satıyorsanız (premium üyelik, abonelik, sanal para, kilidi açılan içerik), hem Apple hem Google genel kural olarak kendi mağaza ödeme sistemlerinin kullanılmasını şart koşar ve bu işlemlerden komisyon alır. Uygulama dışında tüketilen fiziksel ürün ve hizmetlerde (e-ticaret siparişi, taksi yolculuğu, randevu ücreti) ise kendi ödeme altyapınızı kullanabilirsiniz.

8. Test

Mobilde test, masaüstü web'e göre daha zordur; çünkü uygulama çok farklı ekran boyutları, işletim sistemi sürümleri ve donanım kombinasyonlarında çalışır. Bir cihaz matrisi hazırlayın: hedef kitlenizin kullandığı popüler modeller, desteklenen en eski işletim sistemi sürümü, küçük ekranlı ve düşük bellekli bir Android cihaz mutlaka listede olsun. Zayıf bağlantı, çevrimdışı durum, bildirim izninin reddedilmesi, uygulamanın arka plandan dönmesi gibi senaryolar da test planına girmelidir.

• iOS – TestFlight: Apple'ın beta dağıtım aracıdır. Ekip içi test kullanıcılarına hızla dağıtım yapılabilir; ekip dışı test kullanıcılarına açılan sürümler kısa bir beta incelemesinden geçer.
• Android – Google Play test kanalları: Dahili test hızlı ve küçük ekipler içindir, kapalı test davet edilen kullanıcı gruplarıyla, açık test ise herkese açık beta olarak çalışır.

Google Play'de yeni oluşturulan kişisel geliştirici hesapları için ek bir şart bulunuyor: uygulama üretim kanalına çıkmadan önce belirli sayıda test kullanıcısıyla, belirli bir süre boyunca kapalı testten geçmek zorunda. Gerekli test kullanıcısı sayısı ve süre Google tarafından zaman zaman güncellendiği için takvim planlarken Play Console'daki güncel koşulları kontrol edin; bu adım yayın tarihini haftalarca etkileyebilir. Kurum adına açılan organizasyon hesaplarında koşullar farklıdır.

9. App Store ve Google Play'de yayın

Yayın için iki mağazada da geliştirici hesabı gerekir. Apple Developer Program yıllık üyelik ücretiyle, Google Play Console ise tek seferlik kayıt ücretiyle çalışır. Uygulamanın ve hesapların şirket adına açılması, ileride sahiplik sorunlarını baştan önler.

İnceleme ve politika gereksinimleri

• App Store incelemesi: Her yeni uygulama ve güncelleme Apple tarafından incelenir. Eksik işlev, çöken ekranlar, test hesabı verilmemesi ya da açıklamayla uyuşmayan içerik yaygın ret sebepleridir. Giriş gerektiren uygulamalarda inceleme ekibine çalışan bir demo hesabı sağlayın.
• Gizlilik etiketleri ve Data safety formu: App Store'da gizlilik etiketleri, Google Play'de Data safety bölümü, uygulamanın ve içindeki üçüncü taraf SDK'ların hangi verileri topladığını beyan eder. Beyanın gerçek davranışla uyumlu olması gerekir; analitik ve reklam SDK'larını da hesaba katın.
• Gizlilik politikası: Erişilebilir bir URL'de yayında olmalı ve KVKK aydınlatma metninizle tutarlı olmalı.
• Hesap silme: Uygulama içinde hesap oluşturulabiliyorsa, kullanıcının hesabını uygulama içinden silme işlemini başlatabilmesi iki mağazada da beklenir. Google Play ayrıca uygulamayı yeniden yüklemeden hesap silme talebi iletilebilecek bir web bağlantısı ister.

Mağaza sayfası ve ASO

ASO (App Store Optimization), uygulamanın mağaza aramalarında bulunması ve sayfayı görenin indirmeye ikna olmasıyla ilgilidir. Uygulama adı ve alt başlıkta kullanıcının gerçekten aradığı ifadeleri kullanın, ilk iki ekran görüntüsünde temel faydayı gösterin, açıklamanın ilk satırlarını değer önerisine ayırın. Mağaza sayfası metinlerini ve görsellerini yayından sonra da test edip iyileştirin; yorumlara, özellikle olumsuz olanlara yanıt vermek güven sağlar.

10. Yayın sonrası: bakım işin yarısıdır

• Çökme ve performans raporları: Yayının ilk günlerinde çökme oranını yakından izleyin; mağaza görünürlüğünü de etkileyebilir.
• Sürüm güncellemeleri: Hata düzeltmeleri ve kullanıcı geri bildirimine göre yeni özellikler düzenli sürümlerle yayınlanır. Kritik değişikliklerde zorunlu güncelleme mekanizması hazır olmalı.
• İşletim sistemi güncellemeleri: Her yıl yeni iOS ve Android sürümleri çıkar; izinler, bildirimler ve arka plan çalışması gibi davranışlar değişebilir. Beta sürümlerde uygulamanızı önceden test edin.
• Hedef API seviyesi şartları: Google Play, yeni uygulamaların ve güncellemelerin yakın tarihli bir Android API seviyesini hedeflemesini şart koşar ve bu eşik düzenli olarak yükselir. Uzun süre güncellenmeyen uygulamalar yeni kullanıcılara görünmez hale gelebilir. Apple da mağazaya gönderilen derlemeler için güncel Xcode ve SDK sürümlerini zorunlu tutar.
• Bağımlılık güncellemeleri: Kullanılan kütüphanelerde çıkan güvenlik yamaları takip edilmelidir.

Bu döngüyü kendi ürünlerimizde de yaşıyoruz: PatimApp ve Vaybla'yı App Store ve Google Play'de yayına aldık, Nobivo ise şu an test aşamasında. Deneyimimiz, yayın gününün bir bitiş çizgisi değil, asıl ürün çalışmasının başladığı gün olduğunu gösteriyor.

Maliyet ve süreyi belirleyen etkenler

Mobil uygulama maliyeti için tek bir rakam vermek, bir evin fiyatını metrekaresini bilmeden söylemeye benzer. Teklifleri karşılaştırırken şu etkenlerin her birinin nasıl ele alındığına bakın:

• Ekran ve kullanıcı akışı sayısı, kullanıcı rolü çeşitliliği
• Tek platform, iki platform ya da web sürümü de dahil kapsam
• Native veya cross-platform tercihi
• Backend'in hazır servisle mi, siteye özel mi geliştirileceği; yönetim panelinin kapsamı
• Ödeme, harita, gerçek zamanlı mesajlaşma, video gibi entegrasyonlar
• Mevcut ERP, CRM ya da web sitesiyle veri alışverişi
• Özgün tasarım ve animasyon düzeyi
• Çoklu dil, erişilebilirlik ve çevrimdışı çalışma gereksinimleri
• Güvenlik ve KVKK gereksinimleri, veri saklama yeri
• Test kapsamı ve cihaz matrisi
• Yayın sonrası bakım, sunucu ve üçüncü taraf servis giderleri

Yazılım ekibi seçerken sorulacak sorular

1. Kaynak kodun sahibi kim olacak? Kodun, tasarım dosyalarının ve dokümantasyonun proje sonunda size teslim edileceği sözleşmede yazmalı.
2. Mağaza ve sunucu hesapları kimin adına açılacak? Apple, Google, sunucu ve alan adı hesapları şirketinizin adına olmalı; ekip bu hesaplara yetkili kullanıcı olarak eklenmeli.
3. Daha önce yayına aldığınız uygulamaları mağazada gösterebilir misiniz? Referans ekran görüntüsü değil, indirilebilir uygulama isteyin.
4. Yayın sonrası bakım nasıl işleyecek? Hata düzeltme süresi, işletim sistemi uyumluluk güncellemeleri ve bakım ücreti baştan konuşulmalı.
5. Süreç nasıl yönetilecek? Ara teslimler, test sürümlerine erişim, kapsam değişikliklerinin nasıl fiyatlandırılacağı netleşmeli.
6. Test ve kalite güvencesi nasıl yapılıyor? Hangi cihazlarda, hangi senaryolarla test edildiğini sorun.

Fikrinizi bir MVP kapsamına dönüştürmek, teknoloji seçimini netleştirmek ya da mevcut uygulamanızın bakımını devretmek istiyorsanız mobil uygulama geliştirme hizmetimizi inceleyebilir ya da iletişim formundan Ankara'daki ekibimize ulaşabilirsiniz.

Yazan: ArGetia ekibi · Ankara, Türkiye