Native mi cross platform mı

Native ile cross platform arasındaki fark tam olarak nedir?

Native, programı o işletim sisteminin kendi araçları ve diliyle yazmak demektir. Google ın kendi belgeleri açık: 2019 dan beri Android geliştirmenin giderek Kotlin öncelikli olduğu ilan edildi ve aynı sayfa, bir Android uygulaması yapmak istiyorsanız Kotlin ile başlamanızı öneriyor. Apple tarafında ise Swift var. Sonuç şu: iki işletim sistemindeki tek bir uygulama, iki ayrı programdır.

Cross platform, tek bir kod tabanı yazıp aynı kodu ikisinde de çalıştırmak demektir. İki yaygın aile iki farklı yol izler ve anlaşılmaya değer olan da bu farktır. React Native belgeleri, çalışma zamanında karşılık gelen Android ve iOS görünümlerini oluşturduğunu ve bileşenleri bu aynı yerel görünümlerle desteklendiği için uygulamaların diğer uygulamalar gibi göründüğünü, hissettirdiğini ve performans verdiğini söylüyor. Flutter başka bir yol tutuyor ve desteklenen platformlar sayfası, Android ile iOS un ötesine geçip Windows, macOS ve Linux u da kapsayan bir erişim gösteriyor.

Yani tartışma hız üzerine değil, aynı işi kaç kez yaptığınız üzerine. Native de çalışan bir ekip her özelliği iki kez kurar, iki kez test eder ve iki kez bakımını yapar. Cross platformda çalışan bir ekip bir kez kurar ve platform farklı davrandığı her yerde bir istisna yazar. İki yolun da gerçek maliyeti o cümlenin içindedir.

Kararı gerçekten değiştiren dört şey

Performans tavanı. Listeler, formlar ve içerik ekranları için iki yol da yeterince hızlıdır ve kullanıcı bir fark görmez. Tavan, iş sürekli ve ağır olduğunda kendini gösterir: kesintisiz animasyon, kamera görüntüsünün canlı işlenmesi, oyunlar. Native orada öne geçer ve yalnızca program gerçekten böyle bir iş yapıyorsa.

Ekibin büyüklüğü ve bilgisi. En büyük etken ve en az konuşulanı budur. Kotlin bilen biri, yol üstünde öğrendiği bir çerçeveyle değil Kotlin le daha hızlı ve daha sağlam ilerler. Hem Android i hem iOS u sürdürmesi gereken iki kişi, tek bir ortak kod tabanıyla nefes alır. Doğru soru hangi teknolojinin daha iyi olduğu değil, bu kodu yarın kimin açacağıdır.

Bütçe ve her şeyden önce ikinci yıl bütçesi. İlk maliyet kurmaktır; projeleri öldüren maliyet ise bakımdır. İki kod tabanı, her küçük değişikliğin iki kez, her hatanın iki kez ve her sürümün iki kez demektir. Bakım bütçesi ikisinden biri için yetmiyorsa karar fiilen çoktan verilmiştir.

Her iki mağazaya ulaşmak. Cross platform lehine en çok tekrarlanan cümle budur ve İran pazarı için yeniden incelenmesi gereken tam da odur. Sonraki bölüm bunu yapıyor.

İran pazarı için her iki mağazaya ulaşmak ne demek?

Google ın geliştirici ve satıcı kaydı için desteklenen konumlar başlıklı resmi sayfası 215 ülke ve bölgeden oluşan bir tablo taşıyor. O sayfayı bugün okuduk: Irak tabloda var ve İran sözcüğü sayfanın tamamında bir kez bile geçmiyor. Yani İran daki biri için resmi geliştirici kayıt yolu o tabloda tanımlı değil. Ne bir dolanma yolu öneriyoruz ne de hiçbir yol olmadığını iddia ediyoruz; söylediğimiz şey Google ın kendi belgesinde yazandır.

Dolayısıyla biri her iki mağazaya yayını cross platformun başlıca avantajı diye sattığında, İran pazarı için sorunun değişmesi gerekir. Buradaki bir Android uygulaması Cafe Bazaar ve Myket ten, bazen de doğrudan sitedeki bir dosyadan kurulur; iOS sürümü ise ayrı bir hikâyedir. Bunun ayrıntısı bu yoldaki yayın dersinin işidir.

Şimdi reklamların söylemediği sonuç: pratikte yalnızca Android için yayınlıyorsanız, cross platform seçmenin nedeninin büyük bölümü ortadan kalkar ve Kotlin yeniden tamamen mantıklı bir seçim olur; çünkü o tek kod tabanına zaten sahipsiniz ve onunla birlikte performans tavanını ve platforma tam erişimi de alırsınız.

Tersi de geçerli. Aynı uygulamanın gelecek yıl bir iOS sürümü olacaksa, geri dönüp sıfırdan yazmak baştan tek bir ortak kod tabanına sahip olmaktan pahalıya gelir. Doğru karar, o iOS sürümünün gerçek bir plan mı yoksa bir toplantıdaki bir cümle mi olduğuna bağlıdır.

Cross platform nerede işe yaramaz

Dört durum. Birincisi, sürekli grafiği olan her şey: oyunlar, bir görüntü düzenleyici, saniyede onlarca kez yeniden çizilen herhangi bir arayüz. İkincisi, donanımla kesintisiz çalışma: kameranın canlı kullanımı ya da arka planda okumanız gereken sensörler. Üçüncüsü, işletim sistemiyle derin bütünleşme: ana ekran widget ı, arka plan servisi, sistem sürümüne bağlı davranışlar.

Dördüncüsü daha teknik ve diğer üçünden daha çok projeyi hazırlıksız yakalar. Cross platform, platform yeteneklerini kendisi için saran bir katmana bağımlıdır. O sarmalayıcı var olduğu sürece her şey yolundadır. Yeni ya da az kullanılan bir yetenek gerektiği ve ona ait bir sarmalayıcı bulunmadığı anda o parçayı native yazmak gerekir: bir kez Android, bir kez iOS için. O noktada tek kod tabanı yerine üç taneniz olur. Bu maliyet ilk tahminde asla görünmez.

Bir de hiç teknik olmayan beşinci durum: yalnızca native bilen ve değişmeyecek bir ekip. Gerçek bir projenin ortasında yeni bir yığın öğrenmek, o yığının seçilme nedeni olan tasarrufu genelde aşan bir maliyettir.

Bir yığın seçmeden önce şu beş soruyu yanıtlayın

Kullanıcınız uygulamayı nereden kuruyor? Uygulama zamanının çoğunu neyle geçiriyor, içerik ve formlarla mı yoksa kamera ve grafiklerle mi? İkinci yılda bakımını kim yapıyor? Yarın bir iOS sürümü gerekirse bütçesi var mı? Ve ekip bugün gerçekten ne biliyor?

Beş yanıtı yan yana koyun, karar genellikle kendini gösterir ve kimsenin sizin yerinize karar vermesi gerekmez. Yapmamanız gereken şey bir çerçeve karşılaştırma listesinden başlamaktır; o listelerin hepsi doğrudur ve hiçbiri sizin projeniz hakkında değildir.

Duruşumuz, uygulama geliştirme hizmetleri sayfamızda yazılı olan ve bu ders var olmadan önce de orada duran şudur: içerik ve basit formlarla çalışan bir uygulama için cross platform daha mantıklı seçimdir ve varsayılan olarak en pahalı seçeneği önermeyiz. Uygulamanızın hangi gruba düştüğünden hâlâ emin değilseniz, bir uygulama gerçekte nasıl çalışır dersi bu gruplandırmanın geldiği sınırı gösteriyor.