Deep link untuk aplikasi mobile native: rute, token, buka di aplikasi

Apa yang harus dilakukan deep link, dalam kata-kata sederhana

Ketika seseorang mengetuk tautan di ponsel, mereka mengharapkan satu hasil: membawa mereka ke tempat yang benar, segera. Bukan ke tempat yang mirip. Bukan ke layar beranda dengan bilah pencarian. Bukan ke layar login yang lupa alasan mereka datang.

Pengalaman deep link yang baik terlihat seperti ini:

• Jika aplikasi terpasang, aplikasi membuka layar yang tepat seperti yang disiratkan tautan.
• Jika aplikasi tidak terpasang, ketukan tetap membantu (misalnya membuka fallback web atau halaman toko aplikasi dan bisa mengembalikan orang ke tujuan yang sama setelah instalasi).
• Jika pengguna harus login, mereka login sekali dan mendarat di layar yang dimaksud, bukan mulai dari awal aplikasi.
• Jika tautan membawa aksi (terima undangan, lihat pesanan, konfirmasi email), aksinya jelas dan aman.

Sebagian besar frustrasi datang dari tautan yang “agak bekerja” tapi merusak alur. Orang melihat layar yang salah, kehilangan apa yang sedang mereka lakukan, atau terjebak dalam loop: ketuk tautan, login, mendarat di dashboard, ketuk tautan lagi, login lagi. Bahkan satu langkah ekstra bisa membuat pengguna menyerah, terutama untuk aksi sekali pakai seperti undangan atau reset kata sandi.

Sebelum Anda menulis kode Kotlin atau SwiftUI, putuskan apa arti tautan bagi pengalaman Anda. Layar mana yang boleh dibuka dari luar? Apa yang berubah jika aplikasi tertutup vs sudah berjalan? Apa yang harus terjadi saat pengguna belum login?

Perencanaan itulah yang mencegah sebagian besar masalah nanti: rute yang jelas, perilaku “buka di aplikasi” yang dapat diprediksi, dan cara aman menyerahkan kode sekali-pakai tanpa menaruh rahasia langsung di URL.

Jenis deep link dan di mana “buka di aplikasi” sering salah

Tidak setiap “tautan yang membuka aplikasi” berperilaku sama. Menganggapnya bisa saling dipertukarkan akan menyebabkan kegagalan klasik: tautan membuka tempat yang salah, membuka browser alih-alih aplikasi, atau hanya bekerja di satu platform.

Tiga kelompok umum:

• Custom schemes (misalnya skema khusus aplikasi seperti myapp:). Mudah diatur, tetapi banyak aplikasi dan browser memperlakukannya hati-hati.
• Universal Links (iOS) dan App Links (Android). Ini menggunakan tautan web normal dan bisa membuka aplikasi saat terpasang, atau fallback ke situs web saat tidak terpasang.
• Tautan di browser dalam aplikasi. Tautan yang dibuka di dalam aplikasi email atau browser bawaan messenger. Mereka sering berperilaku berbeda dari Safari atau Chrome.

“Buka di aplikasi” bisa berarti hal berbeda tergantung di mana ketukan terjadi. Tautan yang diketuk di Safari mungkin langsung lompat ke aplikasi. Tautan yang sama diketuk di dalam email atau messenger mungkin membuka web view tersemat dulu, dan orang harus menekan tombol “buka” tambahan (atau tidak pernah melihatnya). Pada Android, Chrome mungkin menghormati App Links sementara browser dalam aplikasi sosial mungkin mengabaikannya.

Cold start vs aplikasi sudah berjalan adalah jebakan berikutnya.

• Cold start: OS meluncurkan aplikasi Anda, aplikasi menginisialisasi, dan hanya kemudian Anda menerima deep link. Jika alur startup menampilkan splash screen, memeriksa autentikasi, atau memuat konfigurasi jarak jauh, tautan bisa hilang kecuali Anda menyimpannya dan memutarnya kembali setelah aplikasi siap.
• Sudah berjalan: Anda menerima tautan saat pengguna sedang berinteraksi. Stack navigasi sudah ada, jadi tujuan yang sama mungkin perlu penanganan berbeda (push layar vs reset stack).

Contoh sederhana: tautan undangan yang diketuk dari Telegram sering kali membuka di browser dalam aplikasi dulu. Jika aplikasi Anda mengira OS akan selalu meneruskan langsung, pengguna akan melihat halaman web dan mengira tautan rusak. Rencanakan untuk lingkungan ini sejak awal dan Anda akan menulis lebih sedikit glue code spesifik platform nanti.

