Mobil Uygulama Geliştirme Süreci: Fikirden Mağaza Yayınına

Mobil uygulama geliştirme süreci, bir fikrin gereksinim listesine, tasarıma, çalışan bir yazılıma ve sonunda uygulama mağazasındaki bir sayfaya dönüştüğü sıralı bir yoldur. Her adımda verilen karar, bir sonrakinin ne kadar sorunsuz geçeceğini belirler. Bu yazıda süreci, proje yürütürken izlediğimiz sırayla ve sizden beklenen kararlarla birlikte anlatıyoruz.

Mobil uygulama geliştirme süreci hangi aşamalardan oluşur?

Her proje kendine özgüdür, ancak büyük çerçeve çoğu uygulamada aynıdır:

1. Gereksinim: uygulamanın amacı, kullanıcıları ve kapsamı netleştirilir.
2. Tasarım: ekran akışı ve arayüz çizilir, sizinle birlikte onaylanır.
3. Geliştirme: mobil uygulama ve arkasındaki sunucu tarafı yazılır.
4. Test, düzenleme ve yeniden inceleme: hatalar bulunur, giderilir ve düzeltmeler yeniden kontrol edilir.
5. Mağaza hazırlığı ve inceleme: hesaplar, mağaza sayfası, gizlilik politikası ve yayın onayı.
6. Yayın sonrası bakım: güncelleme, izleme ve destek.

Bu sıra katı bir şelale değildir; bir aşamada eksik fark edildiğinde öncekine dönmek gerekebilir. Yine de sırayı korumak yeniden işi azaltır. Kendi iş planımız da arayüzü olan projelerde Tasarım, Geliştirme, Test, Düzenleme ve Yeniden İnceleme şeklinde ilerler.

Gereksinim aşaması: uygulamanın hangi sorunu çözeceğini yazıya dökün

İlk görüşmede "bir uygulama yapalım" demek yeterli değildir. Asıl soru, uygulamanın kimin hangi sorununu çözeceğidir. Kullanıcı bir müşteri mi, bir çalışan mı, bir saha ekibi mi? Uygulamayı açtığında yapmak istediği ilk iş nedir? Bu yanıtlar ekranların ve özelliklerin temelini oluşturur.

Bu aşamanın çıktısı kısa bir kapsam belgesidir. İçinde şunlar bulunmalıdır:

• Kullanıcı rolleri (örneğin müşteri ve işletme yöneticisi) ve her rolün yapabilecekleri.
• Uçtan uca temel senaryolar: kayıt olma, giriş, asıl işlem, işlem sonrası bildirim.
• İlk sürümde mutlaka olması gereken özellikler ile sonraya bırakılan fikirler.
• Uygulamanın konuşacağı diğer sistemler: mevcut bir veritabanı, ödeme altyapısı, e-posta ya da bildirim servisi.
• Hedef platformlar: yalnızca Android mi, Android ve iOS birlikte mi?

Teknik kapsam kararları da bu aşamada netleşir. Kullanıcı hangi yöntemle giriş yapacak: e-posta ve parola mı, telefon numarası ve tek kullanımlık kod mu? Uygulama internet olmadan da çalışacak mı?

Birden fazla dil gerekecek mi? Hangi işletim sistemi sürümlerinden başlayarak destek verilecek? Anlık bildirim kullanılacak mı? Bu soruların her biri ekran sayısını, test yükünü ve sunucu tarafı işini doğrudan etkiler.

Yanıtları baştan yazılı hale getirmek, sonradan sürpriz çıkmasını önler.

İlk sürümü küçük tutmak, gerçek kullanıcı geri bildirimini erken almanızı sağlar. Hesap, rezervasyon ya da sipariş gibi veriler tutacak bir uygulamanın arkasında sunucu ve veritabanı da olacağı için bunlar baştan kapsama girer. Planlamanın ayrıntıları için yazılım projesi nasıl planlanır yazımıza bakabilirsiniz.

Tasarım aşaması: akışı ekranda görmeden kod yazılmaz

