You can do a lot to help get serious bugs fixed by Apple. The “What can you do?” section of Corbin Dunn’s well-publicized blog post “The Sad State of Logging Bugs for Apple” is far too thin. The post is mostly inside baseball on how bugs are screened at Apple. Neither you nor I can do much about how Apple screens bugs. However, there is a *lot* you and I can do to get serious bugs into the hands of people who can act on them.
First and foremost, write good bugs. This is fairly easy to do, though it can be time-consuming. If you’re not already familiar with bugreport.apple.com, that’s the site for reporting bugs to Apple. When you create a new bug, Apple includes a template in the description for exactly how they want you to report your bug. Apple isn’t looking for you to create your own format or to report things entirely in prose. They also include a handy page of tips for reporting bugs, which you should follow.
Reductive Examples
Create a reductive case of your bug if at all possible. Most likely, you’ll initially encounter a bug in a specific context. For example, I received an email with a fractional street address, and Mail’s data detector chopped off the whole number portion of the address. Rather than report the bug with steps in Mail, I figured that the data detector itself was broken and made a very small Xcode Playground to demonstrate the problem. It’s time-consuming to create reductive cases, but it also reduces the likelihood of confusion. Consider that the person reading and reproducing your bug needs to see it as simply as possible.
If there’s no action on your bug, the next step is to mail [email protected] and request status. Note that it can take a while to get a reply. Filing and following up on getting bugs fixed with Apple is a process, as with anything else.
File a Technical Support Incident incident (TSI). This generally will result in a Developer Technical Support (DTS) engineer testing your repro steps. Assuming they can reproduce, generally they’ll track down the correct person to whom to assign the bug. In my experience, often they’ll reverse the incident charge in this situation without even being asked. This is an excellent use of the two TSIs included in your Apple Developer Program membership. If you’re not going to fight for your bug, how do you figure anyone at Apple will?
Develop a rapport with DTS and others at Apple. I’ve had several bugs transit a specific DTS engineer. I could email that engineer directly if I felt that would help. I would generally only do so if the process seemed broken somehow in order to get it back on track. Keep in mind that there are vastly more developers than Apple engineers, and please be respectful of their time. I’m quite sure you’ll get farther with brevity, clarity, a reductive example, and by being courteous than you would any other way. If you’re able to attend WWDC, bring your bug list to the labs and track down someone on the team that owns your bug. Talk to them.
Reach Out and Advocate
Open Radar is a great resource. You can search for your bug before filing and perhaps duplicate someone else’s reductive example rather than having to create your own. You can also post your bugs there to help other developers.
If you know someone else who is impacted by the same bug as you, let them know and point them to your report on Open Radar. If they can duplicate the bug on bugreport.apple.com, that may help get it attention or increase its priority.
Apple’s Developer Forums are another good place to advocate for your bug. The Forums may connect you with other affected developers, or if you’re quite lucky with a DTS engineer or product engineer who can help take up your case internally.
Filing good bugs is time-consuming, as is making good, reproducible, reductive cases. Do that, then don’t forget about the follow-up. Don’t just throw it over the wall and think it will magically get the attention you expect it deserves. Advocate for your bug, and you’ll increase the odds it gets fixed.