Mobil uygulama geliştirme 2026'da gerçekte ne kadar sürüyor?

Mobil uygulama geliştirme süreleri, sektörümüzde en tutarlı biçimde yanlış aktarılan sayılardan biridir. Üç ayda çıkabilecek projeler için hem "8 haftada App Store'da" vaatlerine hem de "12 aylık" tahminlere denk geldik. iOS, Android ve cross-platform yığınlarda 30'un üzerinde canlı uygulama lansmanı yönettikten sonra, bir brief'i kapsamlandırırken gerçekte kullandığımız döküm şöyle.

Gerçek dört maliyet merkezi

Çoğu uygulamanın süresine kod satırları değil, dört aşama hâkimdir:

1. Keşif ve mimari — bir brief'i inşa edilebilir bir spesifikasyona dönüştürmek.
2. Tasarım — UX akışları, tasarım sistemi, hareket (motion), uç durumlar.
3. Mühendislik — özellik geliştirme, entegrasyonlar, QA.
4. Mağazaya hazırlık — App Store Connect, Play Console, ASO, inceleme süreci.

Bunlardan herhangi birini atlamak ya da sıkıştırmak, "gecikmiş" projelerin çoğunun asıl kaynağıdır. Mühendislik aşaması nadiren kendiliğinden kayar — keşif yeterince derin olmadığı ya da tasarım sistemi hazır olmadığı için kayar.

Gerçekçi süre aralıkları

Minimum uygulanabilir ürünler (MVP, 4–8 hafta)

Dar kapsam, karmaşık bir kimlik doğrulama yok, önce tek platform, analytics ve çökme raporlaması dışında üçüncü taraf entegrasyonu yok. Örnekler: elle küratörlüğü yapılmış bir akışa sahip içerik uygulaması, tek amaçlı bir yardımcı uygulama, pazarlamaya eşlik eden bir uygulama.

Vazgeçtikleriniz: sınırlı animasyon inceliği, yönetim paneli yok, elle girilen mağaza meta verileri, push bildirimi segmentasyonu yok. Kullanılabilir bir v1 çıkarabilirsiniz — ancak bir sonraki çeyrekte muhtemelen yarısını yeniden yazacaksınız.

Üretime hazır uygulamalar (8–16 hafta)

Kimlik doğrulama (e-posta, Apple, Google), bir ya da iki entegrasyon (ödemeler, analytics, push), gerçek bir tasarım sistemi ve ilk günden itibaren CI/CD pipeline'ları. Çıkardığımız B2C uygulamalarının çoğu bu aralıkta yaşar.

Bu seviyede tipik kapsam:

• Eksiksiz kayıt + onboarding akışı
• Hareket ve geçişlerle 5–10 ana ekran
• WebSocket ya da polling ile gerçek zamanlı veri senkronizasyonu
• Uygulama içi satın alımlar ya da abonelikler (StoreKit, Google Play Billing, RevenueCat)
• Analytics + çökme raporlaması + remote config

Platform seviyesinde uygulamalar (16–28 hafta)

Uygulamanın kendisi bir refakatçi değil, ürünün ta kendisi olduğunda. Çok kiracılı (multi-tenant) veri, offline-first mimari, karmaşık izinler, native modüller, büyük içerik kütüphaneleri.

Çıkardığımız örnekler: gerçek zamanlı rota güncellemeleri olan bir B2B lojistik sevkiyat uygulaması, kişiselleştirilmiş içerik motorlarına sahip bir healthtech wellness platformu, sağlayıcılar ile tüketicilerin farklı uygulama varyantları kullandığı bir pazar yeri (marketplace).

Native mı, cross-platform mı?

Bu karar, hangi yöne gittiğinize bağlı olarak mühendislik süresine %20–40 ekler ya da ondan çıkarır.

Native (Swift + Kotlin) şu durumlarda doğru tercihtir:

• Sürükleyici bir UX çıkarıyorsanız (AR, özel kamera, karmaşık animasyonlar)
• Platforma özgü özellikler önemliyse (Live Activities, Widget'lar, Wear OS)
• Uygulama bir refakatçi değil, ürünün kendisiyse

Cross-platform (Flutter, React Native) şu durumlarda doğru tercihtir:

• iOS ve Android'de eş zamanlı olarak lansman yapmanız gerekiyorsa
• Ekibiniz tek bir yığını iki tanesinden daha iyi destekleyebiliyorsa
• UX'in %95'i platformlar arasında aynıysa

2026'da çoğu B2C uygulaması için Flutter ve React Native, performans farkının son kullanıcılar tarafından fark edilemeyeceği kadar olgunlaştı. Ayrıntılı karşılaştırma cross-platform geliştirme sayfasında, platforma özel konular iOS sayfasında.

Gecikmelere gerçekte ne yol açar

30'un üzerinde lansmandan sonra kayma örüntüsü tutarlı. Sıklık sırasına göre:

1. Tasarım donduktan sonra kapsam kayması — 6. haftada gelen "şunu da ekleyebilir miyiz..." klasiktir.
2. Üçüncü taraf API kararsızlığı — ödeme, kimlik ve kargo sağlayıcılarında sandbox != production.
3. App Store inceleme sürprizleri — gizlilik politikası boşlukları, IAP kuralları, App Tracking Transparency.
4. Backend hazır değil — mobil, API'nin akış aşağısındadır. API sürümlenmemiş ve kararlı değilse, mobil kalıcı bir regresyon makinesine dönüşür.
5. İlk kullanılabilirlik testinden sonra tasarım revizyonu — test etmenin doğru zamanı 10. hafta değil, 2. haftadır.

Bu sürelere karşılık gelen bütçe aralıkları

2026'da üretim seviyesinde uygulamalar çıkaran senior ekipler için:

• MVP, 4–8 hafta → €25K–€60K
• Üretime hazır, 8–16 hafta → €60K–€150K
• Platform seviyesi, 16–28 hafta → €150K–€400K

Bu rakamlar baştan sona senior mühendisleri ve tasarımcıları varsayar. Junior ekipler saat başına daha ucuza gelir, ancak genellikle 1,5–2 kat daha uzun sürer ve daha fazla teknik borç üretir — toplam sahip olma maliyeti nadiren daha düşük olur. Bantları neyin belirlediği mobil uygulama yaptırma maliyeti yazısında ayrıntılı; mobil uygulama maliyet hesaplama aracı ise kendi konfigürasyonunuzu bir aralığa ve süreye çeviriyor.

Süre gerçekte nereye gidiyor

Verilen herhangi bir takvimi sınamanın pratik yolu dağılıma bakmaktır. Üretime hazır bir uygulamada tipik olarak şunu görüyoruz:

• Keşif ve mimari — %10-15. Buradan kısmak, aşağıdaki "geciken" projeleri üreten şeyin ta kendisi; kısa vadede hızlı görünür, altıncı haftada geri döner.
• Tasarım — %20-25. Büyük bölümü kimsenin demo etmediği durumlara gider: yükleniyor, boş, hata, çevrimdışı.
• Geliştirme — %40-50. Herkesin tahmin ettiği ve pratikte en az sapan kısım; gecikmeler buradan değil, komşu üç kalemden çıkar.
• Test ve mağaza hazırlığı — %15-25. Sona eklenmez, sürece yayılır; sona bırakıldığında hatalar düzeltmenin en pahalı olduğu anda bulunur.

Bir tedarikçi planının %80'ini geliştirmeye koyuyorsa diğer üçünü planlamamış, ertelemiştir. Şüphe duyduğunuzda bu dağılımı sorun — cevabı, toplam süreden çok daha fazlasını söyler: takvimin gerçekten hesaplanmış olup olmadığını gösterir. Dağılımı veremeyen bir tedarikçi, tarihi hesaplamamış tahmin etmiştir. Sürecin aşama aşama işleyişi mobil uygulama geliştirme süreci yazısında.

runIT'te nasıl kapsamlandırıyoruz

Herhangi bir süre taahhüdünde bulunmadan önce bir haftalık bir keşif sprint'i yürütürüz:

• 1.–2. gün: paydaş çalıştayları, mevcut bir uygulamanız varsa teknik denetim
• 3.–4. gün: bilgi mimarisi, kullanıcı akışları, teknik risk kaydı
• 5. gün: kapsamı belirlenmiş backlog, sprint planı, sabit fiyatlı teklif

Çıktı; epic'ler, kabul kriterleri ve taahhüt edeceğimiz tarihlerle bir Linear panosudur. Production'a inen her şey, sizin onayladığınız bir kaleme kadar izlenebilir. Süreci nasıl kurduğumuz mobil uygulama geliştirme sayfasında.

Bir mobil projeye başlıyorsanız ve size verilen süre tahminine dair bir gerçeklik kontrolü istiyorsanız, bize anlatın — size 48 saat içinde ücretsiz bir ikinci görüş brief'i gönderelim.