Mobil Uygulama Maliyeti: iOS ve Android Uygulama Geliştirme Ücretini Ne Belirler?

Mobil uygulama maliyeti, bir fikri hayata geçirmek isteyen şirketlerin ilk sorduğu ve en belirsiz cevabı aldığı sorudur. Aynı fikir için bir ekip birkaç haftalık iş derken bir başkası aylar sürecek bir projeden söz edebilir. Bu farkın nedeni, mobil uygulama denince akla gelen şeyin telefon ekranındaki arayüz olması, oysa maliyetin büyük kısmının ekranın arkasında yatmasıdır: sunucu, veritabanı, kullanıcı yönetimi, bildirim altyapısı ve mağaza süreçleri.

Bu yazıda iOS ve Android uygulama geliştirme ücretini belirleyen etkenleri tek tek açıyoruz. Amaç bir rakam vermek değil; hangi kararın maliyeti nasıl etkilediğini göstermek. Böylece hem teklif alırken ne istediğinizi netleştirir hem de bütçenizi gerçekten fark yaratan kalemlere ayırırsınız. Planzio adlı takvim uygulamamızı web, iOS ve Android'de canlıda işlettiğimiz için bu kalemleri sahada yaşayarak öğrendik.

Mobil uygulama maliyeti neye göre hesaplanır?

Mobil uygulama maliyeti, temelde harcanacak nitelikli iş gücünün süresine göre hesaplanır. Bu süreyi belirleyen etkenler ise platform sayısı, özelliklerin kapsamı ve karmaşıklığı, arka uç altyapısının büyüklüğü, tasarımın özgünlüğü ve entegrasyon ihtiyaçlarıdır. Bunlara mağaza yayını, test ve yayın sonrası bakım gibi kalemler eklenir.

Kabaca bir çerçeve çizmek gerekirse, kullanıcı girişi olmayan ve bir veri kaynağını gösteren basit bir uygulama en alt kademede yer alır. Üyelik, bildirim, ödeme ve kullanıcılar arası etkileşim eklendikçe orta kademeye çıkılır. Gerçek zamanlı iletişim, harita, çevrimdışı çalışma ve kurumsal sistemlerle derin entegrasyon gibi katmanlar ise üst kademeyi oluşturur. Her kademe arasındaki fark, aylarla ölçülen iş gücü demektir.

Bu yüzden teklif almadan önce yapılacak en değerli iş, uygulamanın ne yapması gerektiğini bir ya da iki sayfada yazmaktır. Hangi ekranlar olacak, kullanıcı hangi işleri yapacak, hangi veriler nereden gelecek? Bu belge ne kadar net olursa, aldığınız teklifler o kadar karşılaştırılabilir olur ve proje boyunca kapsam kayması yaşanma ihtimali azalır.

iOS ve Android için ayrı ayrı mı geliştirilir?

Günümüzde çoğu proje için iOS ve Android ayrı ayrı geliştirilmez; React Native, Expo ya da Flutter gibi çapraz platform teknolojileriyle tek kod tabanından iki platforma birden çıkılır. Bu yaklaşım geliştirme maliyetini iki ayrı uygulama yazmaya göre ciddi biçimde düşürür ve iki platformdaki sürümlerin birbirinden kopmasını engeller.

Yerel, yani her platforma kendi diliyle yazılan uygulamalar hâlâ bazı durumlarda gereklidir: cihaz donanımını yoğun kullanan, çok yüksek performans isteyen ya da platforma özgü en yeni özelliklere ilk gün erişmesi gereken uygulamalar. Ancak bir işletmenin sipariş, randevu, takip ya da müşteri hizmeti uygulaması için bu gereklilik nadiren ortaya çıkar. Çapraz platform teknolojileri bugün mağazalardaki pek çok popüler uygulamanın arkasında çalışmaktadır.

Yalnızca tek platforma çıkmak da bir seçenektir ve ilk sürümde maliyeti düşürür. Kullanıcı kitleniz ağırlıklı olarak tek platformdaysa, örneğin saha ekibinize şirket telefonu dağıtıyorsanız, tek platformla başlayıp diğerini sonra eklemek mantıklıdır. Ancak müşteriye açık bir uygulamada iki platformdan birini atlamak, kullanıcıların bir kısmını baştan dışarıda bırakmak anlamına gelir.

Özellik listesi maliyeti nasıl belirler?

