Native mi, Cross-Platform mu? Mobil Uygulama İçin Teknoloji Seçim Rehberi

Native ve cross-platform arasında evrensel bir kazanan yoktur. Doğru seçim; hedef platformlar, cihaz özellikleri, kullanıcı deneyiminin ne kadar ayrışacağı, performans riski, ekip yetkinliği, erişilebilirlik, test kapsamı, yayın operasyonu ve uzun vadeli bakım sorumluluğuna göre yapılır.

Cross-platform ortak kod sayesinde bazı teslimatları birleştirebilir; fakat “tek kod, yarı maliyet” anlamına gelmez. Native yaklaşım platforma daha doğrudan erişim sağlar; fakat iki istemci ekibi ve sürüm akışı doğurabilir. Kararı teknoloji adıyla değil, riskli kullanıcı görevlerinin kanıtıyla verin.

Native ve Cross-Platform Ne Anlama Gelir?

Native uygulama hedef işletim sisteminin resmi dil, SDK, arayüz ve geliştirme araçlarıyla hazırlanır. Android tarafında Google, platformunu Kotlin-first olarak tanımlar ve yeni Android geliştirmede Kotlin ile başlamayı önerir (Android Developers: Kotlin-first). Apple’ın SwiftUI belgesi, Swift ile Apple platformlarında ortak bir bildirimsel arayüz yaklaşımı sunar. Bunlar iOS ve Android’in tek istemci kodunda birleştiği anlamına gelmez.

Cross-platform yaklaşım; iş mantığı, arayüz veya başka istemci katmanlarını birden fazla platformda paylaşmayı amaçlar. Flutter mimari özeti, Dart uygulama katmanı ile framework, engine ve platform katmanlarının ilişkisini açıklar. React Native mimari özeti ise JavaScript/React katmanı, C++ çekirdek ve host platform arasındaki yapıyı tanımlar. İki framework aynı mimari değildir ve resmi belgeler sürümlerle değişebilir.

Kumsal Platform Karar Ağacı

Bu özgün karar ağacı, teknoloji seçimini yedi kanıt kapısından geçirir: platform kapsamı, cihaz/OS bağımlılığı, deneyim ayrışması, performans iş yükü, ekip/ekosistem, test/erişilebilirlik ve bakım/ürün sahipliği. Bir teknoloji puan tablosu veya performans garantisi değildir.

1. Platform kapsamı: iOS ve Android aynı anda mı, farklı tarihlerde mi, yoksa tek platform mu?
2. Cihaz ve OS: Hangi sensörler, arka plan görevleri, bildirim, widget veya sistem servisleri kritik?
3. Deneyim: İki platform aynı akışı mı, yoksa yerel kalıp ve özelliklerle ayrışan deneyimleri mi gerektiriyor?
4. İş yükü: Yoğun animasyon, medya, harita, gerçek zamanlı veri, çevrim dışı işlem veya hesaplama var mı?
5. Ekip: Hangi diller, araçlar, CI/CD ve hata ayıklama yetkinlikleri gerçekten mevcut?
6. Kalite: Cihaz matrisi, erişilebilirlik, güvenlik ve mağaza testleri nasıl yürütülecek?
7. Yaşam döngüsü: İşletim sistemi ve framework güncellemelerini, eklentileri ve native köprüleri kim sürdürecek?

Native Yaklaşım Ne Zaman Daha Güçlü Bir Adaydır?

• Yeni veya derin işletim sistemi özelliklerine erken ve yoğun erişim gerekiyorsa
• Kamera, ses/video, Bluetooth, NFC, konum, arka plan çalışması veya cihaz üreticisine özel davranış ürünün çekirdeğiyse
• Platformların kullanıcı deneyimi belirgin biçimde farklı tasarlanacaksa
• Yoğun grafik, animasyon veya gecikmeye duyarlı akışlar ölçümde risk gösteriyorsa
• Kuruluşta sürdürülebilir iOS ve Android ekipleri ile ayrı yayın sahipleri varsa
• Framework/eklenti katmanına bağımlılığı azaltmak stratejik öncelikse

Bu maddeler otomatik native kararı değildir. Bir cihaz özelliğinin yalnız bir ekranda kullanılması, bütün uygulamanın ayrı kod tabanlarıyla geliştirilmesini gerektirmeyebilir. Özelliğin sıklığı, kritikliği, mevcut eklenti kalitesi ve native modül geliştirme kapasitesi birlikte değerlendirilir.

