Mobil Uygulama Geliştirme Süreci: Adım Adım Rehber

Bir mobil uygulama fikri çoğu zaman net bir ihtiyaçtan doğar; ancak o fikri mağazada yayında olan ve kullanıcıların düzenli olarak açtığı bir ürüne dönüştürmek planlı bir süreç gerektirir. Bu yazıda mobil uygulama geliştirme sürecini, kurumlarla çalışırken izlediğimiz adımlar üzerinden baştan sona anlatıyoruz. Amacımız, karar vericilerin projeye başlamadan önce hangi soruları sormaları ve hangi kararları vermeleri gerektiğini netleştirmek.

Hedefi ve Kullanıcıyı Tanımlamak

Her şeyden önce uygulamanın neden var olacağı sorusunu cevaplamak gerekir. Uygulama sahadaki personelin işini mi hızlandıracak, vatandaşlara ya da müşterilere yeni bir hizmet kanalı mı açacak, yoksa mevcut bir web hizmetinin mobil karşılığı mı olacak? Bu sorunun cevabı kapsamı, teknoloji seçimini ve yayın modelini doğrudan belirler.

Hedefi yazarken ölçülebilir bir başarı tanımı yapmak işi kolaylaştırır. “Kullanıcılar talep oluşturabilsin” yerine “Kullanıcı bir talebi birkaç adımda, çağrı merkezini aramadan oluşturabilsin” gibi bir ifade, tasarım ve test aşamasında somut bir ölçüt sunar.

Ardından kullanıcıyı tanımlıyoruz. Uygulamayı kim, nerede ve hangi koşullarda kullanacak? Sahada, zayıf internet bağlantısıyla çalışan bir teknisyen ile ofiste masa başında çalışan bir yönetici aynı arayüzden aynı verimi almaz. Bu aşamada gerçek kullanıcılarla kısa görüşmeler yapmak, varsayımların erkenden sınanmasını sağlar.

Kullanıcıların hangi cihazları kullandığını bilmek de önemlidir. Kurum içi bir uygulamada cihazlar kurum tarafından sağlanıyorsa platform seçimi sadeleşir. Geniş kitleye açık bir uygulamada ise genellikle hem iOS hem Android hedeflenir.

Kapsamı Belirlemek ve İlk Sürümü (MVP) Planlamak

Fikir aşamasında istek listesi hızla uzar: bildirimler, mesajlaşma, harita, ödeme, raporlama, çoklu dil desteği. Hepsini ilk sürüme sığdırmaya çalışmak hem süreyi uzatır hem de hangi özelliğin gerçekten değer ürettiğini görmeyi zorlaştırır.

Bu yüzden ilk sürümü, yani MVP’yi (minimum uygulanabilir ürün) tanımlıyoruz. MVP, uygulamanın temel amacını yerine getiren en küçük ama kullanılabilir özellik setidir. Özellikleri “olmazsa olmaz”, “önemli” ve “sonra eklenebilir” şeklinde gruplamak pratik bir yöntemdir.

Kapsam belgesinde her özellik için kısa bir kullanıcı hikâyesi, ilgili ekranlar ve kabul kriterleri yer almalıdır. Bu belge farklı tekliflerin karşılaştırılabilir olmasını sağlar. Geliştirme sırasında “bu özellik kapsamda mıydı?” tartışmalarını da büyük ölçüde azaltır.

Native mi, Cross-platform mu?

Kurumların en sık sorduğu sorulardan biri budur. İki yaklaşımın da güçlü yanları vardır ve doğru seçim projenin ihtiyaçlarına bağlıdır.

Native Geliştirme Ne Zaman Öne Çıkar?

Native geliştirmede iOS için Swift, Android için Kotlin gibi platformun kendi dilleri ve araçları kullanılır. Kamera, Bluetooth, sensörler ya da arka planda sürekli çalışan işlemler gibi cihaz özelliklerine yoğun erişim gerektiren uygulamalarda bu yaklaşım daha esnek bir zemin sunar. Yoğun animasyon içeren arayüzlerde ve platformun yeni özelliklerini hızla kullanmak istediğiniz durumlarda da avantajlıdır. Karşılığında iki ayrı kod tabanı ve çoğu zaman iki ayrı uzmanlık gerekir.

Cross-platform Ne Zaman Mantıklıdır?

