Mobil Uygulama Fiyatları 2026: Maliyeti Ne Belirler?

Ekim 2026 itibarıyla giriş seviyesindeki bir mobil uygulamayı kabaca 250.000 ile 1.000.000 TL arasında fiyatlıyoruz. Kullandığımız pratik hesap şu: geliştirmenin her ayı yaklaşık 250.000 TL, proje uzadıkça toplam da büyüyor. Yani asıl soru uygulamanın kaç ay süreceği, bunu da ekran sayısından çok uygulamanın arkasında kurulması gereken sistemler belirliyor.

Fiyat nasıl hesaplanıyor?

Teklifler saatlik, günlük, sprint başına ya da götürü olarak gelebilir. Hepsinin altında aynı tahmin yatıyor: kaç kişi kaç ay çalışacak. Götürü fiyat da bu tahminin üstüne bir risk payı eklenmiş halidir.

Bu yüzden saat ücretlerini tek başına karşılaştırmak yanıltıcı. Saati ucuz ama işi iki katı sürede bitiren bir ekip daha pahalıya gelir ve bunu çoğu zaman projenin ortasında fark edersiniz.

250.000 TL'lik aylık hesabımız, TCMB'nin 16 Ekim 2026 tarihli gösterge kuruyla (1 USD = 49,36 TL, 1 EUR = 55,52 TL) yaklaşık 5.000 dolar ya da 4.500 euro ediyor. TL fiyatlar enflasyonla çabuk eskiyor; bu yazıdaki rakamlar Ekim 2026 itibarıyla geçerli. Teklif karşılaştırırken KDV'nin dahil olup olmadığına da mutlaka bakın.

Aylık hesabımızla giriş seviyesi aralığı bir ila dört aylık işe denk geliyor: az sayıda temel özelliğe odaklanan bir ilk sürüm. Süreyi neyin uzattığı büyük ölçüde önceden görülebiliyor; aşağıda tek tek anlattık.

Piyasadaki çok düşük teklifler

İlan sitelerinde ve freelance platformlarında bu aralığın çok altında rakamlar da göreceksiniz. Bunlar çoğunlukla hazır bir şablonun logosu ve renkleri değiştirilmiş hali oluyor ya da backend, yönetim paneli ve mağaza süreci teklifin dışında kalıyor. Şablonun her iş için kötü olduğunu düşünmüyoruz. E-ticaret altyapınız hazır bir mobil uygulama sunuyorsa ve ihtiyacınız bundan ibaretse, sıfırdan geliştirmeye para vermeyin.

Süreyi uzatan kalemler

Kapsam: ekranları değil, rolleri ve akışları sayın

Ekran sayısı kötü bir ölçü. Giriş ekranı da ödeme ekranı da birer ekran, ama reddedilen kartlar, iadeler ve faturayla birlikte ödeme ekranı tek başına bir haftalık iş olabilir. Daha doğru ölçü akış: kullanıcının bir sonuca ulaşmak için yaptığı her şey. Üye olmak, randevu almak, iade istemek birer akıştır.

Sonra rolleri sayın. Müşterilerin randevu aldığı, kuaförlerin ya da fizyoterapistlerin kendi takvimlerini yönettiği, platformu işleten firmanın da yeni hizmet verenleri onayladığı bir uygulama aslında aynı veritabanını paylaşan üç ayrı ürün. Bu üçüncü taraf genellikle web tabanlı bir yönetim panelidir ve teklif isterken en kolay unutulan kalem de odur.

Platform: tek kod tabanı mı, iki mi?

Native geliştirme (iOS için Swift, Android için Kotlin) iki ayrı kod tabanı ve iki kez arayüz işi demek. React Native ve Flutter gibi çapraz platform araçlarında ise kodun büyük kısmı iki platformda ortak. Randevu, katalog, saha formu, panel ya da pazaryeri gibi iş uygulamalarına biz çapraz platformla başlıyoruz; hangi durumda yettiğini ve nerede zorlandığını Flutter yazımızda anlattık. Uygulamanın işi büyük ölçüde donanımla ilgiliyse (yoğun Bluetooth kullanımı, AR, gelişmiş kamera işleme, arka planda uzun süre çalışan görevler) native'i tercih ederiz.