Rencanakan rute Anda sebelum mengimplementasikan apapun

Sebagian besar bug deep link bukan masalah Kotlin atau SwiftUI. Mereka masalah perencanaan. Tautan tidak memetakan dengan rapi ke satu layar, atau membawa terlalu banyak opsi “mungkin”.

Mulailah dengan satu pola rute konsisten yang cocok dengan cara orang berpikir tentang aplikasi Anda: daftar, detail, pengaturan, checkout, undangan. Jaga agar mudah dibaca dan stabil, karena Anda akan menggunakannya lagi di email, kode QR, dan halaman web.

Satu set rute sederhana bisa mencakup:

• Beranda
• Daftar pesanan dan detail pesanan (orderId)
• Pengaturan akun
• Penerimaan undangan (inviteId)
• Pencarian (query, tab)

Lalu definisikan parameter Anda:

• Gunakan ID untuk objek tunggal (orderId).
• Gunakan parameter opsional untuk status UI (tab, filter).
• Tentukan default sehingga setiap tautan memiliki satu tujuan terbaik.

Putuskan juga apa yang terjadi saat tautan salah: data hilang, ID tidak valid, atau konten yang tidak bisa diakses pengguna. Default paling aman adalah membuka layar stabil terdekat (seperti daftar) dan menampilkan pesan singkat. Hindari menumpahkan orang ke layar kosong atau layar login tanpa konteks.

Akhirnya, rencanakan berdasarkan sumber. Kode QR biasanya butuh rute singkat yang cepat dibuka dan toleran terhadap konektivitas buruk. Tautan email bisa lebih panjang dan menyertakan konteks ekstra. Tautan halaman web harus menurun secara anggun: jika aplikasi tidak terpasang, orang masih mendarat di tempat yang menjelaskan apa yang harus dilakukan selanjutnya.

Jika Anda menggunakan pendekatan yang digerakkan backend (misalnya menghasilkan endpoint API dan layar dengan platform seperti AppMaster), rencana rute ini menjadi kontrak bersama: aplikasi tahu ke mana harus pergi, dan backend tahu ID dan status mana yang valid.

Penyerahan token yang aman tanpa menaruh rahasia di URL

Deep link sering diperlakukan seperti amplop aman. Sebenarnya tidak. Apa pun dalam URL bisa berakhir di riwayat browser, screenshot, preview yang dibagikan, log analitik, atau disalin ke chat.

Hindari menaruh rahasia di tautan. Itu termasuk token akses jangka panjang, refresh token, kata sandi, data pribadi, atau apa pun yang memungkinkan seseorang bertindak sebagai pengguna jika tautan diteruskan.

Pola yang lebih aman adalah kode sekali-pakai berumur pendek. Tautan hanya membawa kode itu, dan aplikasi menukarnya dengan sesi nyata setelah terbuka. Jika seseorang mencuri tautan, kodenya harus tidak berguna setelah satu atau dua menit, atau setelah penukaran pertama.

Alur penyerahan sederhana:

• Tautan berisi kode sekali-pakai, bukan token sesi.
• Aplikasi membuka dan memanggil backend untuk menukarkan kode.
• Backend memvalidasi masa berlaku, memeriksa apakah sudah digunakan, lalu menandainya sebagai sudah dipakai.
• Backend mengembalikan sesi terautentikasi normal untuk aplikasi.
• Aplikasi menghapus kode dari memori setelah ditukarkan.

Bahkan setelah penukaran berhasil, konfirmasi identitas di dalam aplikasi sebelum melakukan sesuatu yang sensitif. Jika tautan dimaksudkan untuk menyetujui pembayaran, mengubah email, atau mengekspor data, minta pengecekan cepat seperti biometrik atau login ulang.

Simpan sesi yang dihasilkan dengan aman. Di iOS, itu biasanya berarti Keychain. Di Android, gunakan penyimpanan yang didukung Keystore. Simpan hanya yang Anda butuhkan, dan bersihkan saat logout, penghapusan akun, atau saat mendeteksi penggunaan mencurigakan.

Contoh konkret: Anda mengirim tautan undangan untuk bergabung ke workspace. Tautan membawa kode sekali-pakai yang kedaluwarsa dalam 10 menit. Aplikasi menukarnya, lalu menampilkan layar yang jelas menjelaskan apa yang akan terjadi berikutnya (bergabung ke workspace mana). Hanya setelah pengguna mengonfirmasi, aplikasi menyelesaikan proses bergabung.

