Sekilas

  • “Aplikasi hybrid” sering kali digunakan terlalu luas. Hybrid WebView dan framework cross-platform modern memiliki karakteristik yang berbeda.

  • Cross-platform development dapat mengurangi pekerjaan duplikat, namun codebase bersama tidak menghilangkan design, pengujian, dan integrasi khusus platform.

  • native development tetap berharga untuk product dengan kinerja yang menuntut atau persyaratan platform yang mendalam.

  • Para pemimpin harus membandingkan keekonomian product secara keseluruhan, bukan hanya biaya pengembangan awal.

Diskusi arsitektur seringkali dimulai terlalu dini.

Seorang pemimpin bisnis mengatakan perusahaannya membutuhkan aplikasi untuk iOS dan Android. Seseorang merekomendasikan native development untuk kualitas. Yang lain merekomendasikan cross-platform development untuk kecepatan. Yang ketiga menyarankan memulai dengan web.

Perdebatan dengan cepat menjadi bersifat teknis.

Customer problem masih belum terdefinisi.

Arsitektur sangatlah penting karena memengaruhi kecepatan peluncuran, kinerja, pemeliharaan, perekrutan, dan fleksibilitas product di masa depan. Itu tetap harus mengikuti product strategy.

Sebelum memilih framework, team harus memahami apa yang perlu dilakukan oleh product, untuk siapa, dalam kondisi apa, dan bagaimana bisnis mengharapkan product tersebut berkembang.

Perjelas Terminologinya

“Aplikasi hybrid” dapat merujuk pada beberapa pendekatan.

Traditional hybrid app biasanya mengemas pengalaman web di dalam native container. Interface-nya terutama dibangun dengan teknologi web dan dirender melalui WebView.

Framework modern seperti React Native dan Flutter bekerja secara berbeda.

Komponen React Native dipetakan ke blok penyusun UI native platform dan dapat mengintegrasikan native code. Lihat ikhtisar resmi React Native.

Flutter menggunakan sistem renderingnya sendiri dan mengkompilasi aplikasi di seluruh platform yang didukung dari codebase bersama. Lihat ikhtisar resmi Flutter.

Pendekatan ini lebih baik digambarkan sebagai cross-platform development daripada diperlakukan sebagai bentuk arsitektur hybrid yang identik.

Perbedaan ini penting karena pengalaman, kinerja, integrasi, dan persyaratan team berbeda.

Opsi 1: Native Development

native app dibangun khusus untuk suatu platform.

Team iOS biasanya menggunakan lingkungan pengembangan Swift dan Apple. Team Android biasanya menggunakan Kotlin dan alat Android.

Di Mana Native Kuat

native development memberikan akses langsung ke kemampuan platform dan dukungan paling awal untuk feature operating system baru.

Seringkali cocok untuk:

  • Interaksi intensif kinerja.

  • Grafik tingkat lanjut.

  • Pemrosesan latar belakang yang rumit.

  • Integrasi perangkat keras yang mendalam.

  • Product yang pengalaman spesifik platformnya menjadi pembeda.

  • Team yang telah memiliki native capability yang kuat.

Pengorbanan

Penerapan platform terpisah dapat menciptakan upaya duplikat.

Perusahaan mungkin perlu membangun, menguji, merilis, dan memelihara fungsi serupa dua kali. product behavior dapat berubah ketika platform team bergerak dengan kecepatan berbeda.

Native development pada dasarnya tidak efisien. Biayanya harus disesuaikan dengan nilai kemampuan atau kendali spesifik platform.

Opsi 2: cross-platform development

Framework cross-platform memungkinkan sebagian besar product dibuat dalam codebase bersama dan diterapkan ke lebih dari satu platform.

Di Mana Cross-platform Kuat

Pendekatan ini dapat mendukung:

  • Pengiriman lebih cepat di iOS dan Android.

  • product logic bersama.

  • Ketersediaan feature yang lebih konsisten.

  • Team yang lebih kecil.

  • Reuse pengetahuan teknik yang lebih mudah.

  • Strategi pengujian terpadu untuk komponen bersama.

Flutter menggambarkan pendekatannya sebagai pengembangan multi-platform yang dikompilasi secara asli dari satu codebase. React Native menggabungkan JavaScript dan React dengan native UI dan API platform.

Pengorbanan

Satu codebase tidak berarti tidak ada pekerjaan khusus platform.

Team masih perlu menangani:

  • Konvensi interaksi iOS dan Android.

  • Izin.

  • Persyaratan app store.

  • Perbedaan perangkat.

  • native SDK.

  • Platform-specific bug.

  • Perilaku aksesibilitas.

  • Pengujian kinerja.

  • Peningkatan framework dan dependency.

Beberapa kemampuan memerlukan native module khusus. Framework juga dapat menimbulkan dependency pada ekosistem dan release cycle-nya.

Cross-platform bekerja paling baik ketika team merencanakan perbedaan ini daripada menjanjikan penyampaian “tulis sekali, jalankan di mana saja” yang sempurna.

