Fix Radar or GTFO
marco.org
marco.org
I never got any feedback on this bug at all (just like always).
But, this Apple guy looked up the bug on their internal radar tool (a native Mac app, not some crappy web interface). There were screens full of discussion, with engineer's names I recognized, and the bug has been elevated to "Show-Stopper" status, which he told me meant the next release wouldn't ship without a fix.
What I took from this is that Apple's internal tools for bug triage, discussion, and prioritization are relatively sophisticated and heavily used, but they have nothing to do with the pathetic, rude, uninformative Radar interface that we peons who pay Apple for the privilege of developing for their platform get to see. It was kind of interesting to get a peek inside from their perspective.
Having said that, though, I almost never file Radar issues anymore, for exactly the same reason that I don't go to Apple's offices and clean their toilets for free.
As a someone who's filed a few Radar issues over the years, I understand that the lack of feedback is frustrating, but I find it absurd that the way to fix that is to withhold the bug reports that help improve the software we use and develop for daily.
Now, if it was instead the toilet at a restaurant or other venue that I frequent, where I am welcomed and treated with respect, then of course I would alert the staff to their problem.
But a developer's relationship with Apple is much more the former than the latter. (I file really awesome bug reports for other software I use, like OmniGraffle or Arq.)
It's also important to note that I didn't begin with this attitude; I ended up with it after filing dozens of detailed Radar bugs over the years, and evaluating how shitty the response from Apple is.
As others have pointed out, if a developer spends 5+ hours isolating a crippling bug in your shit[1], and filing it with a repro case[2], and you don't even have the courtesy to let them follow changes to the bug when it's marked as a duplicate, then well... you're kind of a rude and arrogant asshole. So developers become less likely to keep performing this service for you... unless they really really really want the bug fixed.
Some of these bugs affect our software critically, but we're completely in the dark about whether we should invest serious time and energy into providing our own workaround or leave it as it'll be fixed in the next Mountain Lion Preview.
This lack of communication is one of the worst things about being an Apple developer, and I fully support the community's efforts to try and persuade them to do better.
1. For security issues, use full disclosure. I received phone calls immediately when I included something like "disclosure in 30 days unless otherwise requested". Otherwise bugs were fixed in the next OS release a year later.
2. Otherwise: our Apple rep (.edu) told us that bugs were prioritized based on how many Macs you couldn't buy until it was fixed. Later, this changed to how the bug was preventing you from deploying iPhones (“iPhone: it's like sudo for Apple”) and I imagine this now includes iPads.
I love this so much. "Unless otherwise requested". Perfect.
Developers aren't their primary concern. Look at Xcode for crying out loud (and wonder at its magical ever-crashing nature).
Your project is corrupt. You're doing something wrong. Look to a professional for assistance with your IDE.
Xcode will crash.
I guarantee you that there is no professional programmer anywhere in the world that has used Xcode to write and compile their applications for 3 years and not had it crash. So your experience would suggest that you aren't one.
How about the lack of ANY refactoring support emphasis on ANY, the joke that is autocomplete, the atrocious file management, the complete lack of preferences, the way SCM destroys project, the inane approach to compiler flags. And don't even start on the index.
Honest to god. I swear the XCode team must be stuck in the 80s still listening to walkmans.
If you file a new bug with Apple, publish it here as well. No more black hole, you can see what others have already posted. You can even see what duplicates are about (if the original bug was also at open radar).
- Developers have a place that they can report things which is industry best practice
- They don't need to put in as much money to staffing it
If it's a big enough issue then they'll hear about it through other channels.
(EDIT: formatting)
However, as a developer, I'm going to be trying my hardest to pressure Apple into making my life easier, and the more people doing the same the better. Just because they can get away with this sort of thing, and it makes logical sense for them to do so doesn't mean that's the way things have to stay. A better ecosystem for Apple developers is a better ecosystem for their end-users, down the line, anyway.
I think some people aren't paying much attention to Apple's products. They tend to add new features pretty quickly so doesn't leave much time for non showstopper bugs.
The entire reason of letting people add bugs is that they can be tracked, if the submitter can't track it then why would they want to add it? If you can't see a perceived benefit then you're going to lose interest in reporting the bugs which in the long term is bad for the overall package.
Basically over some threshold you'll get conflicting behaviour expectations, duplicates formulated differently so they cannot be linked, QA finding more tiny issues in every release than bugfixes going in, etc. At least that's what I've seen so far from both open and closed projects.
(wxWidgets still takes the cake, asking me if the bug still exists after ~8 years since initial report)
500+ developers so far have submitted this to Apple.
Here are my stats from Radar:
4 Open - All over two years old.
7 Duplicate
1 Closed - The only one I got a response back on, and that Apple said was fixed.