Mobile developer
Mobile developer membangun aplikasi yang berjalan di perangkat milik orang lain, di bawah sistem operasi yang bisa menghentikannya tanpa peringatan, dalam versi yang dipilih sendiri oleh penggunanya dan mungkin tidak pernah diperbarui. Ketiga kenyataan itulah yang membentuk seluruh disiplin ini. Panduan ini membahas apa saja yang dikerjakan di iOS dan Android, cara memikirkan pilihan antara native dan cross-platform, serta kapan sebuah tim membutuhkan spesialisasi ini.
Apa yang dikerjakan seorang mobile developer?
Mobile developer membangun dan merilis aplikasi untuk iOS, Android, atau keduanya â layar dan navigasinya, penyimpanan data lokal yang membuat aplikasi tetap berfungsi tanpa koneksi, integrasi dengan kemampuan perangkat seperti kamera, lokasi, biometrik, dan notifikasi, serta proses rilis yang membawa sebuah build melewati review store hingga sampai ke pengguna. Peran ini juga bertanggung jawab atas perilaku aplikasi pada perangkat dengan sumber daya terbatas: waktu startup, memori, konsumsi baterai, dan responsivitas pada perangkat yang jauh lebih tua daripada perangkat tempat aplikasi itu ditulis.
Perbedaan mendasarnya dari web engineering adalah Anda tidak mengendalikan versi yang sedang berjalan. Perbaikan di web sampai ke semua orang pada request berikutnya; perbaikan di mobile harus dibangun, ditandatangani, dikirimkan, direview, disetujui, dirilis, lalu dipasang oleh orang yang bisa saja menolak memperbarui selama berbulan-bulan. Karena itu pengguna menjalankan banyak versi sekaligus, dan setiap perubahan di server harus tetap kompatibel dengan klien yang ditulis jauh sebelumnya. Batasan tunggal itulah yang membuat tim mobile berhati-hati dengan cara yang tidak perlu dilakukan tim web, dan itu pula yang paling sering diremehkan ketika tim web diminta merilis sebuah aplikasi.
Perbedaan kedua adalah perangkatnya. Sistem operasi bisa menangguhkan atau menghentikan proses demi merebut kembali memori, eksekusi di latar dibatasi dan berbeda antar platform, konektivitas bersifat naik-turun alih-alih ada atau tidak ada, dan semua yang dilakukan aplikasi dibebankan ke baterai yang sedang diperhatikan penggunanya. Aplikasi yang mengandaikan adanya jaringan, mengandaikan dirinya terus berjalan saat berada di latar, atau mengandaikan dirinya akan dibuka kembali persis dalam keadaan terakhir akan berjalan sempurna di lingkungan pengembangan dan berperilaku aneh di tangan pengguna sungguhan.
Terakhir, kedua platform memang punya konvensi yang berbeda â navigasi dan perilaku tombol kembali, model permission, norma tipografi dan layout, lifecycle, kebijakan review, dan perkakas rilis. Framework cross-platform mengurangi kode yang terduplikasi tetapi tidak menghapus keharusan memahami keduanya, karena tempat abstraksinya berhenti persis adalah tempat pengguna menyadarinya: gesture, penanganan keyboard, notifikasi, deep link, aksesibilitas, dan segala hal yang menyentuh perangkat keras.
Kapan tim membutuhkan kapabilitas ini
Pekerjaan mobile kerap diserahkan kepada siapa pun yang paling dekat dengan front end, dengan anggapan bahwa aplikasi hanyalah situs web dengan cangkang berbeda. Berikut situasi ketika anggapan itu menjadi mahal.
Tim web diminta menghasilkan sebuah aplikasi
Engineer yang cakap biasanya sanggup menaruh sesuatu ke perangkat. Yang umumnya belum mereka miliki adalah release engineering, kebijakan store, konvensi navigasi platform, batas eksekusi di latar, serta kebiasaan merancang untuk basis terpasang yang menjalankan beberapa versi sekaligus. Penolakan pertama saat submission biasanya menjadi titik ketika semua itu terlihat.
Produk harus tetap berfungsi tanpa koneksi
Pekerjaan lapangan, logistik, lantai ritel, gudang, perjalanan, dan cakupan seluler yang bolong-bolong. Persistensi lokal, aksi yang diantrekan, penyelesaian konflik, serta penggambaran status sinkronisasi yang jujur adalah persoalan desain sama besarnya dengan persoalan engineering, dan semuanya tidak bisa ditambahkan secara meyakinkan setelah semuanya jadi.
Kemampuan perangkat adalah produknya
Kamera dan pemindaian, lokasi presisi atau lokasi di latar, periferal Bluetooth, autentikasi biometrik, data kesehatan atau sensor. Semuanya berada di balik model permission yang berbeda antar platform dan berubah antar versi sistem operasi, dan di situlah lapisan cross-platform generik paling sering kehabisan jangkauan.
Kualitas rilis mulai memakan ongkos
Crash yang menumpuk pada perangkat atau versi sistem operasi tertentu, rating store yang menurun, atau cacat yang sudah terlanjur rilis dan tidak bisa ditarik cepat. Mobile tidak punya padanan rollback cepat bagi pengguna yang sudah memperbarui, sehingga kualitas harus ditegakkan sebelum rilis, bukan diperbaiki sesudahnya.
Performa di perangkat nyata mulai dikeluhkan
Cold start yang lambat, scroll yang tersendat, aplikasi yang dihentikan saat berada di latar, atau baterai yang terkuras terasa. Semuanya didiagnosis dengan perkakas profiling platform pada perangkat yang mewakili pengguna sesungguhnya, dan jarang muncul pada perangkat flagship terbaru yang tersambung ke debugger.
Kapabilitas inti
Kefasihan platform
Memahami bagaimana setiap platform mengharapkan sebuah aplikasi berperilaku â semantik navigasi dan back stack, lifecycle activity dan view controller, prompt permission, tipografi sistem, dan konvensi layout. Aplikasi yang mengabaikannya biasanya digambarkan pengguna sebagai terasa janggal, jauh sebelum ada yang bisa menjelaskan mengapa.
Pertimbangan native dan cross-platform
Memahami apa yang sebenarnya dihemat oleh codebase bersama, di mana abstraksinya bocor, dan berapa ongkosnya turun ke kode native ketika itu terjadi. Keputusannya bergantung pada seberapa besar bagian produk yang menyatu dengan perangkat, seberapa berbeda perilaku yang dituntut di kedua platform, dan siapa yang akan memeliharanya.
Perilaku offline dan data lokal
Memilih penyimpanan lokal, memutuskan apa yang di-cache dan untuk berapa lama, mengantrekan aksi yang dilakukan saat terputus, menyelesaikan konflik ketika aksi itu sampai ke server, dan menampilkan status yang jujur kepada pengguna alih-alih status yang optimistis. Sinkronisasi adalah tempat aplikasi mobile menumpuk cacat-cacatnya yang paling sulit.
Performa pada perangkat terbatas
Waktu cold start, rendering frame saat scroll dan animasi, tekanan memori berikut penghentian yang diakibatkannya, dekode image, dan aktivitas latar yang menguras baterai. Pengukuran yang relevan datang dari perangkat kelas menengah yang lebih tua, bukan dari ponsel terbaru di kantor.
Release engineering
Signing dan provisioning, varian build, versioning, distribusi beta, phased rollout, metadata store, serta kemampuan memaksa pembaruan ketika sebuah versi klien harus dipensiunkan. Sebagian besar risiko operasional di mobile justru berada di sini, bukan di kode aplikasinya.
Review dan kebijakan store
Bekerja di dalam aturan yang ditegakkan tiap store â pengungkapan privasi, kebijakan pembayaran dan langganan, justifikasi permission, persyaratan konten, penghapusan akun â dan merancang agar hasil review bisa diperkirakan, bukan menjadi kejutan yang berulang di dalam rencana pengiriman.
Notifikasi dan pekerjaan latar
Pengiriman push lewat layanan masing-masing platform, siklus hidup token, permission dan opt-in, deep link yang membuka layar yang benar bahkan dari cold start, serta background task yang ditulis agar sanggup bertahan menghadapi sistem operasi yang akan menundanya, membundelnya, atau membatalkannya.
Aksesibilitas di mobile
Dukungan screen reader dengan VoiceOver dan TalkBack, label dan pengelompokan yang bermakna, penghormatan terhadap pengaturan ukuran teks dan reduced motion milik pengguna, ukuran target sentuh yang memadai, dan urutan fokus yang masuk akal. Aksesibilitas mobile punya konvensi dan perkakas pengujiannya sendiri; pengetahuan dari web sebagian berpindah tetapi tidak mencakup semuanya.
Fragmentasi perangkat dan versi
Memutuskan versi sistem operasi dan kelas layar mana yang didukung, menguji pada rentang perangkat yang mewakili pengguna alih-alih yang kebetulan tersedia, serta menangani perbedaan kemampuan tanpa menciptakan labirin percabangan kondisional.
Ekosistem teknologi
Berikut teknologi yang umum dipakai dalam mobile engineering. Daftar ini menggambarkan lanskap disiplin tersebut sebagaimana dipraktikkan secara umum di industri, dan bukan klaim tentang perkakas engineer mana pun. Pertanyaan yang lebih informatif di sini adalah di platform mana seorang kandidat pernah merilis dan memelihara aplikasi, karena pengetahuan soal store, rilis, dan lifecycle terikat pada platform dengan cara yang tidak berlaku pada pengetahuan bahasa pemrograman.
iOS
- Swift
- SwiftUI
- UIKit
- Xcode
- Swift Concurrency
- Combine
Android
- Kotlin
- Jetpack Compose
- Android SDK
- Android Studio
- Coroutines
Cross-platform
- React Native
- Flutter
- Expo
- Kotlin Multiplatform
- .NET MAUI
Data lokal dan sinkronisasi
- SQLite
- Room
- Core Data
- SwiftData
- Realm
- WatermelonDB
Layanan perangkat
- APNs
- Firebase Cloud Messaging
- Crashlytics
- Sentry
- RevenueCat
Testing
- XCTest
- Espresso
- Maestro
- Detox
- Appium
- Firebase Test Lab
Build dan distribusi
- Fastlane
- Xcode Cloud
- Bitrise
- TestFlight
- App Store Connect
- Google Play Console
Bagaimana peran ini bekerja dengan tim Anda
Engineer bekerja di dalam tim Anda, mengikuti prioritas dan standar Anda. Anda yang mengarahkan pekerjaannya; Talent.ID menangani hubungan kerjanya. Pembagian di bawah ini adalah keseluruhan pengaturannya.
Tetap milik Anda
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Ditangani Talent.ID
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Seperti apa ini dalam praktik
Skenario hipotetis, ditulis untuk menunjukkan bagaimana model kerjanya diterapkan. Ini bukan klien Talent.ID dan bukan proyek yang pernah dikerjakan.
- Tantangan
- Sebuah tim memelihara aplikasi di kedua platform sekaligus menjalankan roadmap fitur baru. Laporan crash menumpuk pada perangkat lama, perilaku offline perlu dirombak, dan setiap rilis memakan waktu yang sebenarnya ingin tim habiskan untuk produknya.
- Pendekatan
- Kapasitas mobile tambahan bekerja di dalam praktik yang sudah mapan di tim â arsitektur yang mereka pilih, konvensi branching dan review mereka, pendekatan testing mereka, serta ritme rilis mereka di masing-masing store. Prioritas fitur dan keputusan platform tetap diambil oleh tim yang memiliki aplikasinya.
- Yang ditambahkan ke tim
- Pekerjaan pemeliharaan dan pekerjaan platform bisa berjalan berdampingan dengan pengiriman fitur alih-alih saling berebut. Akan menjadi apa aplikasi itu, dan bagaimana ia dibangun, tetap berada di bawah arahan orang-orang yang bertanggung jawab atasnya.
Disiplin terkait
Pertanyaan yang sering diajukan
- Sebaiknya kami membangun native atau cross-platform?
- Bergantung pada seberapa besar bagian produk yang sebenarnya adalah perangkatnya. Aplikasi yang sebagian besar tersusun dari form, daftar, dan konten terlayani baik oleh codebase bersama, dan penghematan atas implementasi kedua itu nyata. Aplikasi yang dibangun di sekitar kamera, sensor, lokasi di latar, periferal Bluetooth, atau grafis berat justru membelanjakan penghematan itu untuk kode penjembatan dan pengecualian khas platform. Dua faktor non-teknis menentukan lebih banyak kasus daripada faktor teknisnya: siapa yang akan memeliharanya, dan apakah kedua platform perlu terasa berbeda secara bermakna. Satu engineer dengan daftar fitur yang luas umumnya mengarah ke codebase bersama; spesialis per platform dengan produk yang berat di sisi perangkat umumnya mengarah ke native.
- Bisakah seorang web developer membangun aplikasi mobile dengan React Native?
- Mereka bisa bergerak cepat di awal, karena model komponen dan bahasanya berpindah. Yang tidak ikut berpindah justru bagian yang menimbulkan kesulitan: signing dan submission ke store, model permission, lifecycle dan batasan latar, perilaku offline, pengiriman push, serta pengujian lintas perangkat. Di situlah web engineer yang bekerja sendirian kehilangan waktu yang tadinya seolah dihemat oleh sintaks yang familier, sehingga memadukan kefasihan web dengan orang yang pernah merilis dan memelihara aplikasi mobile lebih dapat diandalkan daripada berharap frameworknya menutup jurang itu.
- Apakah kami butuh engineer iOS dan Android yang terpisah?
- Jika Anda membangun secara native, umumnya ya â toolchain, bahasa, konvensi, dan proses rilisnya cukup berbeda sehingga kedalaman yang sungguhan di keduanya tidak umum ditemukan. Jika Anda membangun di atas codebase bersama, satu engineer bisa menutupi keduanya, asalkan ada yang memahami masing-masing platform cukup dalam untuk menangani kasus yang tidak dicakup framework. Bagaimanapun juga, perlakukan kedua platform sebagai hal yang menuntut pengujian dan perhatian rilis terpisah, alih-alih mengandaikan keduanya setara hanya karena kodenya dibagi.
- Bagaimana review app store memengaruhi perencanaan pengiriman?
- Ia menyisipkan jeda yang panjangnya berubah-ubah antara selesainya sebuah perubahan dan sampainya ke pengguna, dan jeda itu di luar kendali Anda. Tim yang merencanakannya merilis dengan ritme yang bisa diperkirakan, menyimpan satu versi di dalam antrean review sementara versi berikutnya dibangun, dan memakai remote configuration atau saklar di sisi server agar perilaku bisa disesuaikan tanpa submission lagi. Tim yang mengabaikannya baru menemukan batasan ini di tengah insiden, yaitu saat terburuk untuk mempelajarinya.
- Apakah aplikasi mobile membutuhkan pekerjaan backend tersendiri?
- Hampir selalu, dan biasanya lebih banyak daripada yang diperkirakan. Klien tidak bisa diperbarui sesuka kita, sehingga API harus berversi dan toleran terhadap pemanggil lama; notifikasi menuntut layanan yang menyimpan token dan menangani pengirimannya; sinkronisasi offline menuntut endpoint yang dirancang untuk rekonsiliasi, bukan sekadar baca dan tulis biasa. Seorang mobile engineer akan punya pendapat tentang semua itu dan sering bisa mengimplementasikannya, tetapi itu tetap pekerjaan sisi server dan sebaiknya direncanakan sebagai pekerjaan sisi server.
- Bagaimana sebaiknya kami mengukur sehat atau tidaknya sebuah aplikasi mobile?
- Sesi bebas crash, waktu cold start pada perangkat yang mewakili pengguna, tingkat adopsi versi terbaru, dan proporsi pengguna yang memberikan izin notifikasi maupun permission lain. Rating store adalah sinyal yang tertinggal dan berisik, berguna untuk arah alih-alih untuk diagnosis. Ukuran yang paling sering terlewat adalah adopsi versi, karena ia menentukan berapa lama sebuah cacat bertahan di lapangan dan seberapa cepat klien lama bisa dipensiunkan dengan aman.
- Bagaimana mobile developer bekerja bersama tim engineering yang sudah ada?
- Mereka bekerja mengikuti arahan Anda: roadmap Anda, keputusan platform Anda, proses review Anda, dan jadwal rilis Anda. Kepemilikan teknis tidak berpindah, dan penambahan kapasitas tim engineering bukanlah model penyerahan pengerjaan kepada pihak lain. Yang dipegang Talent.ID adalah hubungan kerja: payroll, benefit karyawan, administrasi talenta, dan hubungan karyawan yang berkelanjutan.
Ceritakan kebutuhan tim Anda
Jelaskan kekurangannya â pekerjaannya, stack-nya, cara tim Anda berjalan â dan kami akan menyampaikan apa yang dapat kami dukung. Bila bukan sesuatu yang bisa kami bantu, kami akan mengatakannya.