Özellik listesi, mobil uygulama maliyetini belirleyen en büyük kalemdir; çünkü her özellik hem arayüz hem arka uç hem de test emeği demektir. Kullanıcı girişi, anlık bildirim, ödeme, harita, kamera, çevrimdışı çalışma ve kullanıcılar arası mesajlaşma gibi özelliklerin her biri, projeye günler ya da haftalar ekler.

Bazı özellikler göründüğünden çok daha maliyetlidir. Sosyal hesaplarla giriş, tek bir buton gibi görünür; ama Apple ile Giriş, Google ile Giriş ve e-posta ile giriş akışlarının her biri ayrı ayrı kurulur, test edilir ve mağaza kurallarına uygun hale getirilir. Ödeme ve abonelik ise mağazaların kendi altyapılarına bağlı olduğu için ayrı bir uzmanlık alanıdır. Çevrimdışı çalışma, uygulamanın veriyi cihazda tutup sonra sunucuyla eşitlemesini gerektirir; bu da yazılımın en zor problemlerinden biridir.

Buradaki pratik öneri şudur: her özelliği olsa iyi olur ve olmazsa olmaz diye iki kümeye ayırın. İlk sürüme yalnızca olmazsa olmazlar girsin. Olsa iyi olur kümesi, uygulama gerçek kullanıcıyla buluştuktan sonra hangilerinin gerçekten istendiğine göre sıralanır. Pek çok uygulamada ilk listede yer alan özelliklerin bir kısmının hiç kullanılmadığı sonradan görülür.

Arka uç ve API neden maliyetin görünmeyen yarısıdır?

Arka uç, yani uygulamanın verilerini tutan sunucu, veritabanı ve API katmanı, mobil uygulama maliyetinin görünmeyen yarısıdır; çünkü kullanıcı hiç görmez ama her ekranın arkasında çalışır. Kullanıcı hesapları, veri saklama, yetkilendirme, bildirim gönderimi, ödeme kayıtları ve güvenlik denetimlerinin hepsi bu katmanda yaşar.

Bir randevu uygulamasını düşünün. Ekranda takvim ve birkaç buton görünür. Arkada ise kullanıcıların kimlik doğrulaması, randevuların çakışma kontrolü, hatırlatma bildirimlerinin zamanlanması, verilerin şifrelenmesi ve yedeklenmesi, birden fazla cihazdan girişte tutarlılığın korunması gibi onlarca iş vardır. Bu işlerin her biri arayüzden bağımsız olarak tasarlanır, yazılır ve test edilir.

Supabase gibi hazır arka uç platformları bu maliyeti düşürebilir; kimlik doğrulama, veritabanı ve dosya saklama gibi temel işler hazır gelir. Ancak iş kuralları, yetki mantığı ve güvenlik katmanı yine projeye özel yazılır. Şirketin mevcut bir ERP ya da CRM'i varsa uygulamanın bu sistemlerle konuşması da arka uç maliyetine eklenir; entegrasyonun büyüklüğü karşı sistemin ne kadar açık olduğuna bağlıdır.

Tasarım ve kullanıcı deneyimi ne kadar ekler?

Tasarım ve kullanıcı deneyimi, uygulamanın ekran sayısına ve özgünlük beklentisine göre maliyetin anlamlı bir bölümünü oluşturur. Hazır bileşen kütüphaneleriyle kurulan sade bir arayüz düşük maliyetlidir; markaya özel görsel dil, animasyonlar ve her ekranın ayrı ayrı kurgulanması ise tasarım süresini katlar.

Kullanıcı deneyimi tasarımı, görselden önce akışı düşünmektir. Kullanıcı uygulamayı ilk açtığında ne görecek, kayıt olmadan neyi deneyebilecek, bir işi kaç dokunuşla bitirecek? Bu sorulara verilen cevaplar, uygulamanın benimsenip benimsenmeyeceğini belirler. Güzel görünen ama kullanıcının üç ekran sonra kaybolduğu bir uygulama, mağazada düşük puanla cezalandırılır.

Buradaki denge şudur: kurum içi kullanılacak bir saha uygulamasında görsel özgünlük ikinci plandadır, akışın hızı ve hatasızlığı önemlidir. Müşteriye açık bir uygulamada ise ilk izlenim ve marka tutarlılığı doğrudan indirme ve kalıcılık oranına yansır. Bütçeyi hangi tarafa ağırlıklı ayıracağınız, uygulamayı kimin kullanacağına göre karar verilmelidir.

