- Apple secara otomatis menutup bug yang dilaporkan melalui Feedback Assistant jika pengguna tidak memverifikasi (verify) sendiri bahwa masalahnya “masih belum diperbaiki”
- Untuk bug kebocoran privasi terkait ekstensi filter jaringan (FB12088655) yang tidak mendapat respons selama 3 tahun, Apple tiba-tiba meminta verifikasi dan menganggap bug sudah diperbaiki jika tidak ada jawaban dalam 2 minggu
- Meskipun pengembang Little Snitch memastikan masalah yang sama masih ada bahkan di macOS terbaru, Apple tetap menutup laporannya
- Prosedur seperti ini bekerja sebagai struktur yang secara artifisial mengurangi jumlah laporan bug, sehingga menutupi masalah kualitas yang sebenarnya
- Akibatnya, cara Apple mengelola bug melemahkan kepercayaan pengembang dan dinilai merusak budaya umpan balik yang kolaboratif
Masalah penutupan otomatis laporan bug oleh Apple
- Seorang pengembang yang melaporkan bug melalui Apple Feedback Assistant mengkritik praktik Apple yang menutup laporan secara sepihak tanpa konfirmasi dari pelapor
- Apple secara otomatis menutup laporan jika pengguna tidak secara langsung mengonfirmasi bahwa “bug tersebut masih belum diperbaiki”
- Setelah tidak merespons selama bertahun-tahun, Apple tiba-tiba mengirim permintaan verifikasi dan menganggap statusnya “sudah diperbaiki” jika tidak ada tanggapan dalam 2 minggu
- Dalam kasus FB12088655 “Privacy: Network filter extension TCP connection and IP address leak” yang diajukan pada Maret 2023, setelah tidak ada respons selama 3 tahun, baru pada Maret 2026 Apple meminta verifikasi di macOS 26.4 beta 4
- Karena beta OS tidak selalu terpasang, verifikasi sulit dilakukan, dan meski sudah ditanyakan ke Apple apakah masalah benar-benar diperbaiki, tidak ada jawaban yang jelas
- Apple memberi tahu bahwa “jika tidak diverifikasi dalam 2 minggu, bug akan dianggap sudah diperbaiki dan laporan akan ditutup”
- Pengembang Little Snitch melaporkan bahwa masalah yang sama tetap bisa direproduksi di macOS 26.4 beta 4
- Bug yang sama ternyata masih ada juga di macOS 26.4 versi rilis
- Tindakan Apple yang meminta verifikasi langsung dari pengguna untuk bug yang belum diperbaiki dinilai sebagai prosedur yang tidak efisien dan tidak masuk akal
- Disebutkan adanya kemungkinan struktur insentif internal yang bekerja untuk mengurangi jumlah laporan bug
- Akibatnya, jumlah “bug terbuka” menurun sehingga pada metrik internal kualitas tampak seolah membaik
Contoh laporan bug lainnya
- Contoh lain yang disebut adalah bug FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tab”
- Meski masalah ini bisa direproduksi 100%, Apple menandainya sebagai “Investigation complete - Unable to diagnose with current information”
- Pada 9 Maret diminta informasi tambahan, tetapi Apple tidak memberikan respons
- Di iPadOS 26.4 beta, muncul bug baru berupa Safari crash, dan Apple tidak memperbaikinya sampai sebelum versi publik dirilis
- Penulis mengkritik bahwa “tujuan beta tampaknya bukan untuk memperbaiki bug, melainkan untuk membuat orang yang melaporkan bug menjadi repot”
Perubahan setelah masuk Hacker News dan respons Apple
- Tepat setelah tulisan ini naik ke halaman depan Hacker News, Apple memperbarui laporan FB22057274
- Apple meminta pengiriman log sysdiagnose untuk masalah UI
- Padahal langkah reproduksi dan rekaman layar sudah diberikan, dan sysdiagnose dinilai berisiko terhadap privasi serta tidak diperlukan
- Penulis menanggapi permintaan Apple sebagai berikut
- “Untuk bug UI, sysdiagnose tidak diperlukan dan tidak membantu”
- Dengan metode yang bisa direproduksi tanpa Little Snitch, penulis menunjukkan bahwa gejala yang sama dapat direproduksi dengan mengatur profil uplink delay 3000ms menggunakan Network Link Conditioner dari Xcode Additional Tools
Panduan Xcode Additional Tools
- Xcode Additional Tools berisi berbagai utilitas yang berguna, dan dapat diunduh dari halaman Apple Developer Downloads (perlu login)
Evaluasi keseluruhan
- Cara Apple mengelola laporan bug memberi beban yang tidak perlu kepada pengembang,
dan bekerja dengan struktur yang lebih berfokus pada pengurangan jumlah laporan daripada penyelesaian masalah nyata
- Karena laporan dibiarkan tanpa respons dalam jangka panjang, permintaan verifikasi yang tidak masuk akal, dan permintaan informasi yang tidak efisien,
kepercayaan pengembang dan kemauan untuk bekerja sama pun semakin melemah
1 komentar
Opini Hacker News
Penulisnya sepertinya belum pernah merasakan software enterprise
Saat developer menerima laporan bug, trik klasiknya adalah mengulur waktu dengan bilang, “tidak bisa direproduksi, sudah dicek di versi terbaru?” sambil tidak melakukan apa-apa
Kalau tetap tidak terkonfirmasi, mereka akan menutupnya sebagai “kesalahan pengguna” atau “tidak dapat direproduksi”
Satu-satunya cara menghadapi ini adalah menjawab “ya, sudah saya cek” padahal sebenarnya belum dicek
Kalau ada antivirus di log, mereka langsung menutupnya sambil bilang “silakan hubungi pihak sana”
Karena ada banyak prioritas bisnis yang dianggap lebih penting daripada bug yang dilaporkan satu pengguna
Meski begitu, dari sudut pandang pengguna ini tetap disayangkan
Kebanyakan developer tidak tahu cara menguji produk mereka sendiri atau malas melakukannya
Saat bekerja di dukungan teknis enterprise, saya harus menerima setidaknya dua kasus baru per hari dan menangani lebih dari 20 kasus sekaligus
Ada rasa lega besar saat menutup kasus yang tidak menunjukkan kemajuan sebagai “ditutup karena tidak aktif”
Belakangan muncul aturan harus menghubungi tiga kali sebelum menutup, dan itu jadi mimpi buruk
Pada akhirnya birokrasi perusahaan besar merusak semuanya
Apple terlihat seperti berharap bug itu menghilang dengan sendirinya
Saya juga sekarang sudah tidak mengirim laporan bug lagi
Tidak masalah kalau diabaikan, tapi masalahnya adalah ketika mereka memperlakukan saya seperti tenaga QA tanpa bayaran
Mereka menuntut upaya besar untuk membuktikan bahwa bug itu benar-benar ada
Pola pikirnya adalah “ini software milikmu, jadi debug sendiri”
Proyek open source juga sering melakukan penutupan otomatis issue stale
Menganggap issue otomatis selesai hanya karena lewat jangka waktu tertentu itu tidak masuk akal
Kelebihan open source adalah kita bisa memperbaikinya sendiri, mengirim PR, atau fork lalu menyelesaikannya
Memfilter tiket lama terasa lebih rasional
Dari sudut pandang pengguna ini menyebalkan, tapi tidak semua bug memang mudah direproduksi
Kadang lebih efisien meminta pengguna menguji ulang setelah ada perubahan kode terkait
Meski begitu, tetap terasa tidak enak saat harus menutup bug lama yang tidak bisa dijalankan ulang
Itu berarti mereka tidak bisa mereproduksinya hanya di jaringan internal Apple
Menutupnya cuma tindakan menyembunyikan masalah, dan membiarkannya terbuka tidak menimbulkan biaya
Harus memasang beta justru jauh lebih tidak efisien bagi pengguna
Saya bahkan sudah memberikan proyek contoh Xcode beserta langkah reproduksinya
Saya yakin Apple tidak melakukan apa-apa
Mungkin mereka sedang mengadakan pertunjukan bersih-bersih bug untuk persiapan macOS 27 sebelum WWDC
Saat bekerja di Facebook dan Google, saya sering melihat trik manipulasi pengelolaan bug
Setelah SLA diterapkan, prioritas bug sengaja diturunkan, atau tanggung jawab dilempar ke pengguna dengan pertanyaan “masih jadi masalah?”
Setelah waktu berlalu, bug ditutup dengan alasan “versi itu sudah tidak dipakai lagi”
Bahkan kadang dipaksa digabung dengan bug lain agar tanggung jawabnya kabur
Pada akhirnya ini semua karena metrik kinerja organisasi (SLA)
Karena itu sekarang saya hampir tidak pernah lagi mengirim laporan bug
Tapi manajemen menyuruh mereka “fokus ke proyek AI dulu”
Lalu setelah itu mereka dimarahi karena “bug terlalu banyak”
Menurut saya, lebih jujur mengabaikannya saja daripada menutupnya
Kepemimpinan mendorong triage paksa seperti ini
Memblokir notifikasi otomatis adalah masalah
misalnya situs benar-benar mati total, tapi kalau sedang musim sepi maka itu belum tentu P0
Namun dalam praktiknya kualitas datanya rendah sehingga tidak layak dipakai untuk pelaporan
Karena itu satu nilai prioritas saja sering lebih praktis
stalebot pada akhirnya menutup issue yang diabaikan seperti ini sebagai pengganti manusia
severity untuk pelanggan dan priority internal dikelola terpisah
Salesforce “Lightning Experience” ternyata sangat lambat, tidak seperti namanya
Alat internal jauh lebih cepat dan efisien
Hal yang sama juga terjadi di ElevenLabs
Saat mengirim laporan bug, AI otomatis membalas, lalu setelah 48 jam statusnya jadi stale
Sepertinya agen LLM akan segera menyelesaikan masalah seperti ini
Mereka bisa otomatis berkomentar “masih belum diperbaiki” dan secara berkala melakukan bump otomatis dengan kalimat seperti “ini memengaruhi workflow penting”
Dulu saya pernah mengirim bug ke Microsoft, lalu beberapa bulan kemudian mendapat kabar “tidak dapat direproduksi”
Ternyata di sela waktu itu masalahnya sudah terselesaikan secara tidak langsung oleh perbaikan lain
Saya sadar bahwa saya hanyalah orang buta yang memegang sebagian tubuh gajah
Saya mantan karyawan Apple
Pelacak bug internal Apple disebut Radar, dan semua issue harus melewati tahap “Verify” sebelum bisa ditutup
Sekilas terlihat seperti prosedur jaminan mutu, tapi kenyataannya banyak Radar yang berhenti di status Verify selamanya
Tim dievaluasi berdasarkan “jumlah Radar yang belum diverifikasi”, jadi setelah jangka waktu tertentu issue dipaksa ditutup
Ilusi “bug 0” menghasilkan metrik kinerja yang terdistorsi
Itu tidak berarti engineer Apple benar-benar mencoba memperbaikinya
Di perusahaan, saya dan rekan-rekan pernah mengadakan rapat pembersihan backlog
untuk merapikan bug-bug lama yang hanya terjadi sekali
Proses seperti ini sangat umum