- Apple schließt über den Feedback Assistant gemeldete Bugs automatisch, wenn Nutzer nicht selbst bestätigen (verify), dass sie „noch nicht behoben“ sind
- Beim Datenschutzleck-Bug im Zusammenhang mit der Netzfilter-Erweiterung (FB12088655), auf den es drei Jahre lang keine Antwort gab, verlangte Apple plötzlich eine Bestätigung und betrachtete ihn als behoben, falls innerhalb von zwei Wochen keine Antwort erfolgt
- Obwohl die Little-Snitch-Entwickler bestätigten, dass dasselbe Problem auch in der neuesten macOS-Version weiterhin besteht, schloss Apple den Report
- Dieses Verfahren funktioniert als Struktur zur künstlichen Reduzierung der Anzahl von Bug-Reports und verdeckt dadurch tatsächliche Qualitätsprobleme
- In der Folge wird kritisiert, dass Apples Umgang mit Bug-Management das Vertrauen von Entwicklern schwächt und eine kooperative Feedback-Kultur behindert
Apples Problem mit dem automatischen Schließen von Bug-Reports
- Ein Entwickler, der Bugs über den Apple Feedback Assistant gemeldet hat, kritisiert die Praxis, dass Apple Reports eigenmächtig ohne Bestätigung durch den Nutzer schließt
- Apple schließt entsprechende Reports automatisch, wenn Nutzer nicht selbst bestätigen, dass „der Bug noch nicht behoben ist“
- Nach jahrelanger Funkstille verschickt Apple plötzlich eine Bestätigungsanfrage und betrachtet den Fall als „behoben“, wenn innerhalb von zwei Wochen keine Antwort eingeht
- Im Fall FB12088655 „Privacy: Network filter extension TCP connection and IP address leak“, eingereicht im März 2023, gab es drei Jahre lang keine Reaktion; erst im März 2026 bat Apple um eine Bestätigung unter macOS 26.4 beta 4
- Da kein Beta-OS dauerhaft installiert war, ließ sich das nur schwer prüfen; auf Nachfrage bei Apple, ob der Fehler behoben sei, gab es keine klare Antwort
- Apple teilte mit, man werde den Report als behoben ansehen und schließen, falls er nicht innerhalb von zwei Wochen bestätigt werde
- Die Little-Snitch-Entwickler berichteten, dass sich dasselbe Problem auch unter macOS 26.4 beta 4 reproduzieren lasse
- Auch in der finalen Version von macOS 26.4 war derselbe Bug weiterhin vorhanden
- Dass Apple bei nicht behobenen Bugs eine direkte Bestätigung durch den Nutzer verlangt, wird als ineffizientes und unvernünftiges Verfahren kritisiert
- Es wird die Möglichkeit angesprochen, dass intern eine Anreizstruktur zur Reduzierung der Zahl von Bug-Reports wirksam ist
- Dadurch sinkt die Zahl der „offenen Bugs“, sodass es in internen Kennzahlen so aussieht, als habe sich die Qualität verbessert
Weitere Fälle von Bug-Reports
- Als weiterer Fall wird der Bug FB22057274 „Pinned tabs: slow-loading target="_blank" links appear in the wrong tab“ genannt
- Obwohl sich das Problem zu 100 % reproduzieren ließ, markierte Apple es mit „Investigation complete - Unable to diagnose with current information“
- Am 9. März wurden zusätzliche Informationen angefragt, doch Apple antwortete nicht
- In der iPadOS-26.4-Beta trat außerdem neu ein Safari-Absturz-Bug auf, den Apple bis zur Veröffentlichung der öffentlichen Version nicht behob
- Der Autor kritisiert, es wirke, als sei der Zweck der Beta nicht das Beheben von Bugs, sondern die Leute zu nerven, die sie melden
Veränderungen nach Hacker News und Apples Reaktion
- Kurz nachdem dieser Beitrag auf der Startseite von Hacker News erschien, aktualisierte Apple den Report FB22057274
- Apple verlangte für ein UI-Problem die Übermittlung von sysdiagnose-Logs
- Es wurde darauf hingewiesen, dass bereits Reproduktionsschritte und eine Bildschirmaufnahme vorlagen und dass sysdiagnose Datenschutzrisiken birgt und unnötiges Material ist
- Der Autor antwortete auf Apples Anfrage wie folgt
- „Für einen UI-Bug ist sysdiagnose nicht nötig und nicht hilfreich“
- Als auch ohne Little Snitch reproduzierbare Methode wurde vorgeschlagen, in den Xcode Additional Tools den Network Link Conditioner mit dem Profil für 3000 ms Uplink-Latenz zu verwenden, um dasselbe Verhalten nachzustellen
Hinweise zu Xcode Additional Tools
- Xcode Additional Tools enthalten mehrere nützliche Utilities und können auf der Seite Apple Developer Downloads (Login erforderlich) heruntergeladen werden
Gesamtbewertung
- Apples Umgang mit Bug-Reports belastet Entwickler unnötig und funktioniert als Struktur, die eher auf die Verringerung der Report-Zahl als auf tatsächliche Problemlösung ausgerichtet ist
- Durch langfristig unbeantwortete Reports, unvernünftige Bestätigungsanforderungen und ineffiziente Informationsanfragen
wird das Vertrauen von Entwicklern und ihre Bereitschaft zur Zusammenarbeit geschwächt
1 Kommentare
Hacker-News-Kommentare
Der Autor scheint wohl noch keine Erfahrung mit Enterprise-Software gemacht zu haben
Wenn Entwickler einen Bugreport bekommen, ist es der klassische Trick, Zeit zu schinden mit „Ich kann das nicht reproduzieren, haben Sie es in der neuesten Version geprüft?" und sonst nichts zu tun
Wenn es nicht bestätigt wird, wird es als „Benutzerfehler" oder „nicht reproduzierbar" geschlossen
Die einzige Gegenmaßnahme ist, „Ja, habe ich geprüft" zu sagen, ohne es tatsächlich zu prüfen
Wenn im Log ein Antivirenprogramm auftauchte, wurde der Fall sofort mit „Wenden Sie sich bitte dorthin" geschlossen
Es gibt eben viele wichtigere geschäftliche Prioritäten als ein Bug, den ein einzelner Nutzer gemeldet hat
Aus Nutzersicht ist das trotzdem bedauerlich
Die meisten Entwickler wissen entweder nicht, wie man ihr eigenes Produkt testet, oder sie sind zu faul dazu
In meiner Zeit im Enterprise-Tech-Support musste ich pro Tag mindestens zwei neue Fälle annehmen und gleichzeitig mehr als 20 verwalten
Es war eine enorme Erleichterung, Fälle ohne jeden Fortschritt als „wegen Inaktivität geschlossen" abzuschließen
Später kam dann die Regel, dass man vor dem Schließen dreimal nachfassen müsse, und das war ein Albtraum
Am Ende ruiniert die Bürokratie in Großunternehmen alles
Apple wirkt so, als würde das Unternehmen darauf hoffen, dass Bugs von selbst verschwinden
Ich melde inzwischen auch keine Bugs mehr
Ignoriert zu werden ist noch okay, aber das Problem beginnt, wenn sie mich wie unbezahltes QA-Personal behandeln
Dann verlangen sie einen riesigen Aufwand, nur um die Existenz des Bugs zu beweisen
Die Haltung ist: „Es ist deine Software, also debugge sie selbst"
Open-Source-Projekte machen oft etwas Ähnliches mit dem automatischen Schließen veralteter Issues
Nach einer gewissen Zeit automatisch anzunehmen, das Problem sei gelöst, ergibt keinen Sinn
Der Vorteil von Open Source ist, dass man es selbst beheben, einen PR einreichen oder das Projekt forken und so lösen kann
Alte Tickets zu filtern ist deutlich vernünftiger
Aus Nutzersicht ist das nervig, aber nicht jeder Bug ist leicht reproduzierbar
Manchmal ist es effizienter, nach relevanten Codeänderungen den Nutzer erneut um einen Test zu bitten
Trotzdem fühlt es sich unangenehm an, alte, nicht ausführbare Bugs zu schließen
Das bedeutete nur, dass es im internen Apple-Netzwerk nicht reproduzierbar war
Das Schließen verdeckt das Problem nur, und es kostet nichts, es offen zu lassen
Eine Beta installieren zu müssen, ist für den Nutzer deutlich ineffizienter
Ich hatte sogar ein Xcode-Beispielprojekt und Reproduktionsschritte geliefert
Ich bin sicher, Apple hat gar nichts getan
Vermutlich ist das nur eine Bug-Bereinigungsshow im Vorfeld von macOS 27 zur Vorbereitung auf die WWDC
Als ich bei Facebook und Google gearbeitet habe, habe ich viele Tricks im Bug-Management gesehen
Nach Einführung von SLAs wurden Bug-Prioritäten künstlich herabgestuft oder mit „Besteht das Problem noch?" auf den Nutzer abgewälzt
Mit der Zeit wurde es dann mit „Die Version ist obsolet" geschlossen
Teilweise wurden Bugs sogar erzwungen mit anderen zusammengeführt, nur um Verantwortung zu vermeiden
Letztlich liegt so etwas an den Leistungskennzahlen einer Organisation (SLA)
Deshalb melde ich heute kaum noch Bugs
Aber das Management sagt ihnen: „Konzentriert euch jetzt auf AI-Projekte"
Und gleichzeitig werden sie dafür getadelt, dass es zu viele Bugs gibt
Ich finde es ehrlicher, sie einfach zu ignorieren, statt sie zu schließen
Die Führung hat eine solche erzwungene Triage geradezu gefördert
Automatische Benachrichtigungen zu blockieren ist problematisch
In der Praxis ist die Datenqualität aber so schlecht, dass man sie kaum für Reports verwenden kann
Deshalb ist ein einzelner Prioritätswert praktischer
stalebot schließt dann im Grunde diese ignorierten Issues anstelle der Menschen
Für Kunden gab es eine eigene Severity, intern eine eigene Priority
Salesforce „Lightning Experience" ist entgegen dem Namen extrem langsam
Die internen Tools waren viel schneller und effizienter
Bei ElevenLabs gab es dasselbe
Wenn man einen Bugreport einreichte, antwortete automatisch eine AI, und nach 48 Stunden wurde er als stale markiert
Bald werden LLM-Agenten solche Probleme wohl lösen
Sie können automatisch Kommentare wie „Das ist immer noch nicht behoben" posten und regelmäßig mit „Das betrifft einen wichtigen Workflow" automatisch bumpen
Ich habe früher einen Bug bei Microsoft eingereicht und Monate später die Rückmeldung „nicht reproduzierbar" erhalten
Tatsächlich war das Problem in der Zwischenzeit indirekt durch einen anderen Fix behoben worden
Da wurde mir klar, dass ich wie ein Blinder war, der nur einen Teil des Elefanten ertastet hatte
Ich bin ehemaliger Apple-Mitarbeiter
Apples interner Bugtracker heißt Radar, und alle Issues müssen den Status „Verify" durchlaufen, bevor sie geschlossen werden können
Oberflächlich wirkt das wie ein Qualitätssicherungsprozess, tatsächlich bleiben aber unzählige Radars im Verify-Status für immer hängen
Teams werden nach der Zahl ihrer „nicht verifizierten Radars" bewertet und schließen sie deshalb nach einer gewissen Zeit zwangsweise
Die Illusion von „0 Bugs" erzeugt verzerrte Leistungskennzahlen
Daraus lässt sich kaum schließen, dass ein Apple-Ingenieur tatsächlich versucht hat, das Problem zu beheben
Bei uns im Unternehmen haben wir gemeinsam mit Kollegen Backlog-Bereinigungsmeetings durchgeführt
und dabei alte einmalige Bugs aussortiert
Solche Prozesse sind sehr verbreitet