Cross-Platform Ne Zaman Daha Güçlü Bir Adaydır?

• iOS ve Android ürün kapsamı ile ekran davranışları büyük ölçüde aynıysa
• Form, liste, hesap, içerik, e-ticaret veya standart iş akışları ağırlıktaysa
• Tek ürün ekibi ve ortak tasarım sistemiyle iki platformu birlikte yönetmek isteniyorsa
• Riskli cihaz özelliklerinin güncel framework/eklenti desteği prototiple doğrulanabiliyorsa
• Ortak iş mantığı, test ve bileşen yatırımının bakımda değer üretmesi bekleniyorsa
• Ekip seçilen dil, araç zinciri ve gerektiğinde native kod yazma konusunda yetkinse

Cross-platform, platform farklarını yok etmez. İzinler, bildirimler, klavye, geri davranışı, güvenli depolama, arka plan sınırları, derleme, imzalama, mağaza ve erişilebilirlik iki platformda ayrı test edilir.

Cihaz Özellikleri İçin Nasıl Karar Verilir?

Özellik listesini “kamera var” düzeyinde bırakmayın. Kamera için canlı önizleme, yüksek çözünürlük, video, kırpma, belge tarama, çevrim dışı kuyruk, izin reddi ve arka plan yükleme farklı risklerdir. Aynı ayrıntı Bluetooth cihaz türü, konum sıklığı, harita katmanı, biyometri, dosya paylaşımı ve push bildirim için gerekir.

Her kritik özellikte resmi platform API’sini, framework API’sini/eklenti durumunu, lisans ve bakım sahibini, desteklenen OS/cihazları, hata davranışını ve native kaçış yolunu kaydedin. Eklenti mevcut olması üretim kalitesi veya uzun vadeli bakım garantisi değildir.

Performans Kararı Nasıl Kanıtlanır?

“Native hızlıdır” veya “framework native performans verir” gibi genel sloganlar kabul ölçütü değildir. Kritik iş yükünü tanımlayın: uygulama açılışı, uzun liste, büyük görsel, animasyon, harita, video, gerçek zamanlı veri, şifreleme, arka plan senkronu veya düşük bağlantı.

Temsilî düşük, orta ve üst cihazlarda süre, kare takılması, bellek, pil, ağ kullanımı ve hata davranışını ölçün. Aynı veri, ekran ve kabul ölçütüyle küçük bir teknik prototip karşılaştırması yapın. Laboratuvar sonucu bütün kullanıcılar için sonuç garantisi değildir; cihaz ve sürüm matrisiyle yeniden test gerekir.

Kod Paylaşımı Gerçek Maliyeti Nasıl Etkiler?

Paylaşılabilen iş mantığı, veri modeli, ağ katmanı, doğrulama, tasarım bileşenleri ve testler proje maliyetini azaltabilir. Buna karşılık native modüller, platforma özel arayüz, eklenti yükseltmeleri, hata ayıklama, iki cihaz matrisi, iki mağaza ve yayın operasyonu devam eder.

Teklifte “yüzde kaç kod ortak?” yerine hangi modülün neden ortak olduğunu, hangisinin platforma özel kaldığını ve sahipliğini isteyin. Kod satırı oranı; kalite, teslim süresi veya bakım kolaylığını tek başına göstermez.

Erişilebilirlik ve Platform Davranışı

Ekran okuyucu adları ve rolleri, odak sırası, dinamik metin boyutu, renk/kontrast, dokunma alanı, hareket azaltma, klavye ve dış cihazlar gerçek platformlarda sınanmalıdır. Ortak bileşen görsel olarak aynı görünse bile erişilebilirlik ağacı ve sistem davranışı farklı olabilir.

Native veya cross-platform seçmek erişilebilirliği otomatik çözmez. Tasarım sistemi gereksinimleri, framework bileşenleri, özel çizim alanları ve native köprüler test kapsamına girer. Ürün ekibi her platform için gerçek yardımcı teknolojiyle kabul kanıtı toplamalıdır.

Test Matrisi Neleri İçermeli?

