Panduan Sinkronisasi Rilis API dan Aplikasi Mobile

Setiap developer mobile pasti pernah mengalaminya. Tim backend mengumumkan, “API sudah live di production!” Sementara itu, tim mobile menatap layar dengan cemas: “Status: Waiting for Review” di App Store Connect dan “In review” di Google Play Console. Hal ini dapat menyebabkan aplikasi crash, fitur yang rusak, dan pengguna yang kecewa.

Artikel ini memberikan panduan untuk menyinkronkan rilis API dan aplikasi mobile secara aman. Kita akan membahas dasar-dasar versioning, feature flag, serta strategi rilis dan penanggulangan masalah yang penting untuk berbagai jenis konfigurasi backend.

Table of Contents

Versioning

Semantic Versioning (SemVer) untuk Aplikasi : Gunakan format MAJOR.MINOR.PATCH (contoh: 2.1.1).

MAJOR: Untuk perubahan yang bersifat breaking (tidak kompatible).
MINOR: Untuk fitur baru yang backward-compatible.
PATCH: Untuk perbaikan bug yang backward-compatible.

API Versioning: API harus memiliki strategi versioning yang jelas. Kita bisa tempatkan versinya di path URL (misalnya, /v1, /v2) atau dengan cara lain sesuai kebutuhan.Ini akan menentukan skenario rilis yang dipakai.

Backend Backward Compatibility

Sebisa mungkin, buatlah API baru agar tetap mendukung aplikasi versi lama. Untuk perubahan MINOR, seperti field baru sebagai opsional, bukan wajib (mandatory). Hal ini memungkinkan backend untuk merilis fitur baru tanpa merusak aplikasi versi lama, sehingga rilis untuk pembaruan yang non-kritikal menjadi tidak saling bergantung.

Mekanisme Konfigurasi Terpusat

Ini adalah ‘remote control‘ untuk aplikasi kita. Kita bisa menyimpannya di Firebase Remote Config atau membuat satu endpoint khusus tanpa versi yang dipanggil aplikasi saat pertama kali dijalankan.

GET | https://api.domain.com/config

Minimal, endpoint ini mengembalikan informasi versi yang diperlukan dan bisa juga menyertakan feature flag.

{
  "android": {
    "latest_version": "2.1.1",
    "minimum_version": "2.1.0"
  },
  "ios": {
    "latest_version": "2.1.1",
    "minimum_version": "2.1.0"
  },
  "maintenance_mode": false,
  "feature_flags": {
    “enable_new_registration_flow": true,
    "show_revamped_banner": false
  }
}

Di dalam aplikasi kita (misalnya, di splash screen), panggil config ini, dapatkan versi aplikasi saat ini, lalu bandingkan. Jika currentVersion < minimum_version, Maka aplikasi harus manampilkan dialog wajib update (force update).

Kontrol Aplikasi dengan Feature Flag

Firebase Remote Config (atau endpoint /config) mengontrol feature flag yang berfungsi sebagai ’switch‘ jarak jauh untuk fungsi – fungsi di dalam aplikasi. Ini adalah alat penting untuk mitigasi risiko.

Studi Kasus: Kill Switch Apakah flow registrasi baru ternyata memiliki bug? Cukup atur enable_new_registration_flow menjadi false di config kita. Fitur tersebut akan langsung hilang untuk semua pengguna di versi aplikasi baru, tanpa perlu menunggu review ulang di store.

final useNewRegistrationFlow = featureFlags['enable_new_registration_flow'] ?? false;

if (useNewRegistrationFlow) {
  NewRegistrationPage();
} else {
  OldRegistrationPage();
}

Skenario Rilis untuk Perubahan yang Bersifat Breaking

Di sinilah strategi menjadi sangat penting. Pendekatan yang tepat bergantung pada apakah API kita memiliki beberapa versi yang dapat berjalan secara bersamaan.

Skenario A: API dengan Versi