Opsi 3: Progressive Web App

Progressive Web App berjalan melalui browser dan dapat menyediakan kemampuan seperti instalasi, dukungan offline, dan pemberitahuan jika didukung.

Di Mana Web Kuat

Pendekatan yang mengutamakan web dapat bermanfaat ketika:

  • Akses langsung melalui tautan itu penting.

  • Pencarian dan penemuan content itu penting.

  • Product tidak memerlukan integrasi perangkat keras yang mendalam.

  • Iterasi cepat adalah prioritas.

  • Bisnis ini ingin memvalidasi permintaan sebelum melakukan investasi platform yang lebih besar.

  • User sering berpindah antara desktop dan mobile.

Pembaruan dapat dikirimkan tanpa menunggu rilis app store.

Pengorbanan

Dukungan browser dan operating system bervariasi. Akses ke kemampuan perangkat mungkin lebih terbatas. Pengalamannya mungkin tidak terasa terintegrasi seperti native app.

Product web harus dipilih karena sesuai dengan customer journey, bukan hanya karena terlihat lebih murah.

Mulailah dengan Persyaratan Pengalaman

Arsitektur harus dievaluasi berdasarkan skenario product nyata.

Tanyakan:

  • Apakah product memerlukan penggunaan offline?

  • Kemampuan perangkat keras manakah yang penting?

  • Seberapa sensitifkah pengalaman terhadap latensi?

  • Apakah itu berisi animasi atau grafik yang rumit?

  • Seberapa pentingkah perilaku spesifik platform?

  • Seberapa sering product akan berubah?

  • Apa yang harus berfungsi di latar belakang?

  • Bagaimana cara user menemukan dan memasuki product?

  • Persyaratan aksesibilitas manakah yang berlaku?

  • Kemampuan teknik apa yang sudah dimiliki organisasi?

Daftar feature saja tidak cukup. Team harus menguji journey yang paling menuntut secara teknis dan penting secara strategis.

Evaluasi Total product economics

Biaya pembangunan awal menarik perhatian karena terlihat.

Biaya yang lebih besar muncul seiring berjalannya waktu:

  • Pemeliharaan.

  • Jaminan kualitas.

  • Peningkatan framework.

  • Pembaruan keamanan.

  • native integration.

  • Operasi app store.

  • Observabilitas.

  • Pengoptimalan kinerja.

  • Pemeliharaan design system.

  • Perekrutan dan kesinambungan pengetahuan.

  • Pengerjaan ulang ketika product perlu diubah.

Pembuatan awal yang lebih murah bisa menjadi mahal jika arsitekturnya tidak sesuai dengan product. Versi asli yang lebih mahal juga dapat menjadi boros jika aplikasi utamanya berisi content dan workflow standar.

Kasus bisnis harus mencakup setidaknya dua hingga tiga tahun, tidak hanya rilis pertama.

Gunakan Lonjakan Kemampuan Sebelum Melakukan

Ketika keputusan masih belum pasti, team dapat membuat eksperimen teknis kecil seputar persyaratan yang paling sulit.

Jangan membuat prototype layar yang paling mudah.

Uji feature yang paling mungkin mengekspos risiko arsitektur: lokasi latar belakang, pemrosesan kamera, data offline berukuran besar, animasi kompleks, SDK penting, atau kinerja perangkat kelas bawah.

Evaluasi:

  • Kinerja.

  • Upaya pembangunan.

  • Konsistensi platform.

  • Aksesibilitas.

  • Kemampuan untuk diuji.

  • Kompleksitas pemeliharaan.

  • native expertise yang dibutuhkan.

Ini menggantikan opini dengan bukti.

Arsitektur Harus Mempertahankan Pilihan

sebuah product akan berubah setelah diluncurkan.

Arsitektur harus memungkinkan team untuk menambah kemampuan, mengganti layanan, mengukur perilaku, dan mengembangkan pengalaman tanpa rekonstruksi terus-menerus.

Batasan yang jelas antara interface, logika bisnis, data, dan integrasi platform membuat evolusi tersebut lebih mudah, apa pun kerangka kerjanya.

Tujuannya bukan untuk memprediksi setiap kebutuhan di masa depan. Hal ini untuk menghindari keputusan yang membuat perubahan yang masuk akal menjadi mahal dan tidak perlu.

Tidak Ada Pilihan Cerdas Universal

cross-platform development adalah pilihan terbaik bagi banyak bisnis. Ini tidak secara otomatis merupakan jawaban yang benar.

native development dapat memberikan kedalaman platform yang lebih besar. Web dapat memberikan jangkauan dan kecepatan iterasi yang luar biasa. Cross-platform dapat menyeimbangkan pengiriman bersama dengan akses ke kemampuan perangkat.

Pilihan cerdas dibuat dengan menghubungkan arsitektur dengan customer value, realitas team, dan ekonomi jangka panjang.

Bisnis ini tidak memilih cara membuat dua aplikasi. Hal ini berarti memilih landasan pengoperasian untuk satu product experience dalam berbagai konteks.