Mengapa Saya Bertahan dengan Native Kotlin (XML): Realita Developer Spesifikasi Menengah

Coba buka LinkedIn atau grup komunitas programmer hari ini. Anda pasti akan dihujani oleh narasi seperti: “Flutter adalah masa depan!”, “React Native memangkas waktu development!”, atau “Segera tinggalkan XML dan beralihlah ke Jetpack Compose!”

Narasi tersebut sering kali memicu rasa FOMO (Fear Of Missing Out) yang parah bagi developer pemula. Namun, mari kita singkirkan sejenak ego teknologi tersebut dan menatap satu realita yang paling sering diabaikan oleh para tech influencer: Spesifikasi perangkat keras (hardware) yang kita miliki.

Sebagai seorang Solo Android Developer yang juga berprofesi sebagai guru, saya tidak memiliki kemewahan untuk menggunakan Macbook Pro M-Series terbaru. Mesin tempur saya adalah laptop kelas pekerja dengan spesifikasi menengah.

Di artikel ini, saya ingin membagikan opini teknis mengapa saya—setelah berkelana mencoba berbagai framework modern—memilih pulang dan bertahan pada arsitektur klasik Native Kotlin dan XML.

Ilusi Cross-Platform: Dependency Hell dan Ukuran APK

Jauh sebelum saya mendalami bahasa pemrograman Kotlin, cinta pertama saya jatuh pada React Native dan Flutter. Janjinya amat manis: tulis kode satu kali, aplikasi bisa berjalan mulus di Android dan iOS.

Namun, masa itu berakhir cepat saat saya berbenturan dengan realita teknis di lapangan:

1. Tragedi Dependency Hell: Di ekosistem React Native, kemudahan JavaScript dibayar mahal dengan ukuran folder node_modules yang rakus memori. Setiap kali saya ingin melakukan pemeliharaan aplikasi (maintenance) setelah beberapa bulan, selalu ada library pihak ketiga yang usang (deprecated) atau memicu error fatal karena bentrok versi.
2. Ukuran Aplikasi (APK size) yang Membengkak: Flutter memang jauh lebih stabil secara performa dibandingkan React Native. Sayangnya, ukuran APK yang dihasilkan sangat bengkak. Aplikasi sederhana yang seharusnya hanya 3 MB bisa melonjak menjadi 20 MB lebih karena Flutter harus menyertakan engine rendering C++ miliknya sendiri.

Bagi target pasar saya di Indonesia, ukuran file yang besar adalah alasan utama pengguna melakukan uninstall. Seperti yang pernah saya singgung dalam Bongkar Realita Pendapatan AdMob Indonesia, mempertahankan User Experience (UX) dan kestabilan aplikasi adalah kunci utama jika Anda ingin bertahan lama di industri ini.

Patah Hati dengan Jetpack Compose

Jika framework lintas platform bukan jawabannya, bukankah Google sudah merilis Jetpack Compose untuk ekosistem Native? Ya, benar. Compose adalah UI toolkit modern yang deklaratif, bersih, dan cepat ditulis.

Sayangnya, “masa depan” itu ternyata belum siap untuk spesifikasi laptop saya.

Saat mengikuti pelatihan Android pada 2022, saya menggunakan laptop Dell Latitude E5450 (Intel Core i5 Gen 5, RAM 16GB, SSD 256GB). Saat mencoba fitur @Preview di Jetpack Compose, kipas laptop saya langsung menyala seperti mesin jet, Android Studio seketika membeku (hang), dan waktu rendering-nya sangat menyiksa.

Maju ke tahun 2024, saya telah melakukan upgrade ke Dell Latitude 5300 (Intel Core i5 Gen 8, Windows 11). Saya kembali menantang Compose. Hasilnya? Proses rendering preview saat mengetik kode masih terlalu lamban. Ritme kerja saya hancur karena lebih banyak waktu terbuang untuk menunggu loading bar Build selesai dibandingkan menulis logika kode.

Jetpack Compose adalah teknologi brilian, tetapi memaksakan diri menggunakannya di mesin yang terbatas hanya akan membunuh produktivitas coding Anda.

Keunggulan Native Kotlin + XML untuk Spesifikasi Terbatas

Akhirnya, saya kembali ke pangkuan kombinasi klasik: Native Kotlin dan XML. Ini bukanlah sebuah kemunduran, melainkan keputusan paling pragmatis. Berikut adalah tiga keunggulan tak terbantahkan dari arsitektur ini:

1. Rendering UI Instan dan Bebas Hang

Menulis layout UI menggunakan XML di Android Studio ibarat bernapas lega. Fitur Design Preview XML bekerja sangat ringan dan instan tanpa membebani CPU. Meskipun XML memiliki batasan struktur yang kaku, batasan ini justru memaksa kita untuk lebih disiplin dalam mendesain hierarki komponen—sebuah prinsip yang sejalan dengan Teori Dasar UI/UX Designer yang ideal.

2. Diet Ketat APK (Di Bawah 10 MB)

Karena aplikasi Native Kotlin murni bertumpu pada komponen bawaan sistem operasi Android, hasil kompilasinya sangatlah ramping. Sebagai bukti, aplikasi Asmaul Husna Arti dan Makna yang saya kembangkan sendirian dengan arsitektur ini memiliki output APK di bawah 10 MB. Aplikasi ultra-ringan ini sukses menembus 50.000+ unduhan tanpa keluhan memori penuh dari pengguna.

3. Ekosistem “Offline-First” yang Tahan Banting

Fokus utama saya sering kali membangun arsitektur offline-first (aplikasi yang berjalan penuh tanpa internet). Di ekosistem cross-platform, library database lokal sering kali dikelola oleh pihak ketiga dan rawan ditinggalkan pembuatnya (abandoned).

Di ekosistem Native Android, saya menggunakan Room Database. Ini adalah library resmi langsung dari Google. Ia dijamin selalu kompatibel dengan OS Android versi terbaru. Merawat aplikasi dalam siklus 3 hingga 5 tahun ke depan terasa jauh lebih aman secara teknis.

Kesimpulan: Jangan Menjadi Korban FOMO

Jika Anda memiliki PC gaming dengan spesifikasi dewa atau seri Macbook terbaru, silakan melesat ke masa depan bersama Jetpack Compose, Flutter, atau React Native.

Namun, jika Anda adalah developer yang sedang merintis dengan spesifikasi mesin terbatas, jangan biarkan gengsi dan FOMO menghalangi produktivitas Anda. Pengguna di Play Store tidak akan pernah membedah kode Anda untuk melihat apakah Anda menggunakan Compose atau XML. Mereka hanya peduli: Apakah aplikasinya ringan, tidak crash, dan memecahkan masalah mereka?

Bertahanlah dengan Native Kotlin dan XML. Rilis karya Anda, rawat penggunanya, dan kelak saat hardware Anda sudah mumpuni, barulah kita sama-sama melangkah ke teknologi selanjutnya. Keep it simple, keep coding!