5 Tips for Reporting Bugs & Feedback to Apple

If you’ve been a developer on Apple platforms like iOS and macOS for a while, you’re undoubtably familiar with an internal tool known as “Radar.” Radar is a bug tracker that Apple builds, maintains, and uses to track nearly every piece of software engineering work that’s necessary to release their operating systems and devices. And sometimes, when you as a third-party developer, encounter a bug in the OS or frameworks you’re using, you might be encouraged (well, shouted at) to FILE A RADAR! Or even “Radar or GTFO.”

While Radar has its critics, and we’re often among them, it has been a useful tool for us to report issues over the years—many of which have been fixed by Apple.

So how do you file a radar? It’s as simple as filling in a single form in Apple’s Bug Reporter, as long as you’ve got a developer account.¹ But what makes Apple more likely to pay attention to your bug when thousands are pouring in? 10 years of radar-filing and nearly a hundred radars later, we have a few tricks up our sleeve.

1. Reproduce the issue 📋

There’s nothing worse than being assigned a bug to fix that you can’t even make happen. So before you file your report with Apple, you’ll want to make sure you can make it happen more than once. Once you know the steps necessary to “repro” the bug, and have confirmed that it’s not an issue with your own app, try to whittle it down to the smallest number of steps or factors necessary to get it to happen.

Find the “smallest reproducible case” and then move on to tip number two.

2. Include a sample project 📎

Apple doesn’t want to hunt through your entire app, and you don’t want to go around uploading your company’s source code on random web forms. That’s a no-no. So instead, try to make a tiny app dedicated to making the bug happen, and include that with your report instead of your hundred-thousand line codebase.

Your sample project can be super barebones and sometimes even fit into a Playground, but feel free to spice up your radars with humor, instructions within the app, and more if you want to. If only we had the time. 🤷‍♂

3. Attach logs 📑

Apple will often also request a [sysdiagnose](https://developer.apple.com/bug-reporting/profiles-and-logs/?name=sysdiagnose) log with your report. Sysdiagnose is a built-in OS-level tool that can collect detailed logs that the engineer on the other side might find very helpful in their debugging of your issue. If you’re having a problem with a particular framework like CloudKit or Photos, you can also find profiles and instructions for enabling additional logging on the developer portal. You’ll save some back-and-forth if you turn those on and include them in your initial report.

4. Publicize your report 📣

Radars are normally private, for good reasons: reports sometimes contain security and privacy-sensitive information that Apple wouldn’t want to inadvertently leak. But every radar has a unique ID number, and if you’re sure that there’s no corporate or personal secrets, you can use that number to file a public version on Open Radar, an open-source community resource. When you link to the radar on Twitter or in Slack, it’s a best practice to include the Open Radar link and the rdar://bugid style link so Apple folks can open it right up inside their native Radar app for macOS and iOS.

Since Open Radar doesn’t host files itself, we recommend uploading your attachments to Dropbox, Google Drive, or GitHub and linking to them from there. Also, once Apple responds to your bug, it’s on you to mirror that on Open Radar so the larger community knows when it’s fixed, or (more commonly) marked as a duplicate of another report.

5. Know people at Apple 🤝

I know, I know…easier said than done. Even though this might not be realistic for every developer, it really does help to build relationships with Apple engineers at WWDC and Tech Talks, on Twitter, and in the Developer Forums. We’ve found that our radars tend to get treated with a little more urgency by having folks to email or DM who work at Apple. There’s also a trend within the company informally called radar-stalking where Apple engineers can set up a filter to be notified whenever an individual reporter or dev team files an issue. So the more folks you get to know, the better your chances that someone might decide to watch your account for fun!

In Closing

The mascot for Radar is an anteater. It eats bugs, get it?

Filing radars is a pain and sometimes it feels like shouting into a black hole. If you need more urgent help or a workaround, don’t be afraid to use a Technical Support Incident (TSI) if your radar isn’t getting traction fast enough. That’s what the Developer Technical Support team is there for.

Looking for more tips on filing radars that will give Apple everything they need to fix your bug? Check out Apple’s instructions and these posts from our friends at PSPDFKit and Rene Ritchie at iMore. If you have tips of your own that we should know about, tell us all about them on Twitter at @lickability.

¹ If your issue is with the Swift programming language specifically, you may be able to skip Radar and file a bug in the project’s public JIRA project.