Mobil Uygulama Geliştirme: 2026 Kapsamlı Rehberi

Mobil uygulama geliştirme rehberlerinin çoğu bir şey satmak için yazılır. Bu rehber karar vermenize yardım etmek için yazıldı.

Uygulama yaptırmayı düşünüyorsanız muhtemelen dört soruyu aynı anda tartıyorsunuz: hangi platform, ne kadar bütçe, ne kadar süre ve kim yapsın. Bu sorular birbirini etkiler. Cross-platform seçmek bütçeyi değiştirir. Bütçeyi kısmak kapsamı değiştirir. Kapsamı kısmak yayın tarihini değiştirir.

Rehber, bu kararları gerçekte karşılaşacağınız sırayla ele alıyor. Yayımlanmış veri olan yerde veriyi, olmayan yerde bunu açıkça söylüyoruz.

Özet

• Platform seçimi teknik değil ticari bir karardır — kullanıcılarınızın nerede olduğuna ve uygulamanın cihazdan ne isteyeceğine bakılır.
• Mağaza onayı formalite değil, gerçek bir eşiktir. Apple'ın App Review ekibi 2025'te 9,1 milyondan fazla başvuru değerlendirdi ve 2 milyondan fazlasını reddetti.
• Geliştirme maliyeti toplam maliyet değildir. Bakım, mağaza komisyonu ve altyapı ilk bütçe konuşmasında masada olmalı, yayından sonra değil.
• Sabit fiyat sizi saatlik faturalamadan daha çok korur — zor kapsam sorularını kod yazılmadan önce sordurur.

Mobil uygulama geliştirme neleri kapsar?

Uygulama geliştirmek tek isim altında toplanmış dört ayrı iştir: ürün tanımı, tasarım, mühendislik ve yayın operasyonu.

Ürün tanımı uygulamanın ne yapacağına, daha önemlisi neyi yapmayacağına karar verir. Tasarım bunun tek elle tutulan küçük bir ekranda nasıl hissettireceğine karar verir. Mühendislik, kuralları farklı iki işletim sistemi için inşa eder. Yayın operasyonu ise uygulamayı onaydan geçirir, kullanıcıya ulaştırır ve iOS 27 çıkıp sessizce bir şeyi bozduğunda ayakta tutar.

Zorlanan ekipler genelde birinci ve dördüncü aşamayı eksik planlar. Ortadaki ikisi görünürdür, bütçelemesi kolaydır. Kapsam ve yayın işi ise ters gidene kadar görünmez.

Native mi cross-platform mı?

Uygulamanın değeri cihaza bağlıysa native seçin. Değeri içeriğiniz, verileriniz veya iş akışınızsa cross-platform seçin.

Dürüst kısa cevap bu. Native geliştirme, her platform için ayrı uygulama yazmaktır — iOS için Swift, Android için Kotlin. İki ayrı kod tabanı, donanımın sunduğu her şeye tam erişim ve en yüksek performans tavanı demektir. Cross-platform geliştirme ise tek kod tabanının, genelde React Native ya da Flutter ile, iki platformda birden çalışmasıdır.

Karar genelde internetin gösterdiğinden daha nettir. Gerçek zamanlı kamera işleme, arka planda konum, karmaşık hareketler veya platforma özel donanım üzerine kurulu bir uygulama native'e aittir. Rezervasyon uygulaması, kurum içi araç, pazaryeri, sadakat uygulaması veya içerik ürünü genelde ait değildir.

Cross-platform'un gerçek maliyeti: derin işletim sistemi entegrasyonları geç gelir. Çünkü framework, platform yeni bir API yayımladıktan sonra onu sarmalamak zorundadır. Yol haritanız yeni iOS veya Android özelliklerini çıktığı hafta kullanmaya bağlıysa bu gecikme gerçek bir kısıttır.

Native'in gerçek maliyeti: iki kod tabanı, her şeyden iki tane demek — iki derleme, iki test döngüsü, iki hata seti, iki yayın süreci. Bu maliyet ilk geliştirmeyle bitmez, kalıcıdır.

Evrensel doğru bir cevap yok. Uygulamanın ne yapacağını sormadan size cevap veren biri, kendi tercih ettiği teknolojiyi satıyordur. Bu kararı mobil uygulama geliştirme sayfamızda detaylı anlatıyoruz.