Flutter veya React Native gibi cross-platform (çapraz platform) çatılarda tek bir kod tabanından hem iOS hem Android uygulaması üretilir. Form, liste, bildirim ve içerik gösterimi gibi iş akışı ağırlıklı senaryolarda bu yaklaşım bakımı ve iki platform arasındaki özellik eşitliğini kolaylaştırır. Platforma özgü bazı ihtiyaçlar gerektiğinde native modüllerle karşılanabilir.

Bu kararı, mobil uygulama geliştirme projelerimizin başında kurumla birlikte veriyor; ihtiyaca göre native ya da cross-platform teknolojiler kullanıyoruz. Belirleyici olan; uygulamanın cihaz özelliklerine ne kadar bağımlı olduğu, kodun uzun vadede nasıl sahiplenileceği ve iki platformda aynı anda ne kadar hızlı ilerlemek istediğinizdir.

UX/UI Tasarımı ve Prototip

Tasarım yalnızca ekranların güzel görünmesi değil, kullanıcının bir işi en az zahmetle tamamlayabilmesidir. Bu aşamada önce kullanıcı akışlarını çıkarıyor, ardından düşük detaylı tel çerçeve (wireframe) ekranlarla uygulamanın iskeletini kuruyoruz.

Görsel tasarımda iOS ve Android’in kendi arayüz alışkanlıklarını dikkate almak gerekir. Geri gitme davranışı, menü yerleşimi ve sistem bileşenleri iki platformda farklıdır. Kullanıcılar alıştıkları davranışı bulamadığında uygulamayı zor kullanır ve kısa sürede bırakabilir.

Erişilebilirlik de baştan düşünülmelidir. Yeterli renk kontrastı, okunabilir yazı boyutları, rahat dokunma alanları ve ekran okuyucu desteği, sonradan eklemeye çalışmaktan çok daha kolay ve düşük maliyetlidir.

Tasarım onaylanmadan önce tıklanabilir bir prototip hazırlamak, yanlış anlaşılmaları kod yazılmadan yakalamanın pratik bir yoludur. Prototip üzerinde gerçek kullanıcılarla kısa görev testleri yapmak, kafa karıştıran adımları geliştirme başlamadan ortaya çıkarır.

Backend, API ve Yönetim Paneli

Mobil uygulamanın kullanıcıya görünen kısmı işin yalnızca bir bölümüdür. Verinin saklandığı sunucu tarafı (backend), uygulamanın bu sunucuyla konuştuğu API’ler ve içeriği yöneten panel çoğu projede en az mobil taraf kadar emek ister.

Bu katmanda bazı soruların erkenden netleşmesi gerekir. Kullanıcılar nasıl giriş yapacak, kurumun mevcut kimlik doğrulama altyapısı kullanılacak mı? Veriler hangi sistemlerden gelecek ve hangi sistemlere yazılacak? Bildirimler hangi olaylarla tetiklenecek? Uygulama çevrimdışıyken ne olacak?

Mevcut ERP, CRM ya da insan kaynakları sistemleriyle entegrasyon gerekiyorsa bunu kapsam aşamasında belirlemek önemlidir. Kuruma özel bir arka uç gerektiğinde mobil uygulamayı özel yazılım geliştirme yaklaşımımızla aynı mimari içinde ele alıyoruz. Müşteri ve personel süreçleri söz konusu olduğunda uygulamanın CRM ve HRM sistemleri ile birlikte çalışması da sık karşılaşılan bir ihtiyaçtır.

Yönetim paneli genellikle web tabanlıdır. İçerik ekleme, kullanıcı yönetimi, bildirim gönderme ve raporlama gibi işlerin teknik bilgi gerektirmeden yapılmasını sağlar. Paneli kapsam dışında bırakmak, yayından sonra her küçük değişiklik için geliştirici beklemek anlamına gelir.

Geliştirme Döngüleri

Geliştirmeyi kısa ve tekrarlanan döngüler hâlinde yürütüyoruz. Her döngünün sonunda çalışan, test edilebilir bir sürüm ortaya çıkar ve kurum tarafındaki paydaşlar bu sürümü kendi cihazlarında deneyebilir.

Bu yaklaşımın en önemli faydası geri bildirimin erken gelmesidir. Bir ekranın beklentiyi karşılamadığı projenin sonunda değil, ilk denemede fark edilir. Önceliklendirme de esnek kalır; sahadan gelen bilgiye göre bir özelliği öne çekmek ya da sonraki sürüme bırakmak mümkündür.

Test sürümlerini dağıtmak için iOS’ta TestFlight, Android’de ise Google Play’in dahili ve kapalı test kanalları kullanılabilir. Böylece test kullanıcıları uygulamayı mağaza yayınından önce gerçek cihazlarına kurar. Kod incelemesi, otomatik testler ve derleme ile dağıtımı otomatikleştiren CI/CD süreçleri, uygulama büyüdükçe kalitenin korunmasına yardımcı olur.