Jika Anda membangun dengan AppMaster, ini cocok dengan endpoint yang menukarkan kode dan mengembalikan sesi, sementara UI mobile menangani langkah konfirmasi sebelum aksi berdampak besar.

Autentikasi dan “lanjutkan dari tempat Anda berhenti”

Deep link sering mengarah ke layar yang berisi data pribadi. Mulailah dengan memutuskan apa yang bisa dibuka siapa saja (publik) dan apa yang memerlukan sesi login (terlindungi). Keputusan ini mencegah sebagian besar kejutan "berhasil di pengujian".

Aturan sederhana: buka ke status landing yang aman terlebih dahulu, lalu navigasikan ke layar terlindungi hanya setelah Anda memastikan pengguna terautentikasi.

Tentukan apa yang publik vs terlindungi

Perlakukan deep link seolah-olah bisa diteruskan ke orang yang salah.

• Publik: halaman pemasaran, artikel bantuan, awal reset kata sandi, awal penerimaan undangan (belum menampilkan data)
• Terlindungi: detail pesanan, pesan, pengaturan akun, layar admin
• Campuran: layar pratinjau boleh saja, tetapi tampilkan placeholder non-sensitif sampai login

“Lanjutkan setelah login” yang mengembalikan ke tempat yang benar

Pendekatan yang dapat diandalkan: parse tautan, simpan tujuan yang dimaksud, lalu rute berdasarkan status auth.

Contoh: pengguna mengetuk tautan “buka di aplikasi” ke tiket dukungan spesifik saat belum login. Aplikasi Anda harus membuka ke layar netral, meminta mereka masuk, lalu membawa mereka ke tiket itu secara otomatis.

Untuk menjaga keandalan, simpan “target kembali” kecil secara lokal (nama rute plus ID tiket) dengan masa berlaku pendek. Setelah login selesai, baca sekali, navigasikan, lalu hapus. Jika login gagal atau target kedaluwarsa, fallback ke layar beranda yang aman.

Tangani kasus tepi dengan hormat:

• Sesi kedaluwarsa: tampilkan pesan singkat, minta re-auth, lalu lanjutkan.
• Akses dicabut: buka kerangka tujuan, lalu tampilkan “Anda tidak lagi memiliki akses” dan tawarkan langkah aman berikutnya.

Juga hindari menampilkan data pribadi di preview layar kunci, screenshot penukar aplikasi, atau preview notifikasi. Biarkan layar sensitif kosong sampai data dimuat dan sesi terverifikasi.

Pendekatan routing yang menghindari spaghetti navigasi kustom

Deep link menjadi berantakan ketika setiap layar mem-parsing URL dengan caranya sendiri. Itu menyebarkan keputusan kecil (apa yang opsional, apa yang diperlukan, apa yang valid) ke seluruh aplikasi, dan menjadi sulit diubah dengan aman.

Perlakukan routing seperti pipa bersama. Simpan satu tabel rute dan satu parser, dan biarkan UI menerima input yang bersih.

Gunakan satu tabel rute bersama

Buat iOS dan Android setuju pada satu daftar rute yang mudah dibaca. Pikirkan sebagai kontrak.

Setiap rute memetakan ke:

1. sebuah layar, dan
2. model input kecil.

Contoh: “Detail Pesanan” memetakan ke layar Order dengan input seperti OrderRouteInput(id). Jika sebuah rute butuh nilai ekstra (seperti sumber ref), mereka berada di model input itu, bukan berserakan di kode view.

Pusatkan parsing dan validasi

Simpan parsing, decoding, dan validasi di satu tempat. UI tidak perlu bertanya “Apakah token ini ada?” atau “Apakah ID ini valid?” UI harus menerima input rute yang valid atau status error yang jelas.

Alur praktis:

• Terima URL (ketukan, scan, share sheet)
• Parse menjadi rute yang dikenal
• Validasi field yang diperlukan dan format yang diizinkan
• Hasilkan target layar plus model input
• Navigasikan melalui satu titik masuk

Tambahkan layar fallback “tautan tidak dikenal”. Buat berguna, bukan jalan buntu: tampilkan apa yang tidak bisa dibuka, jelaskan alasannya dengan bahasa sederhana, dan tawarkan aksi berikutnya seperti ke Beranda, mencari, atau masuk.

Langkah demi langkah: desain deep link dan perilaku “buka di aplikasi”

Deep link yang baik terasa membosankan dengan cara terbaik. Orang mengetuk dan mendarat di layar yang tepat, apakah aplikasi terpasang atau tidak.

