Firebase Bermasalah, Aplikasi iPhone Ikut Tertutup

Selasa pagi, 29 September 2026, pukul 07.41 sampai 09.52 WIB, aplikasi iOS yang memakai Google Analytics for Firebase tertutup paksa saat dibuka. Pemicunya satu pengaturan yang dihapus Google di servernya sendiri. Kode aplikasinya tidak salah apa-apa. Kode vendor yang ditanam di aplikasi ikut menentukan nasib aplikasi itu, jadi Anda perlu tombol pemati dan tanda bahaya milik sendiri.

Di bawah ini saya uraikan isi laporan Google, kenapa alat penghitung pengunjung bisa menutup halaman pembayaran, dan apa yang perlu dicek pada aplikasi bisnis Anda.

Apa yang terjadi pada 28–29 September?

Google menerbitkan laporan pasca-insiden di blog Firebase pada 2 Oktober 2026. Laporan itu memakai waktu Pasifik, jadi di sana kejadiannya Senin malam 28 September. Dalam WIB urutannya begini:

Bagi pengguna di Indonesia, ini jam berangkat kerja. Orang membuka aplikasi bank, ojek daring, belanja, atau hotel. Konfigurasi rusak itu beredar 2 jam 11 menit.

Kesalahannya kecil sekali. Google menghapus satu pengaturan lewat perubahan dua baris, tetapi kode analitik di dalam aplikasi iOS masih mencarinya. Begitu kode itu menerima konfigurasi tanpa pengaturan itu, ia mencoba menyimpan data dengan label kosong, dan iOS menutup seluruh aplikasi.

Pesan error-nya tercatat di laporan masalah yang dibuka para pengembang di GitHub: key cannot be nil. Artinya kira-kira "tidak bisa menyimpan berkas di map tanpa nama". Seorang pengembang menghitung 56 crash dari 56 pengguna dalam 18 menit pertama. Pengembang lain melaporkan total sekitar 20.000 dan 110.000 kejadian.

Ada dua catatan dari laporan Google yang membantu menakar skalanya. Setiap pengguna aktif hanya mengalami satu kali tertutup paksa, lalu kode itu kembali memakai konfigurasi sebelumnya. Google tidak menemukan perangkat yang terjebak tertutup terus-menerus. Catatan kedua kurang enak didengar: pengujian yang sudah ada di Google lolos semua untuk perubahan itu.

Kenapa alat analitik bisa menutup halaman pembayaran?

Paket kode siap pakai dari vendor yang ditanam di aplikasi disebut SDK (software development kit). SDK tidak berjalan sebagai program terpisah. Ia hidup di dalam aplikasi Anda, memakai memori yang sama, dan ikut mati kalau ia bermasalah.

Bayangkan menyewakan satu kamar di rumah Anda. Kalau kompor penyewa terbakar, yang hangus bukan cuma kamarnya. Seisi rumah ikut.

Paket analitik yang tugasnya hanya menghitung halaman yang dibuka berbagi nyawa dengan halaman pembayaran, formulir pemesanan, dan login. Saat paket itu jatuh, iOS menutup semuanya. Pengguna tidak peduli vendor mana yang salah. Yang mereka lihat hanya logo Anda, lalu layar utama ponsel.

Bagian yang lebih mengganggu: Firebase memakai pengaturan di server ini sebagai tombol pemati jarak jauh (kill switch). Gunanya mematikan fitur yang bermasalah tanpa menunggu rilis aplikasi baru. Kali ini justru alat pengamannya yang memicu masalah.

Artinya, vendor yang bisa mengubah perilaku kodenya dari jauh juga bisa mengubah perilaku aplikasi Anda. Kapan saja, tanpa lewat pengujian tim Anda dan tanpa lewat peninjauan App Store.

Pola ini sudah pernah terjadi. Pada 10 Juli 2020, respons server yang salah ke SDK Facebook untuk iOS membuat Spotify, Pinterest, dan aplikasi besar lain tertutup saat dibuka, seperti dilaporkan 9to5Mac. Kejadian serupa sudah terjadi dua bulan sebelumnya, Mei 2020. Polanya sama: server vendor mengirim data yang tidak diduga kode di dalam aplikasi, dan aplikasi milik orang lain yang tumbang.

Kenapa halaman status tetap hijau?

Selama insiden, halaman status Firebase dan Google Ads tetap hijau. Penjelasan Google: halaman itu membaca kesehatan server, dan servernya memang sehat. Setiap permintaan dijawab cepat. Masalahnya, jawaban itu membuat aplikasi penerimanya tertutup.

Kabar publik pertama datang dari pengembang di GitHub, bukan dari halaman status Google. Halaman status mengukur server vendor. Tidak ada satu pun indikator di sana yang mengukur apakah aplikasi Anda bisa dibuka.

Laporan crash juga datang terlambat. iOS menyimpan laporan crash di ponsel dan baru mengirimnya saat pengguna membuka aplikasi lagi. Karena itu, seperti dicatat Google, pengembang masih melihat crash berjam-jam setelah perbaikan selesai.

Tim yang kebetulan merilis pembaruan minggu itu mudah menyimpulkan "rilis kita yang rusak". Kesimpulan itu keliru, dan sering berujung pada penarikan rilis yang sebenarnya tidak perlu.

Bagaimana membedakan kesalahan Anda dan kesalahan vendor?

