Mobil Uygulama Geliştirme Süreci: Fikirden Yayına Adım Adım

Mobil uygulama geliştirme, dışarıdan bakınca "birkaç ekran çizilip kodlanır, mağazaya yüklenir" gibi görünür. İçeriden bakınca her biri ayrı karar gerektiren bir dizi adım var. Bu yazıda uygulama geliştirme sürecinin fikirden yayına kadar nasıl işlediğini, sürenin nelere bağlı olduğunu ve maliyeti hangi kalemlerin belirlediğini anlatacağız. Rakam vermeyeceğiz, çünkü her proje farklı; ama hangi kararın faturayı büyüttüğünü net göreceksiniz.

Mobil uygulama nasıl yapılır? Sürecin genel akışı

Mobil uygulama nasıl yapılır sorusunun cevabı, sektör ne olursa olsun benzer bir sırayı izliyor: kapsam, tasarım, geliştirme, test, yayın ve yayın sonrası bakım. Sıra önemli. Tasarım bitmeden kodlamaya başlamak ya da test aşamasını kısa kesmek, sonradan katlanarak geri dönüyor.

1. Kapsam: uygulama ne yapacak, ne yapmayacak

Her şey burada belirleniyor. Uygulamanın çözdüğü sorun tek cümleyle anlatılabiliyor mu? İlk sürümde hangi özellikler olacak, hangileri sonraya kalacak?

Buradaki en yaygın hata, ilk sürüme her şeyi sığdırmaya çalışmak. Kullanıcı girişi, profil, bildirim, mesajlaşma, ödeme, harita, sosyal paylaşım. Her özellik hem geliştirme süresini hem de test yükünü artırıyor. İlk sürümü (MVP) küçük tutup gerçek kullanıcı geri bildirimiyle büyütmek hem daha ucuz hem daha az riskli.

Bu aşamanın çıktısı yazılı bir kapsam belgesi olmalı: ekran listesi, kullanıcı akışları, entegre olunacak sistemler (ödeme altyapısı ya da mevcut CRM gibi), hedeflenen platformlar.

2. iOS ve Android: hangi platformda çıkmalı

iOS ve Android uygulama kararı hem maliyeti hem de süreyi doğrudan etkiliyor. Üç yol var:

• Yalnızca iOS ya da yalnızca Android için native (platforma özel) geliştirme. Performans ve platform özelliklerine erişim en yüksek seviyede; iki platform istiyorsanız iki ayrı kod tabanı demek.
• İki platform için tek kod tabanı (React Native, Flutter gibi çapraz platform araçlar). Bugün çoğu iş uygulaması için makul seçim: tek kod tabanı, iki mağaza.
• Önce tek platform, sonra diğeri. Kullanıcı kitleniz belirgin biçimde tek tarafta yoğunlaşıyorsa mantıklı.

Hangi yolun doğru olduğu uygulamanın ne yaptığına bağlı. Yoğun grafik ya da donanıma yakın işler native tarafa çekiyor. Form, liste, içerik ve işlem ağırlıklı uygulamalar çapraz platformla gayet iyi çalışıyor.

3. Tasarım: taslaktan arayüze

Tasarım iki aşamada ilerliyor. Önce düşük detaylı taslaklar (wireframe): hangi ekranda ne var, kullanıcı nereden nereye gidiyor. Bu aşamada renk ve görsel yok; amaç akışı doğrulamak. Değişiklik burada ucuz, kodda pahalı.

Sonra görsel tasarım: gerçek arayüz, tipografi, renkler, bileşenler, farklı ekran boyutlarına uyum. iOS ve Android'in kendi tasarım kuralları var ve kullanıcı, alıştığı platformun davranışını bekler. Bir Android kullanıcısına iOS tarzı geri tuşu davranışı vermek küçük ama sürekli bir rahatsızlık yaratır.

Tasarımı tıklanabilir bir prototipe dönüştürmek bu aşamada işe yarıyor. Kod yazılmadan önce uygulamanın nasıl hissettirdiğini elinizde deneyebiliyorsunuz.

4. Geliştirme

Burada iş iki tarafa bölünüyor: telefonda çalışan uygulama (ön yüz) ve arka planda veriyi tutan ve kullanıcıları doğrulayan sunucu tarafı (backend). Çoğu uygulamada sunucu tarafı, görünen kısımdan daha fazla iş demek. Kullanıcı hesapları, veri tabanı, ödeme entegrasyonu, yönetim paneli, üçüncü taraf servislerle bağlantılar.

İyi işleyen bir süreçte geliştirme kısa döngülerle ilerliyor: birkaç haftada bir çalışan bir sürüm çıkıyor ve siz onu deneyip geri bildirim veriyorsunuz. Aylarca haber alamayıp sonunda bitmiş bir uygulama görmek, düzeltmesi en pahalı senaryo.

5. Test

Test aşaması birkaç farklı soruya cevap arıyor:

