Mobil uygulama native mi, cross-platform mı yazılmalı? Karar ölçütleri ve gerçek maliyetler

Çoğu şirket uygulaması için doğru cevap tek bir kod tabanıdır: React Native ya da Flutter ile iki platformu birden yazmak, ekibi ikiye bölmekten hem daha ucuz hem daha hızlıdır. Native geliştirme belirli tetikleyiciler varsa gerekir: donanıma derin erişim, arka planda sürekli çalışma, eski cihazlarda sıkı bir performans bütçesi ya da yeni işletim sistemi özelliklerini çıktığı gün kullanma zorunluluğu. Arada üçüncü bir yol daha var, Kotlin Multiplatform ile iş mantığını paylaşıp arayüzü her platformda yerel bırakmak. Ama hepsinden önce sıfırıncı soru geliyor: mağazada bir uygulamaya gerçekten ihtiyacınız var mı, yoksa web yeterli mi?

Sıfırıncı soru: uygulama gerçekten gerekli mi

Apple'ın inceleme kılavuzunun 4.2 maddesi bu konuda net. Uygulamanız "yeniden paketlenmiş bir web sitesinin ötesine geçen özellikler, içerik ve arayüz" içermeli; 4.2.2 alt maddesi de esas olarak pazarlama malzemesi, web kırpıntısı, içerik toplayıcı veya bağlantı listesi olan uygulamaları dışarıda bırakıyor. Sitenizi bir WebView'e sarıp mağazaya koymayı düşünüyorsanız planı burada bitirin.

Uygulamanın kendisi de bedava değil. İki mağaza hesabı, iki inceleme kuyruğu, iki sürüm kanalı, imzalama sertifikaları ve kullanıcının güncellemeyi ne zaman alacağı üzerinde sıfır kontrol demek. Web'de bir hatayı öğleden sonra düzeltip aynı gün yayına alırsınız. Mağazada aynı düzeltme incelemeden geçer ve kullanıcıların bir bölümü haftalarca eski sürümde kalır.

PWA ne zaman yeter? Android'de oldukça iyi: kurulum istemi, web push ve çevrimdışı önbellek çalışıyor. iOS'ta sınırlar hâlâ gerçek. Kurulum yalnızca Safari'nin Paylaş menüsündeki "Ana Ekrana Ekle" ile yapılıyor, otomatik kurulum istemi (beforeinstallprompt) desteklenmiyor, web push yalnızca ana ekrana eklenmiş uygulamalarda çalışıyor, sekmede açık duran sitede çalışmıyor, arka plan senkronizasyonu yok. Yani bir kullanıcının sizden bildirim alabilmesi için önce üç adımlı bir kurulumu kendi başına tamamlaması gerekiyor. Kurumsal iç araçlarda, saha ekibi uygulamalarında ve kullanıcıya "şu adımları izleyin" diyebildiğiniz B2B senaryolarda PWA gayet makul bir seçim. Tüketiciye açık bir üründe iOS erişiminizi ciddi biçimde daraltır.

Cross-platform artık marjinal bir bahis değil

Appfigures'ın verisine göre React Native veya Flutter ile yayımlanan uygulamalar, tüm yeni uygulama yayınlarının 2020'de yüzde 7'sini, 2021'de yüzde 12'sini, 2024'te yüzde 15'ini oluşturuyordu. Teknik taraf da bu arada yerine oturdu. React Native'in yeni mimarisi 0.76 sürümüyle (Ekim 2024) varsayılan hale geldi; JavaScript ile yerel taraf arasındaki köprü kalktı, senkron çağrılar ve Suspense gibi modern React özellikleri mümkün oldu. Flutter tarafında Impeller varsayılan render motoru; 2026 yol haritası Android 10 ve üzerinde eski Skia arka ucunun tamamen kaldırılmasını, web'de ise WebAssembly'nin varsayılana geçmesini hedefliyor.

Shopify'ın beş yılı: ölçülen sonuç ve ödenen bedel

Shopify 2020 Ocak'ında React Native kararını açıklarken somut sayılar verdi. Arrive uygulaması (bugünkü Shop) iOS ile Android arasında kodun yüzde 95'ini paylaşıyordu, dahili Compass uygulamasında oran yüzde 99'du ve üç ay içinde iki platforma birden çıkmıştı. Ekip başlangıçta yüzde 80 bekliyordu. Arrive ekibi kendini native geliştirmeye kıyasla iki kat üretken buldu, üstelik tek bir platformla karşılaştırıldığında bile. Yeniden yazılan uygulama iOS'ta eski native sürümden daha az çökme üretti.