Takvimin geliştiriciye değil Apple ve Google'a bağlı kısmını (D-U-N-S, hesap doğrulaması, zorunlu test süresi, inceleme) kaynaklarıyla mobil uygulama ne kadar sürede yapılır yazısında topladık.

Mobil uygulama fiyatları 2026: maliyeti ne belirler?

Kapsamı bilinmeden hiçbir uygulamaya fiyat verilemez. İnternette kapsamsız gördüğünüz her rakam pazarlamadır. Yapabileceğimiz şey, kulağa aynı gelen iki uygulamanın tekliflerinin neden on kat farklı çıktığını açıklamak.

Fiyatı gerçekten değiştiren değişkenler:

• Kullanıcı rolü sayısı. Tek tip kullanıcısı olan uygulama; müşteri, personel ve yönetici barındıran bir uygulamadan kat kat basittir.
• Backend gerekip gerekmediği. Sadece içerik gösteren uygulama, kullanıcı verisini saklayan, senkronize eden ve güvenliğini sağlayan uygulamanın yanında çok küçük bir iştir.
• Çevrimdışı çalışma. "İnternetsiz de çalışsın" brifte tek satırdır, mühendislikte haftalardır.
• Ödemeler. Uygulama içi satın alma, abonelik ve iade yönetiminin her birinin kendi kuralları ve istisnaları vardır.
• Entegrasyonlar. Uygulamanızın konuştuğu her dış sistem, kontrol etmediğiniz bir bağımlılıktır.
• Tek platform mu, iki mi. Önce sadece iOS ile çıkmak, ilk maliyeti yarıya indirmenin meşru bir yoludur.

Bütçeye yazılmayı unutulan kalemler

Geliştirme teklifi toplam maliyet değildir. Üç tekrarlayan kalem ilk bütçe konuşmasına girmeli.

Mağaza komisyonu. Apple'ın App Store Small Business Program'ı, ücretli uygulama ve uygulama içi satın alımlarda standart oran yerine %15 komisyon alıyor (Apple Developer). Program, bir önceki takvim yılındaki geliri 1 milyon dolara kadar olan geliştiricileri kapsıyor. Uygulamanız dijital bir şey satıyorsa bu oran modelinizde kalıcı bir satırdır.

Geliştirici hesapları. Apple Developer Program yıllık 99 dolar (Apple Developer). Google Play ise "25 ABD doları tek seferlik kayıt ücreti" alıyor (Google Play Console Yardım). Küçük rakamlar, ama sürpriz olmamalı.

Altyapı. Uygulamanın backend'i varsa, kullanıcı sayınızla birlikte büyüyen bir barındırma faturası da vardır. Bu bir başarı maliyetidir ama yine de maliyettir.

Tam dökümü — ürününüz değişmese bile platformların dayattığı tekrar eden maliyet dâhil — bir uygulamanın gerçekte ne tuttuğu yazısında.

Uygulama geliştirme ne kadar sürer?

Kapsamı tanımlanmış bir ilk sürüm için gerçekçi aralık 8 ila 16 hafta. Bu aralığın genişliği tesadüf değil.

Bu, kapsamladığımız projeler için kendi yayımladığımız rakam ve tek bir varsayıma dayanıyor: geliştirme başlamadan önce kapsamın sabitlenmiş olması. Üzerinde anlaşılmış bir özellik listesi olmadan başlayan projeler 16 hafta sürmez. Tartışmalar ne kadar sürerse o kadar sürer.

Tipik bir ilk sürümde bu süre kabaca şöyle dağılır:

Takvimi en çok sarsan iki aşama birinci ve sonuncusudur — yani daha hızlı başlamak isteyenlerin ilk kestiği iki aşama.

İlk sürümde ne olmalı?

Tek bir kullanıcının tek bir işi yapabildiğini kanıtlamak için gerekmeyen her şeyi çıkarın.

MVP, gerçek bir kullanıcının temel işi baştan sona tamamlamasını sağlayan en küçük sürümdür. Demo değildir, ucuz versiyon da değildir — dar ama eksiksiz çalışan bir üründür.

Kulağa bariz geliyor ama uygulaması çok zor, çünkü her paydaşın vazgeçilmez saydığı bir özellik vardır. İşe yarayan bir test: her özellik için "üç ay sonra gelse ne olur?" diye sorun. Cevap "pek bir şey olmaz" ise, o bir ikinci sürüm özelliğidir.

