I once had an interesting experience when visiting Apple. I was telling a DTS engineer about a gnarly bug in the Cocoa text system I had found (certain text editing sequences would silently corrupt the undo stack; user might not notice until they accidentally did a select-all and delete, and then tried to undo to get their novel back).
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.
I find the toilet analogy to be flawed. Sure you don't fix their toilets for free, but you would certainly let someone know if you used one of their facilities and found it to be clogged or otherwise malfunctioning.
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.
Well no, to be honest, I certainly don't do that. If I am at say, Moscone Center or a Wal-mart or a low-rent casino, and a toilet is clogged with shit, I don't go wandering around to hunt down a maintenance man and report it to him. I just use another stall.
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 reallyreallyreally want the bug fixed.
We (my company) have filed quite a few radar bug reports, including one quite serious flaw (account passwords being sent across a network in plaintext serious). We never heard a squeak back. We never know if they have, or will ever be fixed in a future release.
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.
I've filed many bugs with Apple over the years. There are two strategies which work:
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.
Seriously the crashing is what amazes you about XCode ?
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.
You're not using Xcode. I mean Really Using Xcode. Like making a serious attempt at exercising its features. Hell, you really don't even have to do that. Create a project, edit some code, compile and run your app. That's usually fine. Now, try repeatedly, several times a minute for eight hours straight to use the debugger on your app (intentionally overrelease something or create some other reason for Xcode to launch lldb when your app crashes.)
LOL. For the same reason, Microsoft Powerpoint has never crashed for me in 3+ years. (Because I haven't used it in 3+ years.)
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.
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).
Did anyone else click on the link hoping for a nice juicy technical article about RADAR (http://en.wikipedia.org/wiki/Radar) and not some whining about a piece of software that would have been fixed by now if it was open source?
This is exactly why action on the part of developers is a good idea. Obviously Apple doesn't need to fix it, the current system is serving them well enough. Apple's target market are its users not its developers, and that's fine.
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.
If you file a bug report on Radar, unless you know someone at Apple who you can give the Report ID to, it is unlikely to be dealt with quickly. Seems like they don't have a dedicated team overlooking it.
This is definitely false: they respond quickly with initial triage. The main problem is that you will subsequently almost never hear anything from them and if your issue was reported as a duplicate you'll need to manually poll them over email for the status.
Actually from what I saw on the OSX project the bugs were triaged pretty quickly by the Engineering Team. The problem is that you don't really get any feedback when it happens. And often the triage reason is technical so they can't really share it.
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.
I don't this is specifically an Apple issue either, I've filled bug reports on quite a few different projects (mostly open source) including at least one that's a full application framework and rarely do they ever move into 'confirmed' or 'accepted' status.
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.
I believe that at a certain size of the project you will get more incoming bugs than you can handle. Doesn't matter if it's closed/open source, who the users are or anything else. It's just a matter of the number of users / size of QA.
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)
True, it's definitely a case where eventually the number of bugs becomes incredibly difficult to manage but it's still essentially training people to not report bugs if they can't see even the smallest amount of traction on it.
Agreed. When I would Google about Windows / Visual Studio problems, I would get an instant feeling of futility when the "connect.microsoft.com" page design appeared. I don't think I ever saw a conclusion that wasn't a generic "we'll consider this for the future" or "won't fix" type thing.
The problem is that you can't get real tracking on your business critical bugs because Apple just marks them as duplicates. And once it's a duplicate, you can't see the status, so you never know if it's actually fixed. So why even bother reporting bugs?
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.
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.