Beş yıllık değerlendirmelerinde sayılar tutmuş görünüyor: yüzde 99,9'un üzerinde çökmesiz oturum ve Shopify uygulamasında P75 ekran açılışı yarım saniyenin altında. Aynı yazıda ödedikleri bedeli de tek tek sayıyorlar. React Native'de hata ayıklama kararsız çalışıyor, her yeni React Native sürümüne geçmek ciddi iş yükü çıkarıyor, üçüncü taraf kütüphanelere bağımlılık artıyor, ve donanım entegrasyonu, arka plan görevleri ve platform güncellemeleri için hâlâ native uzmana ihtiyaç duyuyorlar.

Kendi kararlarındaki istisna da öğretici. Perakende POS uygulamasını iOS'ta native bıraktılar. Gerekçe olarak koydukları eşikler doğrudan kullanılabilir: 1,5 GHz'in altındaki eski donanım, yoğun işlem, çok sayıda arka plan iş parçacığı ve uç seviyede performans gerektiren durumlarda React Native varsayılan tercihleri değil.

Airbnb neden vazgeçti, o hikâyeden ne öğrenilir

Airbnb 2018'de iki yıllık yatırımın ardından React Native'i kapattı. Gerekçeleri okumaya değer, çünkü büyük kısmı teknik değil. Acının çoğu hibrit modelden geliyordu: aynı uygulamada native ve React Native ekranların yan yana yaşaması, iki taraf arasında köprü kurmak, gezinme durumunu paylaşmak ve iki ayrı hata ayıklama dünyasında çalışmak. Buna rağmen anket sonucu şaşırtıcı: mühendislerin yüzde 63'ü fırsat verilse aynı seçimi tekrar yapardı, yüzde 74'ü yeni bir projede değerlendirirdi. Kararı belirleyen şey, native mühendis işe almanın zorlaşması gibi organizasyonel etkenlerdi.

Bu hikâye sekiz yaşında ve o günden bu yana hem React Native hem Airbnb değişti. Alınacak ders "React Native kötü" değil. Ders şu: karışık mimarinin maliyeti, iki mimariden herhangi birini tek başına seçmenin maliyetinden yüksektir. Karar verirken "ekranların yarısını şimdilik diğer tarafta bırakalım" seçeneğini en pahalı seçenek olarak fiyatlayın.

Teklifte görünmeyen kalem: sürüm yükseltme vergisi

Cross-platform tekliflerinde en sık atlanan kalem bu. React Native aynı anda yalnızca en son üç sürüm serisini destekliyor ve yeni bir seri ortalama iki ayda bir çıkıyor. Pratikte anlamı şu: bugün üzerine kurduğunuz sürüm yaklaşık altı ay sonra desteklenen listeden düşer. Ağustos 2026 itibarıyla güncel kararlı sürüm 0.87; destekli olanlar 0.87, 0.86 ve 0.85, 0.84 ve öncesi desteksiz.

Yükseltmeyi ertelemek işi kolaylaştırmıyor, çünkü her ertelemede daha büyük bir sıçrama ve ona bağlı kütüphanelerin toplu güncellemesi birikiyor. Yılda iki yükseltme penceresini takvime ve bütçeye baştan yazın. Bu kalemi içermeyen bir teklif ucuz görünür, farkı ikinci yıl kapatırsınız. Flutter'da mantık aynı, sadece kütüphane ekosistemi biraz daha az hareketli.

Üçüncü yol: iş mantığını paylaş, arayüzü yerel bırak

Kotlin Multiplatform tam olarak bunu yapıyor. Ağ katmanı, önbellek, iş kuralları, doğrulama ve durum yönetimi ortak Kotlin kodunda duruyor; arayüz iOS'ta SwiftUI, Android'de Compose ile ayrı yazılıyor. Google 2024 I/O'da bu modeli resmen desteklediğini duyurdu ve gerekçesini açıkça yazdı: paylaşılmaya en değer kısım, arayüzden bağımsız olan iş mantığıdır. Kendi ürünlerinde de uyguluyorlar, Google Docs iş mantığını Android, iOS ve web arasında paylaşıyor.

Arayüzü de paylaşmak isteyenler için Compose Multiplatform'un iOS desteği Mayıs 2025'te kararlı ilan edildi. JetBrains'in verdiği rakama göre native SwiftUI karşılığına kıyasla iOS uygulama boyutuna yaklaşık 9 MB ekliyor; VoiceOver ve tam klavye erişimi gibi erişilebilirlik özellikleri destekleniyor.

