Native mi cross-platform mu sorusunun kısa cevabı şudur: Native uygulama her platformun kendi diliyle (iOS için Swift, Android için Kotlin) ayrı geliştirilir; cross-platform uygulama Flutter veya React Native ile tek kod tabanından iki platforma çıkar. Donanımı yoğun kullanan, çevrimdışı çalışan uygulamalarda native; form ağırlıklı, hızlı çıkması gerekenlerde cross-platform öne çıkar.
Doğru cevabı teknoloji modası değil, uygulamanın sahada ne yapacağı belirler. Aşağıda iki yaklaşımı performans, donanım erişimi, çevrimdışı çalışma, maliyet ve bakım açısından karşılaştırıyoruz.
Karar neden bu kadar önemli?
Bir mobil uygulama projesinde teknoloji seçimi genellikle ilk toplantıda, çoğu zaman da tek bir soruyla yapılır: "Hangisi daha ucuz?" Oysa bu karar, uygulamanın yalnızca ilk sürümünü değil, sonraki beş yılını belirler. Barkod okuyucunun hızı, kamera ile çekilen fotoğrafın kalitesi, internet olmayan bir şantiyede kaydın kaybolup kaybolmaması, işletim sistemi güncellemesinden sonra uygulamanın çalışmaya devam edip etmemesi — hepsi bu ilk kararın sonucudur.
Yanlış seçim çoğu zaman hemen fark edilmez. İlk sürüm sorunsuz yayına çıkar; sorun, sahadaki kullanıcı sayısı arttığında, cihaz donanımına daha derin erişim gerektiğinde ya da işletim sistemi yeni bir izin kuralı getirdiğinde ortaya çıkar. O noktada teknoloji değiştirmek, uygulamayı baştan yazmak demektir.
Bu yüzden doğru soru "hangisi daha ucuz?" değil, "uygulamamız sahada ne yapacak, kim kullanacak ve kaç yıl yaşayacak?" sorusudur. Aşağıdaki bölümler bu soruyu somut ölçütlere bölüyor; sonunda kendi uygulamanız için hangi yaklaşımın ağır bastığını gerekçesiyle görebileceksiniz.
Mobil neden artık "ek kanal" değil?
Kullanıcıların zamanının büyük kısmı artık mobil uygulamalarda geçiyor:
Sensor Tower State of Mobile 2026 verisine göre kullanıcılar 2025'te iOS ve Google Play uygulamalarında toplam 5,3 trilyon saat, kişi başı günde yaklaşık 3,6 saat geçirdi.
Türkiye'de de tablo benzer. TÜİK Hanehalkı Bilişim Teknolojileri Kullanım Araştırması, 2026 verisine göre 16-74 yaş bireylerde internet kullanımı %92,3'e, internetten mal veya hizmet satın alma oranı %60,0'a ulaştı. Müşteriniz, bayiniz ve saha çalışanınız işini giderek daha fazla telefondan yapmak istiyor; uygulamanın yavaş ya da kararsız olması doğrudan iş kaybına dönüşüyor.
Bir de ekip boyutu var. Mobil uygulama ilk sürümden sonra da bakım ister: her yıl yeni işletim sistemi sürümleri, yeni cihazlar ve mağaza kuralları gelir. TÜİK Girişimlerde Bilişim Teknolojileri Kullanım Araştırması, 2026 verisine göre girişimlerin yalnızca %15,2'si BİT uzmanı istihdam ediyor ve BİT uzmanı arayanların %31,7'si işe alımda güçlük yaşıyor. Seçtiğiniz teknolojinin uzmanını yıllarca bulabilecek misiniz, sorusu da kararın parçasıdır.
Seçenekleri tanıyalım
- Native (Swift / Kotlin): Her platform için ayrı kod yazılır. Uygulama işletim sisteminin sunduğu tüm imkânlara doğrudan erişir; kamera, Bluetooth, NFC, konum, arka plan işlemleri ve biyometrik giriş en doğal hâliyle kullanılır. Karşılığında iki ayrı kod tabanı yönetilir.
- Cross-platform (Flutter, React Native vb.): Tek kod tabanı iki platformda çalışır. Arayüz ve iş kuralları bir kez yazılır; donanıma özgü bazı işler için yine platforma özel kod gerekebilir.
- Progresif web uygulaması (PWA) / mobil uyumlu web: Mağazaya çıkmadan tarayıcıda çalışır, ana ekrana eklenebilir. Donanım erişimi ve arka plan çalışması sınırlıdır; bazı iş uygulamaları için ise yeterlidir.
Native mi cross-platform mu? Karşılaştırma tablosu
| Ölçüt | Native | Cross-platform | PWA / mobil web |
|---|---|---|---|
| Performans ve akıcılık | En yüksek | Çoğu iş uygulaması için yeterli | Tarayıcıya bağlı |
| Donanım erişimi (kamera, NFC, Bluetooth, arka plan konum) | Tam ve doğrudan | Eklentilerle; bazen platforma özel kod gerekir | Sınırlı |
| Çevrimdışı çalışma ve senkronizasyon | Güçlü | Güçlü, doğru kurgulanırsa | Kısıtlı |
| İlk sürüm süresi | Daha uzun (iki kod tabanı) | Daha kısa | En kısa |
| İşletim sistemi yeniliklerine uyum | Anında | Çatının güncellenmesini bekleyebilir | Tarayıcıya bağlı |
| Uzun vadeli bakım | İki ekip/iki kod tabanı | Tek kod tabanı + çatı bağımlılığı | Tek kod tabanı |
| Mağaza varlığı | Var | Var | Yok (isteğe bağlı) |
Tablodaki hiçbir sütun "kazanan" değildir; her satırın ağırlığı sizin uygulamanıza göre değişir. Bu tablodan önce gelen bir karar daha vardır: kullandığınız ERP ya da CRM paketinin hazır mobil uygulaması işinizi görüyorsa ayrı bir uygulama geliştirmek gerekmeyebilir. Bu ayrımın ölçütlerini özel yazılım mı hazır paket mi rehberinde topladık.
Karar için 7 soru
- Uygulama cihaz donanımını ne kadar kullanacak? Barkod/QR okuma, NFC kart, Bluetooth yazıcı, sürekli konum takibi (örneğin filo yönetim sistemi sürücü uygulaması) gibi özellikler ağırlıktaysa native öne çıkar. Uygulamanın konuşacağı cihazı da siz geliştiriyorsanız IoT cihaz geliştirme süreci yazımıza göz atın.
- İnternet olmadan çalışması gerekiyor mu? Şantiye, depo, kırsal saha gibi ortamlarda kayıtların cihazda güvenle tutulup bağlantı gelince senkronize edilmesi kritik bir tasarım konusudur. Aynı ilke sahadaki cihazlar için de geçerlidir; geçiş sistemlerinin çevrimdışı çalışması yazısı bu tasarımın donanım tarafını anlatıyor.
- Kim kullanacak? Kendi çalışanlarınıza dağıtılan bir iç uygulama ile App Store'da binlerce müşteriye sunulan bir uygulamanın beklentileri farklıdır.
- Uygulama kaç yıl yaşayacak? Beş yıl ve üzeri kullanılacak kurumsal uygulamalarda bakım maliyeti, ilk geliştirme maliyetini geçebilir. Bu kalemlerin dökümünü mobil uygulama maliyeti yazısında yaptık.
- Arayüz ne kadar standart? Ekranların çoğu form, liste ve raporsa cross-platform verimlidir; özel animasyon ve yoğun grafik varsa native daha rahattır.
- Hangi sistemlerle konuşacak? ERP, CRM veya saha servis sistemiyle gerçek zamanlı veri alışverişi, teknolojiden çok arka uç ve API tasarımına bağlıdır.
- Bakımı kim yapacak? İçeride ekip kuracaksanız, o teknolojide uzman bulabileceğinizden emin olun; dışarıdan hizmet alacaksanız kaynak kodunun size ait olduğunu sözleşmede güvenceye alın.
Bu soruların cevabı netleşmeden teknoloji seçmek, proje maliyetini de belirsiz bırakır; kapsamın nasıl çıkarılacağını yazılım ihtiyaç analizi yazımızda, maliyetin nasıl oluştuğunu yazılım projesi maliyeti yazımızda anlattık.
Maliyeti yalnızca ilk sürümle hesaplamayın
Teklifleri karşılaştırırken çoğu şirket yalnızca ilk sürümün geliştirme bedeline bakar. Oysa bir kurumsal uygulamanın toplam maliyeti üç kalemden oluşur: ilk geliştirme, yıllık bakım (işletim sistemi güncellemeleri, yeni cihazlara uyum, mağaza kurallarındaki değişiklikler) ve yeni işlevler. Beş yıl kullanılacak bir uygulamada son iki kalem, ilk geliştirme bedelini rahatlıkla geçebilir.
Bu açıdan bakıldığında cross-platform'un ilk sürümdeki avantajı, çatı güncellemelerinin getirdiği bağımlılıkla kısmen dengelenir; native'in iki kod tabanı ise işletim sistemi yeniliklerine doğrudan uyum sağladığı için beklenmedik yeniden yazım riskini azaltır. Hangi tarafın ağır bastığını uygulamanın kapsamı belirler. Teklif alırken şu üç soruyu mutlaka sorun: Yıllık bakım neleri kapsıyor? Yeni bir işletim sistemi sürümü çıktığında uyum çalışmasını kim, hangi sürede yapıyor? Kaynak kodu ve mağaza hesapları kimde kalıyor? Teklif veren firmaları karşılaştırırken yazılım firması seçme kriterlerimiz de işinize yarar. Mobil uygulamanın bağlanacağı ERP, CRM ve entegrasyon katmanına dair rehberler Yazılım Geliştirme yazılarımızda bir arada.
Sık görülen senaryolar ve tipik tercih
- Saha teknisyeni uygulaması (iş emri, fotoğraf, imza, barkod, çevrimdışı çalışma): Donanım ve çevrimdışı ihtiyaç yüksek; native genellikle daha sağlam sonuç verir. Bu senaryonun tamamını saha servis yönetimi rehberimizde ele aldık. Formun hangi alanları içermesi gerektiğini mobil servis formu yazısında ayrıca anlattık.
- Bayi sipariş uygulaması (ürün listesi, özel fiyat, sipariş): Ekranlar standart; her iki yaklaşım da işi görür, belirleyici olan ERP entegrasyonudur. Kurgunun tamamını B2B bayi portalı yazımızda anlattık.
- Depo sayım uygulaması: Barkod okuma hızı ve el terminali uyumu önemlidir; donanım seçimiyle birlikte karar verilmelidir. Uygulamanın bağlanacağı sistemi depo yönetim sistemi (WMS) yazısında anlattık.
- Müşteriye açık kampanya/sadakat uygulaması: Hızlı pazara çıkış öncelikliyse cross-platform ya da PWA mantıklı olabilir.
- Yalnızca raporları görüntüleyen yönetici ekranı: Çoğu zaman mobil uyumlu bir web paneli yeterlidir; ayrı bir uygulamaya gerek olmayabilir.
Digital Bridge'de bu işi nasıl yapıyoruz?
- Önce ihtiyacı çıkarıyoruz. Mobil uygulama geliştirme hizmetimiz ihtiyaç analiziyle başlar: kullanıcılar, cihazlar, çevrimdışı senaryolar ve bağlanılacak sistemler netleşmeden teknoloji önermiyoruz.
- Native geliştiriyoruz. iOS için Swift, Android için Kotlin ile native uygulamalar geliştiriyoruz; çevrimdışı mod, anlık bildirim, kamera ile barkod/QR okuma, GPS, biyometrik giriş, dijital imza ve fotoğraf yükleme gibi saha ihtiyaçlarını bu yaklaşımla karşılıyoruz.
- Uygulama gerekmiyorsa söylüyoruz. İhtiyaç mobil uyumlu bir panelle karşılanabiliyorsa bunu özel web yazılımı olarak kurmayı öneriyoruz.
- Arka ucu birlikte tasarlıyoruz. Uygulamanın ERP, CRM ve diğer sistemlerinizle gerçek zamanlı çalışması için API entegrasyonu katmanını aynı projede kuruyoruz; bayi tarafında e-ticaret ve B2B platformunuzla bütünleştiriyoruz.
- Güvenliği baştan ele alıyoruz. Cihazda saklanan veri, oturum yönetimi ve yetkilendirme kurallarını siber güvenlik ilkeleriyle tasarlıyoruz.
Kapsamı, aşamaları ve bedeli yazılı teklifte netleştiriyoruz.
Sonraki adım
Uygulamanızın ilk sürümünde mutlaka olması gereken beş işlevi ve bu işlevlerin hangi ortamda (ofis, saha, depo, müşteri) kullanılacağını yazın. Bu kısa listeyle iletişim sayfamızdan bize ulaşın; hangi yaklaşımın sizin için doğru olduğunu gerekçeleriyle birlikte değerlendirelim.