Test: Cihaz Çeşitliliği, Performans ve Güvenlik

Mobil uygulamada test, web projelerine göre daha geniş bir yelpazeyi kapsar. Uygulama farklı ekran boyutlarında, farklı işletim sistemi sürümlerinde ve değişen ağ koşullarında tutarlı çalışmalıdır.

Cihaz ve Sürüm Çeşitliliği

Android tarafında üretici ve model çeşitliliği fazladır. iOS’ta cihaz yelpazesi daha dar olsa da eski ve yeni işletim sistemi sürümleri bir arada kullanılır. Hangi sürümlerin destekleneceğine proje başında karar vermek test kapsamını netleştirir. Gerçek cihazlardaki testleri emülatör ve simülatör testleriyle birlikte kullanıyoruz.

Performans

Açılış hızı, ekran geçişlerinin akıcılığı, pil ve veri tüketimi kullanıcı deneyimini doğrudan etkiler. Zayıf bağlantıda uygulamanın nasıl davrandığını, yarım kalan işlemlerin nasıl kurtarıldığını ve uzun listelerin nasıl yüklendiğini özellikle test ediyoruz.

Güvenlik

Mobil uygulama, kurum verisine dışarıdan erişilen bir kapıdır. Hassas verinin cihazda şifreli saklanması, API iletişiminin güvenli kanal üzerinden yapılması, oturum yönetimi ve yetkilerin sunucu tarafında doğrulanması temel gerekliliklerdir. Kişisel veri işleyen uygulamalarda KVKK kapsamındaki yükümlülükler de tasarım aşamasından itibaren dikkate alınmalıdır.

App Store ve Google Play Yayın Süreci

Uygulama hazır olduğunda iş bitmiş sayılmaz; mağazaya çıkış kendi başına planlanması gereken bir aşamadır.

Öncelikle geliştirici hesaplarının kurum adına açılmasını öneriyoruz. Apple ve Google, kurumsal hesaplarda şirket bilgilerinin doğrulanmasını ister ve bu adım beklenenden uzun sürebilir. Hesapların kuruma ait olması, uygulamanın sahipliğini de güvence altına alır.

İnceleme Süreci

App Store’a gönderilen her sürüm Apple’ın inceleme sürecinden geçer; Google Play’de de uygulamalar yayına alınmadan önce incelenir. Yönergelere aykırı içerik, eksik gizlilik politikası, çalışmayan giriş bilgileri ya da yarım kalmış özellikler ret sebebi olabilir. Giriş gerektiren uygulamalarda inceleme ekibine bir test hesabı sağlamak gerekir.

Mağaza Görselleri ve Açıklamalar

Ekran görüntüleri, uygulama simgesi, kısa ve uzun açıklama, anahtar kelimeler ve kategori seçimi, uygulamanın mağazada nasıl bulunacağını ve indirilip indirilmeyeceğini etkiler. İki mağaza da uygulamanın hangi verileri topladığını ve nasıl kullandığını beyan etmenizi ister. Bu beyanın uygulamanın gerçek davranışıyla tutarlı olması gerekir.

Sürüm Notları ve Kademeli Yayın

Her güncellemede neyin değiştiğini sade bir dille anlatan sürüm notları, kullanıcıyla güven ilişkisi kurar. Google Play’de güncellemeyi kullanıcıların bir kısmına kademeli olarak açmak mümkündür; App Store’da da aşamalı yayın seçeneği bulunur. Bu yöntem, beklenmedik bir sorunun tüm kullanıcılara yayılmadan fark edilmesini sağlar.

Yayın Sonrası: Analitik, Bakım ve İşletim Sistemi Güncellemeleri

Mobil uygulama, yayınlandığı gün tamamlanmış bir ürün değil, yaşayan bir hizmettir.

Analitik araçlarıyla kullanıcıların hangi ekranlarda vakit geçirdiğini, hangi adımda süreci yarıda bıraktığını ve hangi özellikleri hiç kullanmadığını görmek, sonraki sürümlerin önceliklerini veriye dayalı belirlemeyi sağlar. Çökme raporlama araçları ise hataları kullanıcılar şikâyet etmeden önce görmemize yardımcı olur. Analitik kurgusunun da kişisel veri ilkelerine uygun olması gerekir.

