- Apple, Feedback Assistant üzerinden bildirilen hataları, kullanıcı “henüz düzeltilmediğini” bizzat doğrulamazsa (verify) otomatik olarak kapatıyor
- Ağ filtresi uzantısıyla ilgili gizlilik sızıntısı hatası (FB12088655) için 3 yıl boyunca yanıt vermeyen Apple, aniden doğrulama istedi ve 2 hafta içinde yanıt gelmezse düzeltilmiş sayacağını bildirdi
- Ancak Little Snitch geliştiricileri aynı sorunun en güncel macOS sürümünde de devam ettiğini doğrulamasına rağmen Apple raporu kapattı
- Bu süreç, hata raporu sayısını yapay olarak azaltan bir yapı gibi işliyor ve gerçek kalite sorunlarını gizleme etkisi yaratıyor
- Sonuç olarak Apple’ın hata yönetimi yaklaşımının geliştirici güvenini zayıflattığı ve işbirlikçi geri bildirim kültürüne zarar verdiği belirtiliyor
Apple’ın hata raporlarını otomatik kapatma sorunu
- Apple Feedback Assistant üzerinden hata bildiren bir geliştirici, Apple’ın kullanıcının onayı olmadan raporları keyfi biçimde kapatma alışkanlığını eleştiriyor
- Apple, kullanıcı “hatanın hâlâ düzeltilmediğini” doğrudan doğrulamazsa ilgili raporu otomatik olarak kapatıyor
- Yıllarca yanıt vermedikten sonra bir anda doğrulama talebi gönderiyor ve 2 hafta içinde yanıt gelmezse “düzeltildi” kabul ediyor
- Mart 2023’te gönderilen FB12088655 “Privacy: Network filter extension TCP connection and IP address leak” vakasında, 3 yıl boyunca yanıt gelmedi; Apple ancak Mart 2026’da macOS 26.4 beta 4 üzerinde doğrulama istedi
- Beta işletim sistemi sürekli kurulu olmadığından doğrulama zordu ve Apple’a düzeltilip düzeltilmediği sorulduğunda net bir yanıt alınamadı
- Apple, “2 hafta içinde doğrulamazsanız düzeltilmiş sayıp raporu kapatacağız” diye bildirdi
- Little Snitch geliştiricileri, aynı sorunun macOS 26.4 beta 4’te de yeniden üretilebildiğini bildirdi
- Nitekim macOS 26.4’ün nihai sürümünde de aynı hata devam ediyordu
- Apple’ın düzeltilmemiş bir hata için kullanıcıdan doğrudan doğrulama istemesi verimsiz ve mantıksız bir süreç olarak değerlendiriliyor
- İçeride hata raporu sayısını düşürmeye yönelik bir teşvik yapısının işliyor olabileceği dile getiriliyor
- Bunun sonucunda “açık hata sayısı” azalıyor ve iç metriklerde kalite artmış gibi görünüyor
Diğer hata raporu örnekleri
- Bir başka örnek olarak FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tab” hatası anılıyor
- %100 yeniden üretilebilen bir sorun olmasına rağmen Apple bunu “İnceleme tamamlandı - mevcut bilgilerle teşhis edilemiyor (Investigation complete - Unable to diagnose with current information)” şeklinde işaretledi
- 9 Mart’ta ek bilgi istendi ancak Apple yanıt vermedi
- iPadOS 26.4 beta’da yeni bir Safari çökme hatası ortaya çıktı ve Apple bunu genel sürüm yayımlanmadan önce düzeltmedi
- Yazar, “Betanın amacı hataları düzeltmek değil, hata bildiren insanları bezdirmek gibi görünüyor” diyerek eleştiriyor
Hacker News sonrası değişiklikler ve Apple’ın yanıtı
- Bu yazı Hacker News ana sayfasına çıktıktan hemen sonra Apple, FB22057274 raporunu güncelledi
- Apple, UI sorunu için sysdiagnose günlüklerinin gönderilmesini istedi
- Oysa yeniden üretim adımları ve ekran kaydı videosu zaten sağlanmıştı; ayrıca sysdiagnose’un gizlilik ihlali riski taşıdığı ve gereksiz bir veri olduğu belirtiliyor
- Yazar, Apple’ın talebine şu şekilde yanıt verdi
- “UI hataları için sysdiagnose gerekli değil ve fayda sağlamaz”
- Little Snitch olmadan da yeniden üretilebilen bir yöntem olarak, Xcode Additional Tools içindeki Network Link Conditioner ile uplink gecikmesini 3000ms profiline ayarlarsanız aynı davranışın yeniden üretilebileceğini belirtti
Xcode Additional Tools bilgisi
- Xcode Additional Tools, çeşitli faydalı yardımcı araçlar içeriyor ve
Apple Developer Downloads sayfasından (giriş gerekli) indirilebiliyor
Genel değerlendirme
- Apple’ın hata raporu yönetim biçimi, geliştiricilere gereksiz yük bindiriyor ve
gerçek sorun çözümünden çok rapor sayısını azaltmaya odaklanan bir yapı gibi çalışıyor
- Uzun süre yanıtsız bırakılan raporlar, mantıksız doğrulama talepleri ve verimsiz bilgi istekleri nedeniyle
geliştirici güveni ve işbirliği isteği zayıflıyor
1 yorum
Hacker News görüşleri
Görünüşe bakılırsa yazarı kurumsal yazılım deneyimlememiş
Geliştiriciler bir bug raporu alınca tipik olarak “Bende yeniden üretilemiyor, en son sürümde kontrol ettiniz mi?” diyerek hiçbir şey yapmadan zaman kazanır
Doğrulanamazsa “kullanıcı hatası” ya da “yeniden üretilemez” diye kapatırlar
Tek karşı önlem, “Evet, kontrol ettim” deyip gerçekte kontrol etmemektir
Loglarda antivirüs görünürse “Onlarla iletişime geçin” deyip hemen kapatıyorlar
Çünkü tek bir kullanıcının bildirdiği bug’dan daha önemli pek çok iş önceliği var
Yine de kullanıcı açısından üzücü bir durum
Geliştiricilerin çoğu kendi ürününü test etmeyi ya bilmez ya da üşenir
Kurumsal teknik destek zamanlarımda günde en az iki yeni vaka almak zorundaydım ve aynı anda 20’den fazlasını yönetiyordum
Hiç ilerlemeyen vakaları “etkin değil diye kapatınca” gelen rahatlama büyüktü
Sonradan kapatmadan önce üç kez iletişim kurma kuralı geldi, tam bir kâbustu
Sonuçta büyük şirket bürokrasisi her şeyi mahvediyor
Apple, bug’ların kendiliğinden yok olması için dua ediyormuş gibi davranıyor
Ben de artık bug raporu göndermiyorum
Göz ardı edilmem umurumda değil, sorun onların beni ücretsiz QA iş gücü gibi görmesi
Bug’ın varlığını kanıtlamak için inanılmaz çaba istiyorlar
Düşünce şu: “Bu senin yazılımın, o zaman debug işini de sen yap”
Açık kaynak projeleri de benzer şekilde stale issue otomatik kapatma yapıyor
Belli bir süre geçince otomatik olarak çözülmüş sayılması mantıklı değil
Açık kaynağın avantajı, kendin düzeltebilmen, PR gönderebilmen ya da fork’layıp çözebilmen
Eski ticket’ları filtrelemek daha mantıklı
Kullanıcı açısından sinir bozucu ama her bug kolay yeniden üretilebilir değil
Bazen ilgili kod değişikliğinden sonra kullanıcıdan tekrar test istemek verimli olabiliyor
Yine de eski ama çalıştırılamayan bug’ları kapatırken insan kendini kötü hissediyor
Bunun anlamı, Apple’ın iç ağında yeniden üretilememesiydi
Kapatmak sadece sorunu görünmez kılmak, açık tutmanın bir maliyeti yok
Beta kurmak kullanıcı için çok daha verimsiz
Ben Xcode örnek projesini ve yeniden üretim adımlarını bile verdim
Apple’ın hiçbir şey yapmadığından eminim
Muhtemelen WWDC öncesi macOS 27 hazırlıkları için bir bug temizleme şovu yapıyorlar
Facebook ve Google’da çalışırken çok bug yönetimi hilesi gördüm
SLA geldikten sonra bug önceliklerini yapay olarak düşürmek ya da “Hâlâ sorun yaşıyor musunuz?” diyerek topu kullanıcıya atmak yaygındı
Bir süre geçince de “o sürüm artık kullanımda değil” denip kapatılırdı
Hatta bazen sorumluluktan kaçmak için başka bug’larla zorla birleştirildiği bile olurdu
Sonuçta bütün bunların nedeni kurumsal performans metrikleri (SLA)
Bu yüzden artık neredeyse hiç bug raporu yapmıyorum
Ama yönetim “şimdi AI projelerine odaklanın” diye talimat veriyor
Sonra da “neden bu kadar çok bug var” diye azarlıyor
Kapatmak yerine görmezden gelmenin daha dürüst olduğunu düşünüyordum
Liderlik bu tür zorunlu triage davranışlarını teşvik ediyordu
Otomatik bildirimleri engellemek sorunlu
Örneğin site tamamen çökmüş olsa bile şu an yoğun sezon değilse P0 olmayabilir
Ama pratikte veri kalitesi o kadar düşük oluyor ki raporlama için kullanılamıyor
Bu yüzden tek bir öncelik değeri daha kullanışlı
stalebot da bu şekilde göz ardı edilmiş issue’ları senin yerine kapatmış oluyor
Müşteri tarafı severity ile iç taraftaki priority ayrı tutuluyordu
Salesforce “Lightning Experience”, adına rağmen çok yavaş
İç araçlar çok daha hızlı ve verimliydi
ElevenLabs’te de aynı şey olmuştu
Bug raporu gönderince AI otomatik yanıt veriyor, 48 saat sonra da stale durumuna düşüyordu
Yakında LLM ajanları bu sorunu çözecek gibi görünüyor
Otomatik olarak “Hâlâ düzeltilmedi” diye yorum yazıp, düzenli aralıklarla “Bu önemli bir iş akışını etkiliyor” diyerek otomatik bump yapabilirler
Bir zamanlar Microsoft’a bug göndermiştim, aylar sonra “yeniden üretilemedi” diye dönüş yaptılar
Meğer o arada başka bir düzeltmeyle dolaylı olarak çözülmüş
Böylece filin sadece bir kısmına dokunan kör olduğumu fark ettim
Eski bir Apple çalışanıyım
Apple’ın iç bug takip sistemine Radar denir ve her issue kapanmadan önce “Verify” aşamasından geçmek zorundadır
Dışarıdan kalite güvencesi süreci gibi görünür ama gerçekte sayısız Radar, Verify durumunda sonsuzca bekler
Takımlar “doğrulanmamış Radar sayısı” ile değerlendirildiği için belli bir süreden sonra zorla kapatırlar
“0 bug” yanılsaması çarpık performans metrikleri üretir
Apple mühendisinin gerçekten bir düzeltme denediği anlamına gelmez
Şirkette iş arkadaşlarımla birlikte backlog temizliği toplantıları yapıp
eski tek seferlik bug’ları ayıklardık
Bu tür süreçler oldukça yaygın