Tiga pertanyaan ini biasanya cukup untuk memilah dalam 15 menit:

Masukkan tiga pertanyaan ini ke panduan langkah demi langkah saat insiden (runbook) yang dipegang petugas jaga. Tanpa itu, satu jam pertama habis untuk membongkar kode sendiri.

Apa yang perlu disiapkan?

1. Ketahui kode vendor apa saja yang ada di aplikasi

Catat setiap SDK di tiap aplikasi: gunanya apa, siapa yang memutuskan ia tetap dipakai, dan apakah ia menghubungi server vendor saat aplikasi dibuka. Biasanya isinya analitik, pelaporan crash, iklan, widget obrolan, dan SDK pembayaran. Paket yang tidak bisa dijelaskan alasannya hanya menambah risiko. Lebih baik dibuang.

2. Siapkan tombol pemati sendiri, dicek sebelum kode vendor jalan

Saat dibuka, aplikasi membaca berkas pengaturan kecil dari server Anda sendiri, lalu menyimpannya di ponsel, sebelum menyalakan SDK yang tidak wajib. Kalau suatu paket vendor mulai membuat aplikasi tertutup, Anda cukup mengubah satu nilai. Saat aplikasi dibuka berikutnya, paket itu tidak dinyalakan. Tidak perlu menunggu peninjauan App Store atau menunggu vendor membereskan masalahnya.

Agar tombol ini bisa diandalkan, pegang dua aturan. Simpan pengaturannya di infrastruktur yang terpisah dari vendor yang dikendalikannya. Lalu, kalau pengaturan hilang atau rusak, aplikasi harus memakai nilai terakhir yang diketahui benar. Tanpa aturan kedua, Anda hanya memindahkan kesalahan Google ke kode Anda sendiri.

3. Pantau crash dari sisi Anda, bukan dari sisi vendor

Pasang peringatan pada persentase sesi bebas crash, yaitu porsi sesi pemakaian aplikasi yang selesai tanpa tertutup paksa. Atur ambangnya supaya ada orang yang dihubungi dalam hitungan menit.

Pasangkan dengan satu sinyal dari server Anda sendiri: jumlah aplikasi dibuka dan jumlah login yang masuk ke API per menit. Kalau jumlah pembukaan aplikasi melonjak sementara login yang berhasil anjlok, pengguna sedang mencoba berulang kali dan gagal. Cara menentukan ambang dan mengarahkan peringatan saya bahas di pemantauan dan peringatan untuk sistem kecil.

4. Ikuti kabar vendor di tempat mereka benar-benar bicara

Pantau repositori GitHub dan catatan rilis SDK yang Anda pakai. Di insiden ini, kabar paling cepat beredar di GitHub, sementara halaman status diam. Google sudah merilis penguatan di Firebase iOS SDK 13.0.0, dan menyebut pembaruan GoogleUtilities 8.1.4 membuat SDK lebih tahan terhadap data server yang rusak. Jadwalkan pembaruannya seperti perubahan lain: uji dulu, baru rilis.

Apakah ini berlaku juga untuk sistem yang Anda kelola sendiri?

Ya, dan justru ini pelajaran yang paling berharga. Kalau Anda mengirim pengaturan dari server ke perangkat milik sendiri, misalnya kios, layar signage, Android TV box, atau gateway IoT, posisi Anda sama dengan Google di cerita ini. Setiap pengaturan yang diubah di server sampai ke semua perangkat sekaligus, tanpa melalui pengujian rilis yang biasa.

Komitmen perbaikan Google setelah insiden ini layak dijadikan daftar periksa:

• Periksa di perangkat. Pengaturan yang hilang atau rusak diabaikan, dan perangkat tetap memakai nilai terakhir yang benar. Data server yang salah tidak boleh membuat perangkat mogok.
• Sebar bertahap. Kirim perubahan ke sebagian kecil perangkat dulu, amati, baru perluas. Kalau ada yang rusak, yang kena hanya beberapa layar.
• Cek siapa yang masih membaca sebelum menghapus. Pengaturan baru boleh dihapus setelah dipastikan tidak ada perangkat terpasang yang masih memakainya.
• Pantau perangkatnya, bukan hanya servernya. Server yang menjawab cepat sementara semua perangkat tertutup tidak bisa disebut sehat.

Cara mengirim pembaruan bertahap ke layar di lapangan saya bahas di mengelola banyak Android TV box.

Yang perlu dicek minggu ini

• Daftar semua SDK vendor di tiap aplikasi, lengkap dengan penanggung jawab dan alasan dipakai.
• Cek apakah aplikasi iOS Anda memakai Firebase Analytics, lalu rencanakan pembaruan ke Firebase 13.0.0 atau lebih baru lewat pengujian biasa.
• Pastikan ada peringatan crash yang benar-benar membangunkan orang, bukan sekadar grafik di dashboard.
• Tambahkan tombol pemati untuk SDK yang tidak wajib, disimpan di infrastruktur sendiri.
• Kalau Anda mengirim pengaturan ke perangkat, pastikan perangkat tetap jalan saat menerima nilai yang hilang atau rusak.

Setiap paket vendor menghemat waktu pengembangan, tetapi juga menambah ketergantungan yang tidak bisa dilepas saat aplikasi berjalan. Jaga daftarnya tetap pendek, siapkan tombol pemati, dan ukur dari tempat pengguna Anda berada.