App developers, frustrated with bug reporting tools, call on Apple to ‘Fix Radar or GTFO’

If you’re an iOS or Mac developer, then you’ve probably had an encounter with Apple’s bug reporting tool called Radar. Although complaints have been voiced about Radar for years, there is now an online petition being passed around that asks the company to fix the major issues that keep many developers from wanting to use it more frequently.

The petition, entitled ‘Fix Radar or GTFO‘ urges developers to file a Radar to fix Radar, effectively using Apple’s own tool to protest just how irritating it is to use. It was created, and the first Radar filed, on March 6th by Martin Pilkington of M Cubed Software.

And the list of petitioners is nothing to joke at. Many on the list are developers and evangelists that I know and respect and they make apps that you use. Craig Hockenberry from The Iconfactory, Steve Streza of Read it Later, Justin Watt of Objectivesee, Chris Parrish, Sam Soffes formerly of Synthetic, Nik Burns of Burnsoft and Andy Mroczkowski of MindSnacks are some recognizable names, but there are hundreds more.

The name of the petition originates with a popular meme among the Apple development community that goes: ‘file a Radar or GTFO’, which was immortalized in the photo below by George Dick being captioned by developer Steve Streza. This refers to the fact that Apple developer evangelist Michael Jurewitz often replies to inquiries about issues with Xcode or other tools with an immediate ‘have you filed a Radar?’

Jury, as he’s known on Twitter, has a point. If you’re complaining about random bugs in software suites as complex as Apple’s SDK is, having a way to track and prioritize them is a must.

Filing a Radar should be the very first thing that a developer does when he or she finds an issue. This was stated eloquently in a recent article from Black Pixel’s Daniel Pasco, in which he stresses the importance of duplicates of the same bug being registered. “File your radar, then go to Open Radar and post the same bug there as well (don’t do this for beta products under NDA!). Then tweet the open radar link so that other people are aware of the issue as well,” Pasco writes. “Hopefully that will spur on other people experiencing the same problem to file a report of their own.”

The problem with this approach is that Radar doesn’t work as well for duplicates as one would hope. You’ll note that Pasco suggests going to Open Radar, a public repository of filed Radar entries, to let other developers know you’ve filed the issue. Why isn’t this kind of easily searchable database a part of Radar itself? Those questions and more are asked in the text of the Radar petition.

The petition is worth reading in full if you’re a developer, but the core of it is this:

By making radars so hard and painful to file, most developers end up not filing them. For every radar that is filed, there are many more that developers would file but don’t consider it a big enough issue to be worth the time. It may be a small bug or feature request, or it may be a common issue that we figure someone else has already filed so there’s no point wasting our time telling you about it.

I spoke to developers that had signed the petition, asking why they felt so strongly about it and came up with a few major points, most of them touched on by the actual text of the Radar itself. Some of the choice points broached by developers and by the document itself:

A lack of transparency — “Radar is a roach motel; bugs go in, and don’t come back out. Developers have no idea if the bug they’re filing is new or has been filed a hundred times.”

Duplication of existing bugs feels fruitless — “Most bugs that get filed just get marked as a duplicate of some other bug, and the progress on that bug can’t be seen by anyone besides the original filer.”

A lack of a feeling of community and communication  — “Developers end up wasting a lot of time building test cases and samples, and have no idea if this data will be useful at all. It would be extremely useful if developers could mark their bugs as “public” or “public to NDA’d people”, so other people could find them and contribute to those bugs directly, or not waste time filing them at all if the bugs have been already fixed.”

Filing radars directly from Xcode — “We spend most of our time in Xcode, so it makes sense to reduce the context switch needed to file a bug. Add a Radar tab to the organiser and let us quickly search and view existing radars.”

“If Apple opened up Radar more to developers and made the common cases less hostile,” one code jockey told me, “those developers would be more willing to write more bugs and better bugs.”

The developers who have signed the petition by filing their own radars are not out to complain about a pet feature that doesn’t exist in Apple’s current SDK. They’re not working to make Apple more publicly transparent about future features, which we all know the company does not do. They’re just asking for the tools that they use to improve Apple’s software development products be made as painless and transparent as possible.

The petition sums it up well, ending with the following appeal “So please fix Radar. You’ve worked hard to give us great APIs, a great language, great documentation and great developer tools. Please now focus your attention on giving us a great tool to help us help you.”

We’ve reached out to Apple to see if the company has a comment on the petition and we will update this if we receive one.