Langkah 1: pilih titik masuk yang penting

List 10 tipe tautan pertama yang benar-benar dipakai orang: undangan, reset kata sandi, tanda terima pesanan, link “lihat tiket”, link promo. Jaga kecil dengan tujuan.

Langkah 2: tulis pola sebagai kontrak

Untuk setiap titik masuk, definisikan satu pola kanonis dan data minimum yang dibutuhkan untuk membuka layar yang tepat. Pilih ID yang stabil daripada nama. Tentukan apa yang wajib vs opsional.

Aturan membantu:

• Satu tujuan per rute (invite, reset, receipt).
• Parameter wajib selalu hadir; yang opsional punya default aman.
• Gunakan pola yang sama di iOS (SwiftUI) dan Android (Kotlin).
• Jika Anda mengantisipasi perubahan, sisakan versi sederhana (mis. v1).
• Definisikan apa yang terjadi saat parameter hilang (tampilkan layar error, bukan halaman kosong).

Langkah 3: putuskan perilaku login dan target pasca-login

Tuliskan, per tipe tautan, apakah login diperlukan. Jika ya, ingat tujuan dan lanjutkan setelah login.

Contoh: tautan tanda terima bisa menampilkan pratinjau tanpa login, tetapi mengetuk “Unduh faktur” mungkin memerlukan login dan harus mengembalikan pengguna ke tanda terima itu.

Langkah 4: tetapkan aturan penyerahan token (jangan taruh rahasia di URL)

Jika tautan membutuhkan token sekali-pakai (penerimaan undangan, reset, sign-in magis), tentukan berapa lama berlaku dan bagaimana dipakai.

Pendekatan praktis: URL membawa kode sekali-pakai singkat, dan aplikasi menukarkannya ke backend untuk sesi nyata.

Langkah 5: uji tiga keadaan nyata

Deep link rusak di tepi. Uji tiap tipe tautan dalam situasi ini:

• Cold start (aplikasi tertutup)
• Warm start (aplikasi masih di memori)
• Aplikasi tidak terpasang (tautan tetap menempatkan seseorang ke tempat yang masuk akal)

Jika Anda menjaga rute, pemeriksaan auth, dan aturan penukaran token di satu tempat, Anda menghindari menyebarkan logika routing kustom ke layar Kotlin dan SwiftUI.

Kesalahan umum yang merusak deep link (dan cara menghindarinya)

Deep link cenderung gagal karena alasan sederhana: asumsi kecil, layar yang diganti nama, atau token “sementara” yang tersebar ke mana-mana.

Kegagalan yang sering terlihat dan perbaikannya

• Meletakkan access token di URL (dan membocorkannya ke log). Query string disalin, dibagikan, tersimpan di riwayat browser, dan tertangkap oleh analitik serta log crash. Perbaikan: letakkan hanya kode sekali-pakai singkat di tautan, tukarkan di dalam aplikasi, dan kedaluwarsakan dengan cepat.

• Mengira aplikasi terpasang (tanpa fallback). Jika tautan membuka halaman error atau tidak melakukan apa-apa, pengguna menyerah. Perbaikan: sediakan halaman web fallback yang menjelaskan apa yang terjadi dan menawarkan jalur pemasangan. Bahkan halaman sederhana “Buka aplikasi untuk melanjutkan” lebih baik daripada diam.

• Tidak menangani beberapa akun di satu perangkat. Membuka layar yang benar untuk pengguna yang salah lebih buruk daripada tautan rusak. Perbaikan: ketika aplikasi menerima tautan, periksa akun yang aktif, minta pengguna konfirmasi atau ganti akun, lalu lanjutkan. Jika aksi membutuhkan workspace tertentu, sertakan pengenal workspace (bukan rahasia) dan validasi.

• Memecah tautan saat layar atau rute diubah. Jika rute terkait nama UI, tautan lama mati saat Anda ganti nama tab. Perbaikan: rancang rute yang stabil dan berbasis intent (invite, ticket, order) dan pertahankan dukungan versi lama.

• Tidak ada jejak saat terjadi kesalahan. Tanpa cara memutar ulang apa yang terjadi, dukungan hanya bisa menebak. Perbaikan: sertakan request ID non-sensitif di tautan, log di server dan di aplikasi, dan tampilkan pesan error yang menyertakan ID itu.

