I was fortunate enough to attend Facebook's London Mobile Forum recently.
Perhaps the most interesting part of it was discussing issues and practices with a group of people who work on other platforms than iOS, at a level where we could leave behind the pseudo-religious battles over platform and concentrate on real issues.
There were several occasions when those of us who dev for iOS would reference 'filing a Radar' and get puzzled looks from the un-annointed. It made me think about the phenomenon of Radar and it's reputation within the developer community.
I see a lot of negativity toward Radar, mostly expressed as frustration around visibility of content. For those who don't know what Radar is, it's really two things:
Externally it's a website. You can go there and log an issue or feature request, provide details and submit it to Apple. You can see only the issues you've logged and their current status. We'll discuss this aspect in a moment.
Internally to Apple, it's Mac application and a website that is used by the engineering teams to track reported bugs and issues and is part of the process of defining what work to do and track it's resolution/implementation. This side gives you a view on most/all of the logged issues, depending on access rights, and add comments, amend status etc...
It's not really changed much, except for some facelifts around the interfaces, for many years. Most of the complaints from developers come from the opacity of the process. Things you file are not accessible to your outside colleagues, progress on tickets is invisible and the most common response is that your issue is a duplicate of another issue (which you can't reference because you didn't log it) and it's closed. This cuts you off from the progress on possible resolutions.
(One solution that people support is end-running the system with OpenRadar. This is an openly visible database of bug reports where you can duplicate your original Radar along with it's actual Radar reference and update, track and discuss to your hearts content. It's a good initiative, if somewhat more time consuming and does point to a need for change.)
Now I agree this is frustrating. But it's important to remember the origin, purpose and management of the original system. It's run by the engineering teams, NOT by Developer Relations (which is actually a subgroup of Phil Schillers marketing teams). It's primary purpose was for internal bug tracking and was opened later to external submission by registered developers. You are probably now saying that this should be changed and a better system put in place. Well that's very likely true but it's not happened yet so perhaps we should focus on what we can do to get more out of the current system?
Post more things
People are not posting enough on Radar. The passed down lore, often confirmed by Apple people, is that the more Radars are filed on an issue, the more attention it gets. Internally to Apple it's considered a mark of disrepute to have too many Radars pending on you. Because the process is a black box, we often feel like our contribution is unlikely to have an effect, however you have to have some faith that this is how it works.
No-one wants to spend time writing dry, factual descriptions of minor UI Kit bugs but consider this: Swift is acknowledged to have improved significantly through our input and the mechanism for that has been Radar posts.
Swallow your angst and try to commit to posting everything you find. It's a no-lose situation as I'll cover now.
The no-lose situation
If you file *every* bug or issue you encounter, and every feature request you devise, what good will it do? I would argue this is a no-lose situation. Why? Well consider the possible outcomes:
1. Nothing changes
We're no worse of than we are now but at least you can say you've tried, you've sent the information and nothing has been done with it. Now you can legitimately take to Twitter and whinge about it.
2. More submissions results in more fixes/features
Great! That thing you filed in June 2011 got fixed in iOS9! Or maybe that Swift issue you cursed about got fixed in the very next release. Now you don't 100% know that it was your submission that tipped the scales but we're not all that in need of validation, it's enough to know that your hand was on the cart of progress.
3. The existing system can't handle the load
Mayhem! Engineering is swamped by bug reports. Management can't decide what to fix next, Radar crashes daily with the tidal wave of input. Apple are, if nothing else, pragmatic and, certainly in the last decade, ready to admit when they are wrong. The most likely outcome here is that a new system rises, phoenix-like, from the ashes of the old one that is better suited to the requirements that iOS has wrought on the number of developers Apple attracts.
So if it's a no-lose result, please do embrace Radar for what it is, and what it can do, and post more on there.
