If you’ve ever run any type of Apple beta software, you know the feeling; heading into the Feedback app, filling in all of the information, and then pressing that gorgeous “Submit” button.
We’ve all been there, and besides knowing that the bug report gets sent to some server back in Cupertino, not much is publicly known about the inner workings of Apple’s software team and how it handles bugs. That however changed in March of last year when Corbin Dunn, a former Apple engineer recollected his experience working at the tech-giant.
In turns out like everything Apple does, it’s highly organized. Internal Apple employees who work on software use an application called “Radar,” which allows them to log a bug directly into the database of bugs. For everyone else, the equivalent of “Radar” is the Feedback app on beta devices or bugreport.apple.com.
Radar however provides more information than what the Feedback app or website provides. Radar enables engineers to comment, set priority, log the progress on a bug fix, and in which future update the bug is expected to be fixed. Employees here can also set the priority of the bug; the higher the priority, the sooner it’s likely to be addressed.
Once a bug gets submitted, it then get sorted into different departments, as Corbin explains:
Each bug is placed into a particular top level component, which can have sub components. Savvy internal developers will log bugs directly into the component that the bug corresponds to, such as “AppKit / NSTableView”. This will get it directly to the right person who needs to look at it. Top level components have a large dropping areas that generic bugs can fall into, such as “iTunes / All”. These components get saturated with bug reports.
Once a bug gets sorted into the correct component, an engineer, likely from Developer Support will review the report and decide where it belongs more specifically. In simpler terms, from start to finish it’s a complicated process for how bugs get sorted and ensuring they end up at the desk of the right engineer who can fix it.
The System is Apparently a Big Mess
But, as Corbin explains, the entire system of bug management is “screwy” since the majority of different departments only have one or two people reviewing bugs, causing them to be limited in resources resulting in a backlog of bugs needing to be addressed.
In the contest, Corbin advises that Apple should allow the engineer who owns the specific code being reported on to review the report and allowing them to take full ownership of its fixing. Speaking from personal experience logging bugs at Apple, Corbin describes the system as “demoralizing” and frustrating.
From an internal developer’s perspective, it was quite frustrating to take the time to log a detailed bug, only to see it sit “unscreened” for weeks and weeks. It is demoralizing to see this happen to your bugs. But worse yet, sometimes your bug would get forward-duped. Someone else at a later time logs the same bug, and your older bug report gets duplicated to it. More often than not, this is simply because of the delayed screening of bugs.
When bugs get left unseen, it means they aren’t getting fixed and leave users with a buggy OS experience. Worse yet, sometimes the bugs get left unscreened forever resulting in them never being fixed, and if they are screened, engineers sometimes ask the original user who reported the bug to provide more information, which they don’t always do.
In a solution to all of this, Corbin advises that internal Apple engineers need to “take more responsibility in promptly screening bugs” and that Apple management “needs to allow engineers to have more time to do this”. Corbin who released this article in March of 2019 seems to have possibly motivated some Apple executives to make some changes.
Things Have Likely Changed
Bloomberg reported 9 months later that Apple’s Craig Federighi overhauled the entire software department and more specifically how it handles bugs. According to that report, Apple now pushes out “daily builds” that leaves unfinished or buggy features disabled by default. From there, people who test the software can manually turn those features on or off to diagnose any potential issue.
Given the 9 month gap between Corbin and Bloomberg’s article, it’s hard to exactly tell what remains the same at Apple from Corbin’s recollection. Some parts likely remain true including the use of Radar, and engineers’ ability to use the application to log comments, progress, and more. The biggest difference will likely bowl down to how exactly bug reports are sorted and assigned.