• Desteklenen işletim sistemi sürümleri ve cihaz sınıfları
• Ekran boyutu, yön, dil, bölge ve dinamik yazı
• İzin verilmiş, reddedilmiş ve sonradan değiştirilmiş durumlar
• Çevrim dışı, yavaş ağ, zaman aşımı ve yeniden senkron
• Arka plan/ön plan geçişi, uygulamanın sonlandırılması ve geri dönüş
• Bildirim, deep link, dosya paylaşımı ve dış uygulama dönüşü
• Güvenli oturum, veri saklama ve hesap kapatma
• Erişilebilirlik ve gerçek kullanıcı görevleri
• Platform güncellemesi, framework/eklenti yükseltmesi ve geri dönüş
• Mağaza öncesi paket, imza, yapılandırma ve analitik doğrulama

Flutter ve React Native Nasıl Karşılaştırılmalı?

Karşılaştırma marka popülerliğiyle sınırlanmamalıdır. Güncel resmi sürüm desteği, dil ve ekip yetkinliği, arayüz yaklaşımı, platform API erişimi, gerekli eklentilerin sahipliği, hata ayıklama, test araçları, derleme/yayın zinciri ve uzun vadeli bakım incelenir.

İnternetteki eski benchmark veya eklenti listelerini güncel kabul etmeyin. Aynı kritik prototipi iki adayla geliştirmek her proje için gerekli olmayabilir; fakat yüksek riskli cihaz özelliği veya performans iş yükünde küçük bir karşılaştırma, varsayımdan daha güçlü kanıt sağlar.

Hibrit Mimari Seçenekleri

Karar yalnız “tam native” veya “tam cross-platform” olmak zorunda değildir. Ortak backend ve API her iki native istemciye hizmet verebilir. Cross-platform uygulama belirli özelliklerde native modül kullanabilir. Mevcut native uygulamaya sınırlı paylaşılan ekran veya iş mantığı eklenebilir.

Hibrit yaklaşımda sınır belirsizse iki teknolojinin maliyeti birlikte büyür. Hangi katmanın ortak, hangisinin platforma özel olduğu; veri ve hata akışının nerede kesildiği; sürüm uyumluluğunu kimin test ettiği yazılmalıdır. Entegrasyonları veri alanı ve hata davranışıyla planlamak için web yazılım entegrasyonları rehberini kullanabilirsiniz.

Platform Kararı İçin Pilot Nasıl Yapılır?

1. En riskli bir veya iki kullanıcı görevini seçin.
2. Hedef cihaz/OS, ağ ve erişilebilirlik koşullarını sabitleyin.
3. İşlev, performans, hata ve kullanıcı deneyimi kabul ölçütlerini yazın.
4. Gerekli native API veya eklentinin güncel desteğini doğrulayın.
5. Derleme, test, hata ayıklama ve mağaza paketini de pilot kapsamına alın.
6. Sonucu yalnız demo görüntüsüyle değil ölçüm, hata listesi ve bakım notuyla kaydedin.

Pilot, bütün ürünün sonucunu garanti etmez; en pahalı varsayımları erken sınar. Ekip öğrenme süresi ile teknolojinin kalıcı sınırını birbirinden ayırın.

Teklifte Hangi Sorular Sorulmalı?

• Seçim hangi kullanıcı görevleri ve teknik risklere dayanıyor?
• Hangi kod/katman ortak, hangileri platforma özel?
• Kritik cihaz özellikleri nasıl prototiplendi?
• Native modül ve üçüncü taraf eklentilerin sahibi kim?
• iOS ve Android test matrisi nedir?
• Erişilebilirlik hangi gerçek araçlarla doğrulanacak?
• Framework, OS ve eklenti güncellemesi nasıl izlenecek?
• CI/CD, imzalama, mağaza hesapları ve yayın kimde olacak?
• Hata izleme, analitik, çökme ve geri dönüş süreci nedir?
• Kaynak kod, dokümantasyon, hesaplar ve devir nasıl teslim edilecek?

Tedarikçileri aynı teknik kanıtlarla değerlendirmek için yazılım firması teknik yeterlilik kontrol listesini kullanabilirsiniz.

Sonuç

Native veya cross-platform seçimi tek bir performans ya da maliyet sloganıyla yapılamaz. Platform kapsamı, cihaz bağımlılığı, deneyim, iş yükü, ekip, kalite ve yaşam döngüsü birlikte değerlendirilmelidir. Platform Karar Ağacı kararı gerçek görev ve pilot kanıtına bağlar.

Mobil uygulama teknolojisi, kapsamı ve teslim modelinizi değerlendirmek için Kumsal Ajans mobil uygulama ekibiyle görüşebilirsiniz.