Mağaza yayını ve sonrası: yıllık mobil uygulama maliyeti nedir?

Yıllık mobil uygulama maliyeti, geliştirme bittikten sonra devam eden giderlerdir: Apple ve Google geliştirici hesapları, sunucu ve veritabanı barındırma, bildirim ve e-posta servisleri, işletim sistemi güncellemelerine uyum, mağaza politikası değişikliklerine göre yapılan zorunlu düzenlemeler ve hata düzeltmeleri. Uygulama yayına girdiği gün bitmez, o gün başlar.

İşletim sistemi tarafı bu kalemin en düzenli parçasıdır. Apple ve Google her yıl yeni sürüm çıkarır; bazı yıllarda eski uygulamaların güncellenmesini zorunlu kılan değişiklikler gelir. Mağaza politikaları da değişir: gizlilik beyanı, hesap silme zorunluluğu, abonelik gösterim kuralları gibi başlıklar geçtiğimiz yıllarda pek çok uygulamanın güncelleme yapmasını gerektirdi. Bu değişiklikleri takip etmeyen uygulama mağazadan kaldırılabilir.

Sunucu maliyeti ise kullanıcı sayısıyla büyür. Az kullanıcılı bir uygulama çok düşük altyapı gideriyle çalışır; kullanıcı arttıkça veritabanı, depolama ve bildirim hacmi büyür. Bu iyi bir sorundur, ama baştan planlanmalıdır. Teklif alırken geliştirme ücretinin yanında ilk yılın işletme giderlerini de sormak, bütçeyi sürprizlerden korur.

MVP ile başlamak maliyeti nasıl düşürür?

MVP, yani en küçük uygulanabilir ürün, uygulamanın yalnızca temel değerini sunan ilk sürümüdür ve mobil uygulama maliyetini düşürmenin en etkili yoludur. Olmazsa olmaz özelliklerle sınırlı bu sürüm daha kısa sürede tamamlanır, gerçek kullanıcıyla erken buluşur ve sonraki özelliklerin varsayımla değil geri bildirimle seçilmesini sağlar.

MVP yaklaşımının maliyet avantajı yalnızca ilk sürümün küçük olması değildir. Asıl kazanç, hiç kullanılmayacak özelliklerin hiç geliştirilmemesidir. Baştan altı aylık kapsamlı bir proje planlayıp sonunda kullanıcıların üç özelliği kullandığını görmek yerine, iki aylık bir çekirdekle başlayıp neyin istendiğini görerek büyümek hem bütçeyi hem zamanı korur.

MVP demek özensiz demek değildir. Az özellik, ama her biri düzgün çalışan, güvenli ve mağaza kurallarına uygun. Kullanıcı girişi, veri güvenliği ve temel akış ilk günden sağlam kurulmalıdır; çünkü bunlar sonradan düzeltilmesi en pahalı katmanlardır. Küçük başlayıp sağlam temel üzerinde büyümek, mobil projelerde en sık işe yarayan yoldur.

Doğru kapsam, doğru bütçe

Mobil uygulama maliyetini belirleyen şey teknoloji değil, kapsamdır. Ne yapılacağı net olan, olmazsa olmazlarla başlayan ve arka ucu baştan düzgün kurulan bir proje, hem bütçesini tutturur hem de yayın sonrasında sürpriz yaşamaz. Teklif alırken geliştirme ücretiyle birlikte kaynak kodun kime ait olacağını, ilk yıl işletme giderini ve mağaza süreçlerinin kimin sorumluluğunda olduğunu sormak, sağlıklı bir karşılaştırmanın temelidir.

Rezon, şirketlere özel CRM, ERP ve bayi portalı sistemleri kuran, kendi SaaS ürünlerini canlıda işleten İstanbul merkezli bir yazılım çözümleri şirketidir. Planzio uygulamamızı web, iOS ve Android'de kendimiz yayınladığımız için mağaza süreçlerini, abonelik altyapısını ve yayın sonrası bakımı sahadan biliyoruz; şirketlere geliştirdiğimiz uygulamalarda kaynak kod müşteriye aittir. Fikrinizi kapsam ve bütçe açısından birlikte netleştirmek için İletişim sayfamızdan ücretsiz keşif görüşmesi talep edebilir, yaklaşımımızı Çözümler sayfamızdaki Web ve Mobil bölümünde inceleyebilirsiniz.