Everyone has a love/hate relationship with bug reports. For the user, they’re a nuisance to file. For the engineer receiving a bug report, it means extra work and the sad realization that your product isn’t perfect.

I’ve been frustrated with Apple’s handling of bug reports just as much as everyone, but haven’t really thought much about it recently. But with some recent talk on the topic, I felt like playing the devil’s advocate and wanted to share a few thoughts in defence of Apple’s engineers.

I've been unhappy with how Apple deals with external bug reports. This is what happens to your bugs: https://t.co/6SIgeQBDHz

— corbin dunn (@nibroc) March 10, 2019

When @nibroc shared a post about the ugly details for how bugs are dealt with at Apple (spoiler alert: not well, or consistently), I enjoyed seeing my feelings echoed by someone much more familiar with the process; I haven’t actually ever worked for Apple, so I don’t have the same experiences on the other side of the fence. But being a software engineer myself, working on a team developing an SDK for other developers, I thought I’d share my own thoughts in defence of them.

Side note: I wanted to point out that I feel that Corbin’s article is spot on, and is a great post!

It seems like people tend to forget what bug reports represent: a request to fix something. As with all requests, some are good and some are bad. This goes for bugs as well, and the quality of bug reports from most users leaves much to be desired. Judging by the kinds of bugs that I’ve seen, the usefulness of many of them may be limited. Statements of “It doesn’t work” without version information, crash stack traces, log messages, etc can all contribute to cluttering up your bug list and can hide otherwise important bugs.

But stepping back from the quality of bug reports for a moment, let’s not forget that at the other end of a bug report is a human being that has to figure out what to do with it. Many times that human being has a lot of other work they need to get done.

Apple engineers have feelings too

I feel that the more people who realize there are human beings on the other end of a bug report (who are also developers), the more bugs will be properly fixed.

I’d hate being on the receiving end of even 10% of the bugs Apple devs must receive.

— Michael Nachbaur (@NachoMan) March 10, 2019

As developers, we all know how difficult it is to track down problems in our software, even if we discover the bug ourselves. When a bug is reported from someone else (either within, or outside, your team or company) the problem gets even harder to track. Apple’s engineers are no different, and reporting gnarly bugs with little to no information about it is a virtual guarantee that it won’t get fixed.

Helping the engineer triage their bug starts with the report itself. Proper descriptions of the problem, a good summary to indicate the impact of the bug, and of course reproduction steps (if any).

A little bit of kindness certainly goes a long way as well; no engineer likes to discover bugs in their product, so already having issues pointed out by their users is a hard pill to swallow. It’s easy to feel deflated when issues are pointed out, so I try my best when filing bug reports to treat it as if I were talking to the developers themselves directly. If I wouldn’t be willing to say something directly to their faces, I would find a gentler way of writing it in the report.

Developing an SDK is no easy picnic either. In my work on the Service SDK at Salesforce, I can attest to the fact that developing an SDK is significantly more difficult to build than an app. With an app, you have control over so many variables that helps to constrain the app’s functionality; rotation, colours and fonts, languages, etc are all within your control. With an SDK however you have no control over how it will be used (or abused) in a developer’s app.

The same goes for Apple, but to a significantly higher degree. The things some people do to a UITableView or UIViewController to get things to work the way they want must make Apple engineers cry themselves to sleep at night.

A little bit of effort goes a long way

Oh for sure! I used to love Appkit bug reports that included a test case in source code.

— corbin dunn (@nibroc) March 10, 2019

If a bug is really important to you, my advice is to try reproducing it in a stand-alone app.

Create a small test project that demonstrates the bug (be it a crash, a UI glitch, or whatever). Many times I’ve found the root cause of a bug on my own this way, and found it to be something I’ve done incorrectly in the first place!

I’ve even gone so far as creating Xcode UI tests that automates the reproduction of a bug. This helps the engineer reproduce your problem quicker, the steps can be documented with comments, and as a bonus it allows Apple engineers an easy way to verify their fix solves your actual problem!

Bug reporting is a 2-way street

It’s easy to blame Apple for poor bug handling practices, but I feel it’s a two-way street. It’s just as much our responsibility as theirs to ensure important bugs get fixed; we should do everything in our power to make their jobs easier in solving bugs. And if we can’t, then at the very least we can treat Apple’s engineers with respect.

Even if your bug doesn’t get fixed, at least you’ll be paying it forward for when someone inevitably files a bug against your product.