Tasarım, önce basit çizimlerle ekranların sırasını belirlemekle başlar; ardından renkler, yazı tipleri ve bileşenlerle arayüz tasarımına, gerekirse tıklanabilir bir prototipe dönüşür. Amaç, güzel görünmekten önce kullanıcının hiç düşünmeden ilerleyebildiği bir akış kurmaktır.

Android ve iOS kullanıcılarının alışkanlıkları farklıdır. Geri dönme hareketi, gezinme çubuğu ya da bildirim izni isteme biçimi gibi ayrıntılar bu yüzden tasarımda ele alınır. Yazı boyutu, renk kontrastı ve dokunma alanlarının büyüklüğü gibi erişilebilirlik konuları da bu aşamada çözülür.

Çalışma biçimimizde tasarım ve işleyiş kararlarına canlı olarak katılabilirsiniz. Bu önemlidir, çünkü bir ekranı geliştirme başladıktan sonra baştan çizmek, tasarım aşamasında değiştirmekten neredeyse her zaman daha fazla emek ister.

Geliştirme aşaması: uygulama, sunucu ve veritabanı birlikte ilerler

Bir mobil uygulama çoğu zaman yalnızca telefondaki ekranlardan oluşmaz. Dört parça birlikte düşünülür:

• Mobil istemci: kullanıcının gördüğü uygulama. Android ve iOS için tek kod tabanıyla (Flutter) ya da platforma özgü olarak yazılabilir.
• Arka uç (API): uygulamanın veri alıp gönderdiği sunucu tarafı. Bizde genellikle ASP.NET Core ile kurulur.
• Veritabanı: kayıtların tutulduğu yer; SQL Server ya da MySQL.
• Yardımcı hizmetler: anlık bildirim ve kimlik doğrulama gibi işler için Firebase'in sunduğu hizmetler.

İstemci tarafında tek kod tabanı mı yoksa platforma özgü geliştirme mi seçileceği ayrı bir karardır; karşılaştırmasını Flutter mı yerel geliştirme mi yazımızda ele aldık. Geliştirme boyunca ilerlemeyi ekran görüntüleriyle e-posta yoluyla bildiririz. Böylece bitmiş üründe sürprizle değil, adım adım gördüğünüz ve onayladığınız bir işle karşılaşırsınız.

Geliştirme sırasında yalnızca ekranlar değil, veri güvenliğine ilişkin kararlar da alınır: kullanıcıların yalnızca kendi verilerini görmesini sağlayan yetki kuralları, parolaların ve oturum bilgilerinin korunması, sunucu ile uygulama arasındaki iletişimin şifrelenmesi gibi. Bunlar sonradan eklenmesi zor konulardır; bu yüzden baştan tasarıma dahil edilirler. Sade arayüz de bu aşamada bir tercihtir: aksi belirtilmedikçe uygulamayı gereksiz seçeneklerle doldurmadan, karışıklık yaratmayacak biçimde sade tutarız.

Test, düzenleme ve yeniden inceleme: gerçek koşullarda deneyin

Testin amacı, uygulamanın yalnızca yazarının cihazında değil, kullanıcıların elindeki farklı koşullarda da çalıştığını görmektir. Test listesine en az şunlar girer:

• Farklı ekran boyutları ve işletim sistemi sürümleri.
• Zayıf, kesintili ya da hiç olmayan internet bağlantısı.
• Konum, bildirim ve kamera gibi izinlerin reddedildiği durumlar.
• Uygulamanın arka plana alınıp geri dönülmesi, telefonun döndürülmesi, arama ile bölünmesi.
• Kayıttan asıl işleme kadar uçtan uca akışın bir test hesabıyla baştan sona denenmesi.
• Uygulama yeni sürüme güncellenirken kullanıcı verisinin korunması.

Bulunan hatalar düzenleme aşamasında giderilir, ardından düzeltmeler yeniden incelenir. Yeniden inceleme adımı önemlidir, çünkü bir hatayı düzeltirken başka bir yeri bozmak sık görülen bir durumdur. Son iki adımı atlamak ya da sıkıştırmak, hataların kullanıcıya ulaşması anlamına gelir.