Türkiye'de platform kararı görece kolay. StatCounter verilerine göre Eylül 2026'da Türkiye'de mobil işletim sistemi payı Android'de %77, iOS'ta %23. Geniş kitleye hitap eden bir tüketici uygulamasında Android'i atlayamazsınız. Şirket içi uygulamalarda ise kararı şirketin çalışanlara verdiği telefonlar belirler. İki mağazaya aynı gün çıkmak da şart değil: önce kullanıcılarınızın olduğu mağazaya çıkın, uygulama orada kendini kanıtlayınca ikincisini ekleyin.

Backend: en büyük fark burada

Telefondaki uygulama işin görünen kısmı. Arkasında kullanıcı hesapları, veritabanı, API, dosya depolama, push bildirimleri, yönetim paneli ve e-posta gönderen ya da veri eşitleyen arka plan işleri durur. Çalışan bir web ürününüz olduğu için bunlar zaten hazırsa, mobil uygulama yeni bir ön yüzden ibarettir ve çok daha küçük bir projedir. Yoksa bunları kurmak uygulamanın kendisinden uzun sürebilir.

Supabase veya Firebase gibi hazır backend servisleri kullanıcı hesaplarını, veritabanını ve dosya depolamayı kullanıma hazır olarak sunar. İlk sürüm için çoğu zaman doğru tercih bunlardır; büyüdükçe parçaları kendi servislerinize taşıyabilirsiniz. Bir tavsiye daha: mobil uygulamanın backend'ini paylaşımlı hostinge kurmayın. Arka plan işleri, kuyruklar ve sunucu ayarları isteyen bir API için orada yeterli kontrolünüz olmaz.

Entegrasyonlar: her biri küçük bir proje

Ödeme, harita, SMS doğrulama, kargo firması, e-Fatura entegratörü, Logo veya Mikro gibi bir ERP: her entegrasyon başkasının API'si, test ortamı, erişim bilgileri, istisnai durumlar ve hata yönetimi demek. Teklifte her entegrasyonun ayrı bir satır olarak tahmin edilmesini isteyin; plansız haftalar genellikle orada saklanır.

Ödemede maliyeti doğrudan değiştiren bir kural var. Uygulama içinde dijital içerik ya da özellik satıyorsanız (abonelik, premium özellik, oyun içi para), Apple çoğu pazarda kendi uygulama içi satın alma sistemini zorunlu tutuyor ve komisyon alıyor. Fiziksel bir ürün ya da uygulama dışında tüketilen bir hizmet satıyorsanız (yemek siparişi, kuaför randevusu, kargo), App Store İnceleme Yönergeleri bu kez Apple'ın sistemini kullanmanıza izin vermiyor (3.1.1 ve 3.1.3(e) maddeleri). Bu durumda iyzico ya da PayTR gibi bir ödeme kuruluşuyla entegre olursunuz; mağaza komisyon almaz, siz ödeme kuruluşunun komisyonunu ödersiniz. Google Play'de de ayrım aynı.

Tasarım

Platformun standart bileşenlerini kendi renklerinizle kullanmak ucuzdur. Özel bileşenleri ve animasyonlarıyla kendi tasarım sisteminizi kurmak ise geliştirmeden önce tasarım işi, sonra da onu kodlamak için ek süre demek. İlk sürümde tasarım bütçesini temel akışı anlaşılır kılmaya harcamayı, özel görünümü sonraya bırakmayı öneririz.

Mağaza kuralları, hesaplar ve KVKK

Hiçbir özellik listesinde görünmeyen ama her uygulamanın ödediği bazı maliyetler var:

• Kullanıcı hesap açabiliyorsa, Apple hesabın uygulama içinden silinebilmesini de şart koşuyor (5.1.1(v) maddesi).
• Apple'ın asgari işlevsellik kuralı (4.2), yeniden paketlenmiş bir web sitesinden fazlasını bekliyor. Web sitenizi ince bir kabuğa koyup göndermek ret riski taşıyor.
• Geliştirici hesaplarını şirket adına açın. Apple da Google da kurumsal hesap için D-U-N-S numarası istiyor. Numara ücretsiz, ama Apple'ın uyarısına göre gelmesi beş iş gününü bulabiliyor; uygulama bitmeden epey önce başvurun. Google Play'de 13 Kasım 2023'ten sonra açılan kişisel hesaplar, yayına çıkmadan önce en az 12 test kullanıcısıyla 14 gün kesintisiz kapalı test yapmak zorunda. Kurumsal hesaplarda bu adım yok.
• Uygulama kişisel veri işliyorsa KVKK gereği aydınlatma metni, gereken yerlerde açık rıza ve silme taleplerini karşılayan bir akış gerekir. Veriler yurt dışındaki bir sunucuda duruyorsa (örneğin Supabase ya da Firebase projesini Avrupa'daki bir bölgede açtıysanız) KVKK'nın 9. maddesindeki yurt dışına aktarım kurallarına da uymanız gerekir. Yeterlilik kararı yoksa kanunun saydığı güvencelerden biri gerekir; küçük bir şirket için bu genellikle Kurul'un ilan ettiği standart sözleşmedir ve imzadan sonraki beş iş günü içinde Kuruma bildirilir. Sağlık ve finans uygulamalarında buna sektörün kendi kuralları eklenir.

İki projemiz: bir ay ve altı ay

Finlandiya'da kiralık ve satılık ilanları tek yerde toplayan bir platformun (adını paylaşmıyoruz) iOS uygulamasını Expo ve React Native ile yaklaşık bir ayda geliştirdik. Yapay zeka destekli kodlama araçlarıyla çalıştık ve uygulama Ekim 2026'da App Store incelemesini geçti. Arkasındaki platform zaten çalışıyordu: ilanları toplayan tarayıcılar, Supabase veritabanı, Next.js web sitesindeki arama ve haritalar. Uygulama, çalışan bir ürüne eklenen yeni bir ön yüzdü.

My3PL adlı depo rehberi içinse iki ila beş kişilik ekibimiz web sitesini, web uygulamasını ve Flutter ile mobil uygulamayı birlikte geliştirdi. 2022'de başlayan bu iş, yapay zeka kodlama araçlarını henüz kullanmadığımız dönemde yaklaşık altı ay sürdü. Ortada hazır hiçbir şey yoktu; backend, veri modeli ve web ürünü de işin parçasıydı.

Bu iki proje arasındaki farkın iki nedeni var ve hangisinin ne kadar pay sahibi olduğunu ayırt edemiyoruz: yapay zeka destekli geliştirme kodlamayı hızlandırdı, Finlandiya'daki uygulamanın altında da bitmiş bir backend vardı. Bizim çıkardığımız ders şu: API'si olan bir web ürününüz varsa, mobil uygulamanın arkasındaki platformdan çok daha küçük bir proje olmasını bekleyin. Sıfırdan başlıyorsanız backend'i başlı başına bir proje olarak bütçeleyin.

Yayından sonraki giderler

Geliştirme bir kerelik bir harcama. Aşağıdakiler ise devam eder:

• Apple Developer Program yıllık 99 USD, yani 16 Ekim 2026 kuruyla yaklaşık 4.900 TL. Google Play'e ise tek seferlik 25 USD (yaklaşık 1.230 TL) kayıt ücreti ödersiniz. İkisi de dolar bazlı olduğu için TL karşılığı kurla birlikte değişir.
• Uygulama içinde dijital bir şey satıyorsanız komisyon ödersiniz. Apple, Küçük İşletme Programı'na katılan ve yıllık geliri 1 milyon doları aşmayan geliştiricilerden %15, diğerlerinden %30 alıyor; AB gibi bazı pazarlarda koşullar farklı. Google ise ABD, Birleşik Krallık ve Avrupa Ekonomik Alanı'nda 30 Haziran 2026'da, Avustralya ve Japonya'da 30 Eylül'de yeni bir ücret yapısına geçti. Türkiye'nin de içinde olduğu diğer pazarlarda, yeni yapı oralara ulaşana kadar, yıllık ilk 1 milyon dolarlık kazançta %15, üstünde %30, otomatik yenilenen aboneliklerde %15 alıyor.
• Barındırma ve üçüncü taraf servisler: backend sunucusu, dosya depolama, harita, SMS, e-posta ve hata takibi. Küçük uygulamalar çoğu zaman ücretsiz ya da giriş paketlerine sığar, fatura kullanıcı sayısıyla birlikte büyür.
• Apple ve Google her yıl şartları yükseltiyor. Apple, 28 Nisan 2026'dan beri App Store Connect'e yüklenen uygulamaların Xcode 26 ve iOS 26 SDK'sı ile derlenmesini istiyor. Google Play'de 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler Android 16'yı (API 36) hedeflemek zorunda. Android 14 veya daha eskisini hedefleyen mevcut uygulamalar ise yeni Android sürümlerini kullanan yeni kullanıcılara görünmüyor.

En çok hafife alınan kalem bu sonuncusu. Bir yıl kimsenin dokunmadığı bir uygulamada tek satırlık bir düzeltmeyi yayınlamak için bile önce bu güncellemeleri yapmanız gerekir. Bu yüzden bakımı teklifte ayrı bir kalem olarak isteyin.

Karşılaştırılabilir teklif almak için

Kimseden fiyat istemeden önce tek sayfalık bir özet yazın:

1. Uygulamayı kimler kullanacak (roller) ve her rolün yapabilmesi gereken üç ila beş temel iş ne?
2. Elinizde ne var: web sitesi, API, veritabanı, CRM ya da ERP?
3. İlk gün hangi platformlar gerekli, hangisi bekleyebilir?
4. Tüm entegrasyonlar, isimleriyle.
5. Uygulamada bir şey satıyor musunuz? Satıyorsanız dijital mi, fiziksel mi?
6. Tabi olduğunuz veri kuralları: sağlık, finans, çocuk verisi, kişisel veri.

Sonra her firmaya aynı soruları sorun. Backend ve yönetim paneli fiyata dahil mi, yoksa hazır olduğu mu varsayılıyor? Tasarım, gerçek cihazlarda test ve mağazaya yükleme dahil mi? Mağaza hesapları ve kaynak kod kimin adına olacak? Yayından sonra bakım ne kadar tutacak ve yıllık SDK güncellemelerini kim yapacak? KDV dahil mi? Diğerlerinden çok düşük bir teklif, genellikle bu sorulardan birine farklı cevap veriyordur.

Fiyatı düşürmenin en güvenilir yolu ilk sürümü tek bir temel akışa indirmek; bu akışı nasıl seçeceğinizi MVP yazılım geliştirme yazımızda anlattık. Sözleşme tipi konusundaki görüşümüz şu: kapsamı yazılı, küçük bir ilk sürüm için götürü fiyat işe yarar. Daha büyük işlerde, her biri telefona kurabileceğiniz bir sürümle biten kısa ve ücretli aşamalarla çalışmayı tercih ediyoruz. Böylece iki taraf da iş tam anlaşılmadan yapılmış bir tahmine bağlı kalmıyor. Özetten mağaza sayfasına kadar aradaki adımları Ankara'da mobil uygulama geliştirme yazımızda bulabilirsiniz.

Sık sorulan sorular

Mobil uygulama kaç ayda yapılır?

Bizim fiyatlarımızla giriş seviyesi bir uygulama bir ila dört aylık iş. Finlandiya'daki platform için geliştirdiğimiz iOS uygulaması yaklaşık bir ay sürdü; backend hazırdı ve yapay zeka destekli kodlama araçlarıyla çalıştık. My3PL için sıfırdan web sitesi, web uygulaması ve mobil uygulama geliştirmek ise bu araçlardan önce yaklaşık altı ay sürmüştü.

Önce iOS mu, Android mi?

Çapraz platform geliştirin ve önce kullanıcılarınızın çoğunun elindeki platformda yayına çıkın. Türkiye'de geniş kitleli bir uygulama için bu genellikle Android demek; şirket içi bir uygulamada ise şirketin verdiği telefonlara bakın.

Web sitemi uygulamaya çevirmek daha ucuz olmaz mı?

Siteyi bir uygulama kabuğuna koymak mümkün, ama Apple yeniden paketlenmiş bir web sitesinden ibaret uygulamaları reddedebiliyor. Siteniz telefonda zaten iyi çalışıyorsa ve asıl isteğiniz ana ekranda bir simgeyse, progresif web uygulaması (PWA) yetebilir. Cihaz özelliklerine, çevrimdışı çalışmaya ya da mağazada yer almaya ihtiyacınız varsa gerçek bir uygulama yaptırın.

Apple ve Google her satıştan komisyon alır mı?

Hayır, yalnızca uygulama içinde satılan dijital ürün ve özelliklerden alırlar. Fiziksel ürünler ve gerçek dünyadaki hizmetler kendi ödeme kuruluşunuz üzerinden geçer. Ücretsiz ya da gelirini reklamdan elde eden bir uygulama yalnızca geliştirici hesabı ücretlerini öder.

Kendi uygulamanız için bir rakam görmek isterseniz, yukarıdaki tek sayfalık özeti mobil uygulama geliştirme sayfamızdan bize gönderin; Ankara'daki ekibimiz uygulamanın kaç ay süreceğine bakıp size dönüş yapsın.