Cek realitas cepat: bayangkan tautan undangan dikirim di chat grup. Seseorang membukanya di ponsel kerja dengan dua akun, aplikasi tidak terpasang di tabletnya, dan tautan diteruskan ke kolega. Jika tautan hanya membawa kode undangan, mendukung fallback, meminta akun yang tepat, dan mencatat request ID, tautan itu bisa berhasil di semua situasi tanpa mengekspos rahasia.

Contoh: tautan undangan yang selalu membuka layar yang benar

Undangan adalah contoh klasik deep link: seseorang mengirim tautan ke rekan kerja di messenger, dan penerima mengharapkan satu ketukan untuk mendarat di layar undangan, bukan halaman beranda generik.

Skenario: seorang manajer mengundang agen dukungan baru untuk bergabung ke workspace “Support Team”. Agen mengetuk undangan di Telegram.

Jika aplikasi terpasang, sistem harus membuka aplikasi dan meneruskan detail undangan ke dalamnya. Jika aplikasi tidak terpasang, pengguna harus mendarat di halaman web sederhana yang menjelaskan tujuan undangan dan menawarkan jalur pemasangan. Setelah instal dan peluncuran pertama, aplikasi harus tetap bisa menyelesaikan alur undangan sehingga pengguna tidak harus mencari tautan lagi.

Di dalam aplikasi, alurnya sama di Kotlin dan SwiftUI:

• Baca kode undangan dari tautan masuk.
• Periksa apakah pengguna sudah login.
• Verifikasi undangan dengan backend Anda, lalu rute ke layar yang benar.

Verifikasi adalah inti. Tautan tidak boleh berisi rahasia seperti token sesi jangka panjang. Tautan harus membawa kode undangan sekali-pakai yang hanya berguna setelah server Anda memvalidasinya.

Pengalaman pengguna harus terasa dapat diprediksi:

• Belum login: mereka melihat layar login, lalu kembali ke penerimaan undangan setelah login.
• Sudah login: mereka melihat satu konfirmasi “Gabung workspace”, lalu mendarat di workspace yang benar.

Jika undangan sudah kedaluwarsa atau sudah dipakai, jangan buang pengguna ke halaman error kosong. Tampilkan pesan jelas dan langkah berikutnya: minta undangan baru, ganti akun, atau hubungi admin. “Undangan ini sudah diterima” lebih baik daripada “Token tidak valid.”

Daftar periksa cepat dan langkah berikutnya

Deep link terasa “beres” ketika berperilaku sama di mana pun: cold start, warm start, dan ketika pengguna sudah masuk.

Daftar periksa cepat

Sebelum Anda merilis, uji tiap item di perangkat nyata dan versi OS yang berbeda:

• Tautan membuka layar yang benar saat cold start dan warm start.
• Tidak ada data sensitif di URL. Jika harus melewatkan token, buat singkat dan sekali-pakai.
• Tautan yang tidak dikenal, kedaluwarsa, atau sudah dipakai fallback ke layar jelas dengan pesan dan aksi aman.
• Bekerja dari aplikasi email, browser, pemindai QR, dan preview messenger (beberapa akan membuka tautan lebih dahulu).
• Logging memberi tahu apa yang terjadi (tautan diterima, rute di-parse, auth diperlukan, alasan sukses atau gagal).

Cara sederhana memvalidasi: pilih beberapa tautan yang mutlak harus bekerja (undangan, reset kata sandi, detail pesanan, tiket dukungan, promo) dan jalankan alur uji yang sama: ketuk dari email, ketuk dari chat, scan QR, buka setelah reinstall.

Langkah berikutnya (agar mudah dipelihara)

Jika penanganan deep link mulai tersebar ke banyak layar, perlakukan routing dan auth sebagai pipa bersama, bukan kode per-layar. Pusatkan parsing rute di satu tempat, dan buat setiap tujuan menerima parameter bersih (bukan URL mentah). Lakukan hal yang sama untuk auth: satu gerbang yang memutuskan “lanjut sekarang” vs “login dulu, lalu lanjut.”

Jika Anda ingin mengurangi glue code kustom, membangun backend, auth, dan aplikasi mobile bersama-sama bisa membantu. AppMaster (appmaster.io) adalah platform no-code yang menghasilkan backend produksi-ready dan aplikasi native, yang dapat mempermudah menjaga nama rute dan endpoint penukaran kode sekali-pakai tetap selaras saat kebutuhan berubah.

Jika Anda melakukan satu hal minggu depan, lakukan ini: tuliskan rute kanonis Anda dan fallback eksak untuk setiap kasus kegagalan, lalu implementasikan aturan-aturan itu dalam satu lapisan routing.