Bu yol kimin için mantıklı: çalışan iki native ekibiniz varsa, arayüzün her platformda tam yerel hissetmesi ürün açısından önemliyse ve tekrar tekrar yazılan asıl şey karmaşık iş mantığıysa. Paylaşım oranı doğal olarak daha düşük kalır. Ama paylaştığınız kısım, iki ekipte ayrı ayrı yazıldığında en çok tutarsızlık ve hata üreten kısımdır.

Native hâlâ ne zaman doğru cevap

Şu maddelerden birden fazlası sizdeyse native yazın: kamera, Bluetooth, NFC veya özel donanımla derin çalışma; arka planda sürekli konum takibi ya da senkronizasyon; giriş gecikmesinin ürünün kendisi olduğu deneyimler (harita, çizim, kamera, oyun); eski cihazlarda ciddi bir performans bütçesi; yeni iOS veya Android özelliklerini duyurulduğu gün kullanma ihtiyacı.

Bir de sessizce atlanan durum var: uygulama tek platformda yaşayacaksa ve diğerine hiç çıkmayacaksa cross-platform yazmanın getirisi sıfırdır. Sadece fazladan bir araç zinciri ve fazladan bir yükseltme takvimi eklersiniz.

Ekipte kim olduğu, çerçeveden daha belirleyici

Kararı çoğu zaman bu belirlemeli. Web tarafında güçlü bir React ekibiniz varsa React Native, kâğıt üzerinde daha iyi görünen bir alternatiften daha hızlı sonuç verir. Ekip Kotlin ve Swift biliyorsa, Flutter için Dart öğrenmek üç haftalık bir gecikme değil, aylara yayılan bir verim düşüşüdür.

Hangi çerçeveyi seçerseniz seçin, en az bir kişi Xcode'u açıp yerel bir yığın izini okuyabilmeli. Yerel tarafı kimsenin bilmediği bir cross-platform projesi ilk imzalama hatasında, ilk mağaza reddinde veya ilk yerel modül çakışmasında durur. Bu boşluk dışarıdan destekle kapatılabilir, ama planlanmamış olması pahalıdır.

Mobil güvenlik sunucu güvenliği gibi çalışmaz

Çerçeve seçiminden bağımsız iki nokta var. Birincisi: uygulama paketi kullanıcının cihazında duruyor ve incelenebiliyor. React Native'de JavaScript paketi, Flutter'da derlenmiş kod, native'de ikili dosya, hepsi tersine mühendisliğe açık. Koda gömdüğünüz API anahtarı sır değildir; koda gömülü sır yönetimi yazısındaki ayrım burada birebir geçerli, istemcide duran anahtar yayımlanmış anahtardır. Üçüncü taraf servislere erişim kendi arka ucunuz üzerinden geçmeli.

İkincisi bağımlılıklar. Cross-platform projeler tipik olarak daha uzun bir üçüncü taraf paket listesiyle gelir ve bu liste doğrudan kullanıcının cihazına iner. Yazılım tedarik zinciri güvenliği yazısındaki kontroller mobil tarafta da aynen geçerli. Uygulama içi güncelleme (OTA) kullanıyorsanız dikkat edin: o kanal, mağaza incelemesini atlayarak kullanıcı cihazına kod indiren bir yoldur. İmzalanması ve erişiminin dar tutulması gerekir.

Bu hafta yapılacak dört şey

Bir: gerçek kullanıcı cihaz dağılımınıza bakın. Analitikte iOS ile Android oranı ne, cihazların yaşı ne? Tek platform baskınsa tartışmanın yarısı burada biter.

İki: uygulamanın gerçekten yapması gereken beş şeyi yazın ve her birinin yanına gereken cihaz yeteneğini not edin. Listede kamera akışı işleme, arka plan senkronizasyonu veya Bluetooth eşleme yoksa cross-platform yolunuz açık demektir.

Üç: bakım bütçesini baştan yazın. Yılda iki çerçeve yükseltmesi, iki işletim sistemi ana sürümüne uyum, mağaza politika değişiklikleri. Bu kalemi tekliften düşerseniz ilk yılın sonunda geri gelir.

Dört: küçük ama gerçek bir ekran seçip iki hafta içinde her iki platformda çalışır hale getirin. Karar bir karşılaştırma tablosuyla değil, ekibinizin o iki haftada ürettiği hızla verilir. Dağıtım tarafını baştan kurmak isterseniz küçük ekipler için CI/CD yazısı mobil hat için de iyi bir başlangıç; kararın ticari tarafı için hazır paket mi özel yazılım mı ve teknik borcu ölçme ve önceliklendirme yazılarına bakabilirsiniz.