Mümkünse uygulamayı yayından önce sınırlı bir kullanıcı grubuyla deneyin. Mağazalar bu amaçla test dağıtım kanalları sunar; iç test ve davetli kullanıcılarla yapılan kapalı test gibi seçeneklerin kapsamı mağazaya göre değişir. Gerçek kullanıcılar, ekibin hiç aklına getirmediği yolları dener: beklenmedik bir sırada düğmeye basmak, formu yarım bırakmak, uygulamayı günlerce açık tutmak. Bu geri bildirim, yayından sonra yaşanacak hayal kırıklığını azaltır.

Mağaza hazırlığı ve inceleme: yayından önce gerekenler

Yayın, kodun bitmesiyle değil, mağaza gereksinimlerinin karşılanmasıyla gerçekleşir. Hazırlanacaklar şunlardır:

• Geliştirici hesapları: Google Play ve App Store için ayrı hesap gerekir. Hesabın kurum adına açılması önemlidir; uygulama hesap sahibinin adıyla yayımlanır ve uygulamanın sahipliği hesapla birlikte yürür.
• Mağaza sayfası: uygulama adı, kısa ve uzun açıklama, simge, ekran görüntüleri, kategori ve yaş derecelendirmesi.
• Gizlilik politikası: herkesin erişebildiği bir web adresinde yayımlanmış olmalıdır. Ayrıntıları mobil uygulama gizlilik politikası nasıl hazırlanır yazımızda anlattık.
• Veri beyanı: mağazaların "hangi verileri topluyorsunuz" diye sorduğu formlar.
• İnceleme için test hesabı: giriş gerektiren uygulamalarda inceleyicinin kullanabileceği bir hesap ve kısa bir kullanım notu.

Mağazalar uygulamayı yayımlamadan önce inceler. İncelemenin ne kadar süreceğini mağaza ve dönem belirler; bu yüzden yayın tarihini biraz esneklikle planlamak gerekir. Sık görülen ret nedenleri arasında eksik ya da açılmayan gizlilik politikası, inceleyiciye çalışan bir test hesabı verilmemesi, mağaza açıklaması ile uygulamanın uyuşmaması ve uygulamanın çökmesi sayılabilir. Mağaza kuralları zaman içinde değiştiği için güncel gereksinimleri yayından önce mağazaların kendi belgelerinden kontrol edin.

Yayın sonrası: bakım sürecin devamıdır

Uygulama yayına çıktıktan sonra iş bitmez. İşletim sistemleri yeni sürümler çıkarır, mağazalar kurallarını günceller, kullanıcılar uygulamayı hiç öngörülmeyen biçimlerde kullanır ve sunucu tarafında güvenlik güncellemeleri gerekir. Yayın sonrası dönemde şunlara ihtiyaç duyarsınız:

• Çökme ve hata raporlarının düzenli izlenmesi.
• İşletim sistemi ve kütüphane güncellemelerine uyum.
• Kullanıcı geri bildirimine dayalı küçük iyileştirmeler ve yeni sürümler.
• Sunucu, veritabanı ve yedekleme bakımı.
• Sorunları iletebileceğiniz bir destek kanalı.

Bakım kapsamını proje başında konuşmak, sonradan "uygulama neden çalışmıyor" sorusuyla karşılaşmanızı önler.

Yayından sonraki ilk dönem özellikle önemlidir. Gerçek kullanıcılar gelmeye başlayınca hangi ekranlarda takıldıkları, hangi özelliği hiç kullanmadıkları ve hangi hataların tekrarlandığı görünür hale gelir. Bu bilgiyi toplayıp önceliklendirmek, ikinci sürümü tahmine değil gözleme dayandırmanızı sağlar.

Özetle süreç şu sırayla ilerler: gereksinim, tasarım, geliştirme, test ve düzenleme, mağaza hazırlığı, bakım. Uygulama fikrinizi bu çerçevede değerlendirmek için mobil uygulama geliştirme hizmetimize göz atabilir, sorularınız için yazılım iletişim sayfamızdan bize yazabilirsiniz.