Apple ve Google işletim sistemlerini düzenli olarak günceller. Yeni sürümler bazen eski davranışları değiştirir, yeni izin kuralları getirir ya da mağaza gereksinimlerini günceller. Bu nedenle uygulamanın, kullanılan kütüphanelerin ve sunucu tarafının düzenli bakımı planlanmalıdır. Bakımı ihmal edilen bir uygulama zamanla yeni cihazlarda sorun çıkarabilir ya da mağaza gereksinimlerini karşılayamaz hâle gelebilir.

Bakım ve destek kapsamını, hangi durumda kimin müdahale edeceğini proje başında konuşmak yayın sonrasındaki belirsizlikleri ortadan kaldırır.

Süreyi ve Maliyeti Etkileyen Faktörler

Kurumların ilk sorusu genellikle “ne kadar sürer, ne kadar tutar?” olur. Kapsam netleşmeden kesin bir cevap vermek doğru olmaz; ancak süreyi ve maliyeti belirleyen başlıca faktörler bellidir:

• Ekran ve özellik sayısı: Her yeni akış tasarım, geliştirme ve test yükü getirir.
• Platform tercihi: Tek platform, iki platform için ayrı native geliştirme ya da cross-platform yaklaşım farklı efor gerektirir.
• Backend ve yönetim paneli: Hazır bir altyapıya bağlanmak ile sunucu tarafını sıfırdan kurmak arasında ciddi fark vardır.
• Entegrasyonlar: Mevcut sistemler, ödeme altyapıları veya kamu servisleriyle yapılan entegrasyonlar; karşı tarafın dokümantasyonuna ve test ortamına göre süreyi etkiler.
• Tasarımın özgünlüğü: Platform bileşenlerine yakın bir tasarım ile özel animasyonlar içeren bir arayüz aynı emeği gerektirmez.
• Güvenlik ve uyum gereksinimleri: Kişisel veri, ödeme ya da kurumsal veri içeren uygulamalarda ek kontroller gerekir.
• Çevrimdışı çalışma ve çoklu dil: Çevrimdışı veri senkronizasyonu ve birden fazla dil desteği kapsamı genişletir.
• Yayın sonrası destek: Bakım, izleme ve yeni özellik ihtiyacı uzun vadeli bütçeyi belirler.

Kamu kurumları için geliştirilen uygulamalarda kurumun bilgi güvenliği politikaları, barındırma tercihleri ve mevcut sistemlerle uyum da planlamaya dahil edilir. Bu alandaki genel yaklaşımımızı kamu yazılım çözümleri sayfamızda bulabilirsiniz. Her durumda, bu faktörleri netleştiren bir kapsam çalışması gerçekçi bir plan ve teklif için sağlıklı bir başlangıçtır.

Projeye Başlamadan Önce Kısa Kontrol Listesi

• Uygulamanın amacı ve başarı ölçütü yazılı olarak tanımlandı mı?
• Hedef kullanıcılar ve kullanım koşulları belli mi?
• İlk sürümde (MVP) yer alacak özellikler önceliklendirildi mi?
• Hedef platformlar ve desteklenecek işletim sistemi sürümleri belirlendi mi?
• Native ya da cross-platform kararı gerekçeleriyle verildi mi?
• Backend, API ve yönetim paneli ihtiyacı kapsamda yer alıyor mu?
• Entegre olunacak mevcut sistemler listelendi mi?
• Kişisel veri ve güvenlik gereksinimleri belirlendi mi?
• App Store ve Google Play geliştirici hesapları kurum adına açıldı mı?
• Gizlilik politikası ve mağaza metinlerinden sorumlu kişi belli mi?
• Yayın sonrası bakım ve destek modeli konuşuldu mu?

Sonuç

Kullanılan ve yaşayan bir mobil uygulama; net bir hedef, gerçekçi bir ilk sürüm, doğru teknoloji kararı ve yayından sonra da devam eden bir bakım anlayışıyla ortaya çıkar. Sürecin her adımında kurum ile geliştirme ekibi arasındaki açık iletişim, yazılan kod kadar belirleyicidir.

SEKTEK olarak kamu kurumları ve özel sektör için iOS ve Android uygulamalarını tasarımdan backend’e, mağaza yayınından bakıma kadar bütün aşamalarıyla ele alıyoruz. Diğer hizmetlerimize çözümler sayfamızdan göz atabilirsiniz. Projenizi konuşmak için teklif formunu doldurabilir ya da İstanbul Beykoz’daki ofisimizle iletişime geçebilirsiniz.

• mobil uygulama
• uygulama geliştirme
• iOS
• Android