İlk sürümde vazgeçilmez gibi duran ama genelde olmayan özellikler:

• Tek sağlayıcının ötesinde sosyal giriş seçenekleri
• Uygulama içi sohbet veya mesajlaşma
• Push bildirim kampanya araçları (altyapı evet, kampanya paneli hayır)
• Başlangıç hacminde bir tablonun göreceği işi yapan yönetim panelleri
• Aynı anda iki pazara açılmıyorsanız çok dilli destek

Amaç daha az iş yapmak değil. Amaç daha erken yayına çıkmak, gerçek kullanıcılardan öğrenmek ve ikinci sürüm bütçesini toplantı odasında tahmin ettiğinize değil, kullanıcının gerçekten istediğine harcamak.

Uygulamalar mağazadan neden reddediliyor?

Mağaza onayı gerçek bir eşiktir ve ölçeğini küçümsemek kolaydır.

Apple'ın App Review ekibi 2025'te 9,1 milyondan fazla başvuru değerlendirdi ve bunların 2 milyondan fazlasını sorunlu bularak reddetti (Apple Newsroom, Mayıs 2026). Bu toplamın 1,2 milyondan fazlası yeni uygulama, yaklaşık 800 bini güncellemeydi. Kabaca her beş başvurudan biri geçemedi.

Bunların hepsi hata yapmış meşru uygulamalar değil; Apple'ın rakamları dolandırıcılık ve spam'i de kapsıyor. Ama sayı asıl noktayı gösteriyor: başvurmak yayımlamak değildir.

Google'ın süreci farklı işliyor. Google, bazı uygulamaların uzatılmış incelemeye tabi olduğunu ve bunun "istisnai durumlarda yedi güne veya daha uzun süreye çıkabileceğini" belirtiyor (Google Play Console Yardım). Yeni geliştirici hesaplarının uzun yola girme ihtimali daha yüksek.

Planlama açısından anlamı şu: aynı hafta onay geleceğini varsayan bir lansman tarihi asla duyurmayın. Pay bırakın, erken başvurun ve ilk başvuruyu bitiş çizgisi değil bir kontrol noktası sayın.

Gerçekten önlenebilir redler hep aynı yerlerde toplanıyor — eksik hesap veya abonelik bilgisi, eksik gizlilik açıklamaları, inceleyenin cihazında çöken özellikler, çalışmayan demo hesapları ve tek izin penceresini ilk açılışta harcamak. Bunların hepsi, başvuruyu bir inceleyicinin bakacağı gibi test ederek yakalanır.

Mağazaların gerçekte andığı kurallar bunları doğrudan alıntılıyor ve iki mağaza arasındaki en büyük farkı anlatıyor: Google Play'de tekrarlanan red hesabı kaybetmeye doğru tırmanıyor.

Yayından sonra maliyet ne oluyor?

Uygulama biten bir proje değil, yaşadığı sürece bakım bütçesi isteyen bir üründür — ve iki metriğinin yayımlanmış bir eşiği var; Play'deki görünürlüğünü etkileyen bir eşik.

İki platform da her yıl büyük bir işletim sistemi sürümü çıkarır ve her biri uygulamanızın dayandığı bir davranışı değiştirebilir. Sertifikalar dolar. Bağımlılıklar kullanımdan kalkar. Cihazların şekli değişir. Bunların hiçbiri opsiyonel iş değildir — bakılmayan uygulama yerinde saymaz, geriler.

Dört kalem planlayın:

1. İşletim sistemi uyumu. Yıllık, öngörülebilir, pazarlıksız.
2. Bağımlılık ve güvenlik güncellemeleri. Sürekli, ve bir şey bozulana kadar en çok atlanan kalem.
3. Gerçek kullanımdan çıkan hata düzeltmeleri. Yayından sonraki ilk üç ayda en yoğun.
4. İyileştirme. Uygulama ellerine geçtikten sonra kullanıcıların istediği özellikler.

Yayın sonrası ilk yıl için hiç bütçe ayırmamak, gördüğümüz en yaygın planlama hatası ve iyi bir uygulamayı terk edilmiş bir uygulamaya çeviren şey tam olarak bu.

Uygulamayı kim geliştirsin, nasıl seçilir?

