Flutter vs Native: Kenapa Saya Tetap Pilih Native buat Sebagian Besar Proyek Mobile

Flutter itu bagus, dan saya udah pernah pakai buat beberapa proyek client yang emang butuh dua platform sekaligus dengan budget dan timeline ketat. Tapi buat sebagian besar kerjaan mobile saya sekarang, saya tetap balik ke native — Swift buat iOS, Kotlin buat Android. Bukan karena saya anti cross-platform secara prinsip. Lebih ke soal di mana breaking point-nya biasanya muncul.

Akses API platform yang nggak nunggu

Fitur-fitur baru dari Apple atau Google biasanya nongol duluan di native SDK, baru belakangan (kalau ada) di-bridge ke Flutter lewat plugin komunitas. Saya pernah kena ini langsung: satu proyek client butuh integrasi Live Activities di iOS (widget yang nongol di lock screen buat nunjukin progres real-time), dan waktu itu plugin Flutter buat fitur ini masih setengah jadi — beberapa edge case nggak kehandle, dan maintainer plugin-nya nggak terlalu aktif update. Saya akhirnya nulis native module sendiri buat nge-bridge itu ke Flutter, yang ujung-ujungnya bikin saya mikir: kalau saya harus nulis native code juga buat satu fitur penting, ngapain nggak native dari awal aja.

Performa dan feel yang lebih “kena”

Native widget otomatis ngikutin konvensi platform — animasi, gesture, feedback haptic — tanpa saya harus effort ekstra buat niruin. User biasanya nggak sadar kenapa, tapi mereka bisa “ngerasa” app yang native vs yang nggak. Scroll physics di iOS misalnya punya karakteristik rubber-band yang khas; Flutter bisa niruin, tapi butuh tuning manual yang di native udah gratis dari framework-nya.

Debugging yang nggak berlapis

Kalau ada bug aneh, saya debug langsung di layer yang sama dengan platform-nya, tanpa lapisan abstraksi tambahan yang kadang bikin stack trace membingungkan. Ini kerasa banget waktu ngejar bug memory leak di salah satu app — di Flutter, saya harus bolak-balik antara Dart heap dan native heap buat nyari sumbernya, karena Flutter engine sendiri punya lapisan rendering (Skia/Impeller) yang nggak selalu transparan soal di mana leak-nya beneran kejadian.

Ukuran tim dan skala proyek

Kalau saya kerja sendirian dan targetnya cuma satu platform dulu (misalnya iOS aja buat validasi produk), nggak ada alasan kuat buat nanggung overhead cross-platform framework. Setup awal Flutter emang cepat, tapi begitu proyeknya butuh makin banyak fitur platform-specific, overhead maintain dua “mental model” — widget tree Flutter plus native code buat yang nggak ke-cover — mulai kerasa lebih berat daripada langsung native dari awal.

Flutter tetap masuk akal kalau prioritas utamanya kecepatan rilis ke dua platform sekaligus dengan tim kecil dan budget terbatas, dan fitur-fiturnya nggak terlalu platform-specific — semacam MVP atau internal tool yang penting jalan cepat, bukan yang harus “kerasa” premium. Tapi kalau saya punya waktu dan proyeknya bakal di-maintain jangka panjang, native masih pilihan default saya. Ongkos belajar dua bahasa dan dua toolchain itu nyata, tapi buat saya itu lebih murah dibanding ongkos nge-debug lapisan abstraksi yang nggak selalu kooperatif.