Native, Hybrid ve Web Uygulama: Seçimi Ne Belirler?
Native, hybrid ve web arasındaki seçim çoğu yazıda performans karşılaştırmasına indirgeniyor. Oysa bugünün cihazlarında üçünün de yeterince hızlı çalıştığı geniş bir alan var; ayrım asıl olarak tarayıcının erişemediği yeteneklerde ortaya çıkıyor. Peki o yetenekler gerçekten gerekiyor mu, yoksa listeye alışkanlıktan mı yazılıyor?
Ayrımı performans değil, erişim yapıyor
Native uygulama tek bir işletim sistemi için derlenir ve cihazın sunduğu hemen her şeye ulaşır: arka planda çalışma, Bluetooth eşleşmesi, sağlık verisi, kamera üzerinde kare kare kontrol. Hybrid tarafta tek kod tabanı iki platformda çalışır, tarayıcı motorunun ulaşamadığı yerler köprü eklentileriyle kapatılır. Web uygulaması ise yalnızca tarayıcının izin verdiği kadarını görür.
Bu sınır sabit değil, her yıl web lehine kayıyor. Service worker ile çevrimdışı çalışma, Web Push ile bildirim (iOS tarafında 16.4 sürümünden beri, ana ekrana eklenmiş uygulamalar için), getUserMedia ile kamera erişimi artık tarayıcıda var. Yani "web çevrimdışı çalışmaz" cümlesi eskidi. "Web arka planda sürekli konum toplayamaz" cümlesi hâlâ geçerli. Karar verirken bakılacak yer tam olarak bu ikisinin arasındaki daralan bant.
| Özellik | Native | Hybrid | Web |
|---|---|---|---|
| Kod tabanı | Platform başına ayrı | Ortak | Ortak |
| Donanım erişimi | Tam | Eklentinin desteklediği kadar | Tarayıcı API'leriyle sınırlı |
| Mağaza incelemesi | Her sürümde | Her sürümde | Yok |
| Düzeltmenin kullanıcıya ulaşması | Gün mertebesinde | Gün mertebesinde | Dakikalar içinde |
Herkesin verdiği örnekler çoğu listede yanlış yerde duruyor
Instagram, "native olmasa olmazdı" örneği olarak gösterilir. Gerçekte Instagram, React Native'i 2016'dan itibaren üretimde kullanan ilk büyük uygulamalardan biri oldu; kendi mühendislik yazılarında bazı ekranlarda iOS ile Android arasında kodun neredeyse tamamını paylaştıklarını anlattılar. Uber için de benzer bir durum var: şirket, düşük bant genişlikli pazarlar için birkaç yüz kilobayta sığan m.uber.com adında bir progressive web app yayınladı. Konum ve harita, tarayıcıda çalıştı.
Ters yönde de aynı karışıklık var. Gmail'in mobil uygulamaları hybrid değil, native. Twitter'ın hybrid diye anılan yapısı ise sektörün en çok konuşulan PWA vakalarından biriydi (Twitter Lite). Bir örnek listesinde dört maddeden üçü yanlış sınıflandırılabiliyorsa, o listeye bakarak karar vermenin kendisi sorunlu.
Kararı bitiren tek soru
Uygulamanın yapması gereken işlerden hangisi tarayıcıda hiç yapılamıyor? Cevap "hiçbiri" çıkıyorsa native tarafa geçmenin bedeli, karşılığında alınandan büyük olur: iki ayrı kod tabanı, iki mağaza incelemesi, her küçük düzeltme için yeniden yayın kuyruğu.
Yeni bir işe başlarken varsayılanım web tarafı; native'e ancak tarayıcının veremediği somut bir yetenek listeye girdiğinde geçerim. Sürekli arka plan konumu, cihaz eşleşmesi, ağır 3B grafik, uygulama içi satın almanın mağaza tarafından zorunlu tutulması. Hybrid arada durur ve seçilme sebebi çoğu zaman teknik değil, ekiptir: elinizde React bilen üç kişi varsa React Native ile çıkacağınız yol, sıfırdan Swift ve Kotlin ekibi kurmaktan kısadır.
Hybrid'in faturası sonradan geliyor
Hybrid'in maliyeti ilk sürümde ucuz görünür. Pahalı olan kısım, kullandığınız köprü eklentisinin bakımsız kalıp yeni işletim sistemi sürümüyle bozulduğu ay ortaya çıkar. O noktada ya eklentiyi kendiniz sürdürürsünüz ya da o özelliği native koda düşürürsünüz; ikisi de bütçede hesaplanmamış işlerdir. Eklenti seçerken son commit tarihine bakmak, yıldız sayısına bakmaktan daha çok işe yarar.
Peki baştan yanlış seçildiyse? Yönler simetrik değil. Web'den native'e geçmek görece kolaydır, çünkü elinizde çalışan bir ürün ve gerçek kullanım verisi olur; hangi ekranın native'e değdiğini artık tahmin etmezsiniz. Native'den web'e dönmek ise pratikte baştan yazmak demektir. Belirsizlik varken ucuz olan tarafta durmak bu yüzden mantıklı.