• Farklı cihazlarda ve işletim sistemi sürümlerinde aynı davranıyor mu? Android tarafında cihaz çeşitliliği ciddi bir test yükü.
• Zayıf internet ya da kesilen bağlantıda ne oluyor? Uygulama arka plana atılıp geri geldiğinde kaldığı yerden devam ediyor mu?
• Performans: açılış süresi, pil tüketimi, bellek ve veri kullanımı.
• Güvenlik: kullanıcı verisi nasıl saklanıyor, sunucuyla iletişim şifreli mi?

Yayın öncesi kapalı test (TestFlight ve Google Play'in test kanalları), gerçek kullanıcılardan ilk geri bildirimi almanın en ucuz yolu.

6. Mağazaya yayın

App Store ve Google Play'in geliştirici hesabı ve inceleme süreci birbirinden ayrı. Apple'ın incelemesi daha sıkı; ret sebepleri genellikle eksik gizlilik politikası, çalışmayan giriş akışı, inceleme ekibine test hesabı verilmemesi ya da açıklamayla örtüşmeyen içerik. Bunları önceden bilmek, yayını haftalarca geciktiren ret döngüsünü önlüyor.

Mağaza sayfası da bu aşamanın parçası: ekran görüntüleri, açıklama metni, anahtar kelimeler, simge. Uygulamanın mağazada bulunabilmesi için yapılan bu hazırlık yayın günü tamam olmalı.

7. Yayın sonrası bakım

Uygulama yayına çıktıktan sonra işletim sistemi güncellemeleri, mağaza kural değişiklikleri, hata raporları ve kullanıcı geri bildirimi düzenli iş üretiyor. Her yıl yeni iOS ve Android sürümü çıkıyor; bakımı yapılmayan uygulama bir noktada yeni cihazlarda bozuluyor ya da mağaza kurallarına uymadığı için kaldırılıyor. Bütçe planlarken yayın sonrası bakımı ayrı bir kalem olarak baştan koyun.

Mobil uygulama geliştirme ne kadar sürer?

Süre, kapsamla doğru orantılı. Tek platformda çalışan, sunucu tarafı basit birkaç ekranlık bir uygulama ile ödeme, mesajlaşma, bildirim ve yönetim paneli olan iki platformlu bir uygulama arasında aylar fark var. Süreyi en çok uzatan şeyler genellikle şunlar:

• Kapsamın proje ortasında büyümesi
• Geri bildirim ve onayların gecikmesi
• Üçüncü taraf entegrasyonların (ödeme ya da kimlik doğrulama gibi) beklenenden zor çıkması
• Tasarım ve geliştirme ekiplerinin ayrı olması ve aradaki devir teslimlerin uzaması

Mobil uygulama maliyetini belirleyen kalemler

Fiyat sormadan önce şu kalemlerin her birinin cevabını bilmek işinizi kolaylaştırır. Teklifler arasındaki fark çoğunlukla bunlardan kaynaklanıyor.

• Platform sayısı ve yaklaşımı (native ya da çapraz platform)
• Ekran ve özellik sayısı
• Sunucu tarafının karmaşıklığı: kullanıcı yönetimi, veri tabanı, gerçek zamanlı özellikler, dosya depolama
• Entegrasyonlar: ödeme, harita, bildirim, mevcut sistemleriniz
• Tasarımın özgünlüğü: hazır bileşenler mi, sıfırdan arayüz mü
• Yönetim paneli ihtiyacı
• Test kapsamı ve cihaz çeşitliliği
• Yayın sonrası bakım ve sunucu giderleri (bunlar aylık devam eden kalemler)

Bir teklifin belirgin biçimde düşük olması, genellikle bu kalemlerden birinin eksik hesaplandığı anlamına geliyor. Teklif isterken kapsam belgesini paylaşın; aynı belgeye verilen teklifler karşılaştırılabilir olur.

Proje başlamadan önce sorulacak sorular

Bir ekiple çalışmaya başlamadan önce şunları netleştirin:

• Kodun ve mağaza hesaplarının sahibi kim olacak? (Cevap siz olmalısınız.)
• Tasarımı yapanla kodu yazan aynı ekip mi, yoksa iş aradaki teslimlerle mi ilerleyecek?
• Ne sıklıkla çalışan bir sürüm göreceksiniz?
• Yayın sonrası bakım teklife dahil mi?
• Sunucu ve üçüncü taraf servis ücretleri kimin üzerinden ödenecek?

Kısa özet

Mobil uygulama geliştirme süreci kapsamla başlıyor ve yayın sonrası bakımla devam ediyor. Süreyi ve maliyeti belirleyen şey büyük ölçüde ilk aşamada verilen kararlar: platform seçimi, özellik sayısı, entegrasyonlar ve sunucu tarafının kapsamı. Bu kararları baştan netleştiren projeler hem daha hızlı bitiyor hem de bütçeyi şaşırtmıyor.

OZGN STUDIO'da mobil uygulamaları tek ekip geliştiriyor; ilk taslağı çizen kişiler kodu da yazıyor ve onayladığınız şey yayına çıkıyor. Bir uygulama fikrini kapsam ve süre açısından konuşmak isterseniz hello@ozgnstudio.com adresine yazmanız yeterli.