Portföyü değil süreci değerlendirin. Portföyler bitmiş ekranları gösterir; dokuzuncu haftada kapsam değiştiğinde ekibin nasıl davrandığı hakkında hiçbir şey söylemez.

İmza atmadan önce sorulmaya değer sorular:

• Kodu tam olarak kim yazacak? Ekip büyüklüğü değil, isim ve kıdem sorun. Bazı ajanslar senior ekip satar, işi junior'lara yaptırır.
• Teklif sabit mi saatlik mi? Sabit fiyat, kapsam konuşmasını ait olduğu yere, en başa çeker. Saatlik faturalama riski size aktarır.
• Kapsam değişince ne oluyor? Cevabı olmayan ekip bunu hiç düşünmemiştir.
• Kod ve hesaplar kimin? Depolar, App Store ve Google Play hesapları, alan adları sizin olmalı. Bunu yazılı alın.
• Yayın sonrası destek nasıl işliyor? Kimse tarif edemiyorsa, kimse planlamamıştır.

Biz kısa bir keşif görüşmesinin ardından sabit fiyat veriyoruz — tam da zor kapsam sorularını sözleşmeden sonraya değil öncesine taşımak için. Böyle çalışmak istiyorsanız, ne yaptırmak istediğinizi anlatın.

Sık sorulan sorular

Önce iOS'ta mı Android'de mi yayınlamalıyım?

Kullanıcılarınızın olduğu yerde yayınlayın. Android'in pazar payında baskın olduğu pazarlarda cevap tersine dönebilir. Elinizde web analitiği varsa, karar vermeden önce mevcut ziyaretçilerinizin cihaz dağılımına bakın — ulaşabileceğiniz en ucuz araştırma budur.

Uygulama her zaman mobil siteden iyi midir?

Hayır. Ürününüz içerik, gezinme veya tek seferlik bir işlemse, hızlı bir mobil site genelde daha iyi hizmet eder ve daha az tutar. Uygulamalar tekrar eden kullanım, çevrimdışı çalışma, bildirim ve cihaz özellikleriyle kendini amorti eder. Bunlardan hangisine ihtiyacınız olduğunu söyleyemiyorsanız web ile başlayın.

Backend olmadan uygulama yapılabilir mi?

Evet — uygulama kullanıcı verisi saklamıyor, cihazlar arası senkronize etmiyor ve hesap gerektirmiyorsa. Backend, uygulamanın sunucu tarafıdır: veriyi tutar, hesapları yönetir ve cihazları senkronize eder. Tamamen cihaz üzerinde çalışan, buna hiç ihtiyaç duymayan çok sayıda işe yarar uygulama var. Backend'i sonradan eklemek mümkün ama nadiren ucuz olur; bu yüzden onuncu haftada fark etmek yerine en başta karar vermeye değer.

Uygulama bakımı yıllık ne kadar tutar?

Karmaşıklığa ve entegrasyon sayısına göre değişir; bu yüzden tek bir yüzde olarak gördüğünüz her rakam, veri kılığına girmiş bir tahmindir. Güvenilir olan şey şekli: bakım tekrarlayan yıllık bir maliyettir, yayından sonraki ilk aylarda en yüksektir ve hiçbir zaman sıfıra inmez.

Uygulama projeleri en çok neden bütçeyi aşar?

Hiç sabitlenmemiş kapsam yüzünden. Gördüğümüz neredeyse her bütçe aşımının kökeninde, ne yapılacağı üzerinde anlaşılmadan geliştirmeye başlanmış bir proje var.

Buradan sonrası

Mobil uygulama geliştirme, erken alınan kararları ödüllendirir ve ertelenen kararları cezalandırır. Platform seçimi, kapsam ve mülkiyet koşulları — üçünü de ilk satır kod yazılmadan önce netleştirmek, sonradan netleştirmekten çok daha ucuzdur.

Bu rehberden tek bir şey alacaksanız şu olsun: önce kapsamı sabitleyin, sonra fiyatı. Takvim, kalite ve işi yapan ekiple ilişkiniz dahil geri kalan her şey bunun üzerine kurulur.

Uygulama projelerini nasıl kapsamlayıp fiyatlandırdığımızı mobil uygulama geliştirme sayfamızda okuyabilir, diğer mühendislik ve büyüme hizmetlerimize göz atabilirsiniz.