Ini adalah metode yang paling aman. Backend kita mendukung beberapa versi API yang berjalan bersamaan (misalnya, api/v1/profile dan api/v2/profile).

Persiapan: Tim backend merilis API v2 sambil memastikan agar v1 tetap beroperasi. Aplikasi Flutter 2.0.0 dibuat untuk menggunakan v2.
Rilis & Tunggu: Kirim aplikasi 2.0.0 ke store dan tunggu proses review selesai. Selama waktu ini, aplikasi versi lama terus menggunakan v1 tanpa masalah.
Lakukan Sinkronisasi: Setelah versi 2.0.0 sudah live di kedua store, perbarui Firebase Remote Config atau endpoint /config untuk mengatur “minimum_version”: “2.0.0”.
Hasil: Kita memaksa aplikasi lama untuk melakukan pembaruan. Aplikasi baru menggunakan v2. Kita bisa dengan aman menonaktifkan v1 beberapa minggu kemudian.

Skenario B: API tanpa Versi

Ini adalah skenario yang lebih berisiko karena memerlukan koordinasi ketat, yaitu ketika API kita tidak memiliki versi (misalnya, endpoint api/profile itu sendiri yang dimodifikasi dengan perubahan breaking). Merilis backend akan langsung merusak semua aplikasi versi lama. Urutannya harus sangat diperhatikan.

Persiapan & Code Freeze:
- Kode backend yang baru sudah selesai, sudah ditest, dan belum dirilis (deploy).
- Kita buat aplikasi Flutter baru (2.0.0) yang disesuaikan dengan perubahan backend yang akan datang.
Kirim Aplikasi: Kirim aplikasi 2.0.0 ke Play Store dan App Store. untuk direview. Pastikan juga untuk merilisnya ke penguji internal kita melalui TestFlight dan jalur pengujian internal Google Play.
Pastikan Menggunakan Publikasi Manual. Untuk skenario ini, kita harus mengonfigurasi rilis kita untuk publikasi manual, bukan otomatis.
- Mengapa? Publikasi otomatis akan langsung merilis aplikasi ke publik begitu lolos proses review. Hal ini bisa saja terjadi pada jam 3 pagi di hari Minggu, jauh sebelum tim backend kita siap untuk merilis API baru. Ini akan langsung merusak aplikasi yang sudah live untuk semua pengguna.
- Publikasi manual berarti setelah aplikasi disetujui, aplikasi akan menunggu kita menekan tombol “Rilis”. Ini memberikan kendali penuh atas waktu rilis, yang sangat penting untuk rilis yang terkoordinasi.
- Di Google Play Console, fitur ini dikenal sebagai “Managed publishing.” Di App Store Connect, kita bisa melakukannya dengan memilih untuk merilis versi secara manual setelah disetujui.
Tunggu Proses Review: Tunggu hingga aplikasi disetujui dan siap untuk dipublish di kedua store. Selama periode ini, aplikasi lama (1.x.x) masih berkomunikasi dengan API yang lama.
Ekseskusi:
- Langkah 4a: Mulai Transisi. Perbarui config untuk memulai transisi. Jika aplikasi kita memiliki maintenance mode, ubah “maintenance_mode” menjadi true. Jika tidak, ubah “minimum_version” menjadi “2.0.0”. Langkah ini akan langsung memunculkan halaman maintenance atau wajib update bagi semua pengguna di versi aplikasi lama, mencegah mereka melakukan panggilan API.
- Langkah 4b: Rilis Backend. Segera setelah config diperbarui, rilis kode backend baru yang berisi perubahan breaking.
- Langkah 4c: Verifikasi Internal. Uji versi aplikasi baru dengan tim internal kita menggunakan TestFlight atau pengujian internal Google Play. Aplikasi sekarang akan berinteraksi dengan backend yang baru saja dirilis.
  - Jika pengujian berhasil dan semuanya berjalan sesuai harapan, lanjutkan ke langkah berikutnya.
  - Jika pengujian gagal, kembalikan (roll back) backend ke versi sebelumnya (1.x.x), pulihkan config ke minimum_version yang lama, dan ulangi proses dari awal setelah bug diperbaiki.
- Langkah 4d: Publikasikan Aplikasi. Setelah pengujian internal berhasil, publikasikan versi aplikasi baru di App Store dan Play Store untuk semua pengguna.
- Langkah 4e: Matikan Maintenance Mode (jika ada). Setelah backend sepenuhnya dirilis, stabil, dan pengguna mulai memperbarui aplikasi, kita bisa mengatur “maintenance_mode”: false di /config kita.
Hasil: Kita meminimalkan jeda waktu terjadinya ketidakcocokan hanya dalam hitungan menit. Wajib update memblokir pengguna lama, memaksa mereka mengunduh versi 2.0.0. Pengguna baru mengunduh versi 2.0.0 dan berinteraksi dengan backend yang baru dirilis.

**Penanggulangan Masalah (Damage Control)**

Kita tidak bisa menarik kembali (rollback) aplikasi yang sudah terpasang di perangkat pengguna. Kita harus punya rencana penanggulangan masalah yang bisa dieksekusi secara bertahap sesuai tingkat masalah.

Gunakan Feature Flag

Masalah: Sebuah fitur dalam rilis baru ternyata bermasalah, tetapi sisa aplikasi lainnya stabil.
Tindakan: Gunakan feature flag di dalam config untuk menonaktifkan fitur yang bermasalah dari jarak jauh.
Hasil: Perbaikan instan. Krisis dapat dihindari tanpa adanya downtime sama sekali.

Hotfix

Masalah: Bug memerlukan perubahan kode di aplikasi tetapi bukan crash yang fatal.
Tindakan: Perbaiki menjadi hotfix (2.0.1), kirim untuk ditinjau, lalu rilis.

**Penghentian Darurat (Maintenance Mode)**

Bayangkan skenario terburuk: kita telah merilis versi baru menggunakan API tanpa versi, dan sebuah bug critical menyebabkan aplikasi crash saat dibuka. Hotfix sudah dikirim, tetapi masih terjebak dalam antrean review. Pengguna terjebak dalam crash loop (aplikasi crash berulang kali), menciptakan pengalaman pengguna yang sangat buruk. Di sinilah maintenance_mode menjadi penting.

Tindakan: Daripada membiarkan pengguna menderita, kita perbarui endpoint/config dari jarak jauh dan atur “maintenance_mode”: true.
Hasil: Saat pengguna membuka aplikasi, Aplikasi akan melihat flag ini dan akan segera menampilkan halaman maintenance seperti (“Kami sedang melakukan pemeliharaan penting dan akan segera kembali.”).
Hasil: Kita berhasil mengubah bencana yang tak terkendali menjadi sebuah downtime yang terkontrol. Crash berhenti untuk semua orang. Ini memberikan waktu berharga bagi tim dan melindungi reputasi brand kita selagi menunggu hotfix disetujui. Setelah merilis versi yang sudah diperbaiki, kembalikan flag ke false agar aplikasi kembali beroperasi normal.

Kesimpulan

Untuk melakukan sinkronisasi API dan aplikasi mobile yang aman, terapkan strategi versioning, jaga backward compatibility, dan manfaatkan layanan konfigurasi jarak jauh yang fleksibel untuk wajib update, feature flag, dan maintenance mode. Lengkapi semua itu dengan skenario rilis yang terdefinisi dengan baik untuk API yang memiliki versi maupun yang tidak, serta proses penanggulangan masalah yang tangguh. Dengan begitu, setiap proses deployment akan menjadi sebuah agenda yang dapat diprediksi dan berisiko rendah.

Sebagai informasi, LOGIQUE menyediakan jasa pembuatan aplikasi mobile yang terintegrasi secara optimal dengan sistem backend. Perusahaan di Indonesia yang membutuhkan dukungan dalam pengembangan aplikasi dapat menghubungi tim kami untuk mendapatkan solusi yang tepat.