> Their system is absurdly complex, requiring a lot of information up front
Not really. Everything it asks for is useful information. It used to have a bunch of fields that, depending on the bug, you sometimes ended up just writing N/A in, they recently re-did the bug reporter interface so all of those free-form text areas are now a single text area pre-filled with a template, which makes it a lot easier to trim out an irrelevant section. And it's a lot faster than it used to be as well.
> Bugs stay marked New and untouched for months or longer, only to be closed with Duplicate or some other lame status
When was the last time you actually filed a bug? My dupes are generally marked as such in less than a week (presumably whenever the next bug review session happens, which is usually on a weekly cadence), and many times they get marked as such within one day. I can't remember the last time I had a non-brand-new bug get marked as a dupe.
> with absolutely no way to search or read the apparently-similar bug reports to understand the issue and resolution
This is true. You can, however, post a comment on your dupe asking for an update.
Radar is mostly a black hole. This is just something you have to deal with. But that doesn't mean you shouldn't file bugs. If nobody files a bug report, then the bug will never get fixed. And I've lost track of the number of bug reports I've filed that have actually been fixed as a result of my report (e.g. I get asked to confirm the fix later).
---
> For instance, an ordinary build seems to spawn background tasks that frequently display old errors as new errors, only to mysteriously produce a “Successful” build while still showing all those older errors
Those errors aren't from the build. Those errors are from the "live issues" feature. Xcode does have an issue where a successful build often doesn't actually clear out the "live issues", but you don't need to clean to get rid of them! Just modify the line in question (e.g. add and delete a space), that will clear out the issue and force it to re-perform the "live issues" compilation check. I do hope that some day Xcode will get better at handling this. Perhaps you should file a bug report.
> I can’t stop using Xcode 8.x due to other developer-unfriendly decisions Apple makes, such as ending support for SDKs or changing compilers in backward-incompatible ways, where using the Xcode 8.x suite (faults and all) is unavoidable.
Why do you need an older SDK? The only reason I can think off the top of my head to need the iOS 10 SDK instead of iOS 11 is if you're developing an iOS app, using a launch storyboard, and aren't prepared to support the iPhone X. I do wish Apple had a way to opt out of iPhone X support with Xcode 9 (e.g. an Info.plist key), but honestly, it's been months at this point since Xcode 9 came out, you should just spend the effort to support iPhone X. If you actually need the iOS 10 SDK for another reason, I'm quite curious as to what it is.
What are you referring to regarding "changing compilers in backward-incompatible ways"? I have to assume you mean the Swift compiler, but the transition from 3.1 to 3.2 is pretty painless. In most cases it should just work with perhaps a few warnings thrown in. I only know of a few edge cases surrounding Substring that are actually backwards-incompatible, but those are easy to fix.
Bug reporting and other forms of feedback are time investments, which are not cheap. If those investments seem to go nowhere, I reinvest in things that do go somewhere (like work-arounds). Of course a lack of reporting means that bugs won’t necessarily be fixed. Part of my point is that unfixed bugs making it into public releases is not surprising, given Apple’s lack of investment in their tools.
Apple needs to make highly-visible changes to draw contributors back, such as a giant and reliable search feature, publicly-visible lists of bug reports, and public comment threads on everything (as a start). Otherwise, if I’ve already been burned many times before, why would I keep wasting time submitting bugs into a black hole?
Xcode builds need to work without any compromises. I didn’t mention Xcode because I need a work-around (and frankly, “add and delete a space” should never be a reasonable thing to have to do). I mentioned Xcode because its glaring list of bugs can only lead to conclusions that are bad for the platform: maybe it means “we don’t know what we are doing”, or maybe it means “we don’t care about developers”, or maybe it means “we barely use our own tools”; not good.
Radar is never going to be public. There’s too much sensitive information in there, and tons of bugs submitted every day that contain sensitive info. People include all sorts of info, such as closed-source source code, that they wouldn’t do if it was public. Not to mention a lot, if not most, of the reports are filed by Apple engineers and those definitely wouldn’t be public even if external ones were.
But not being public doesn’t mean filing reports is useless! Even duplicates are useful. Bugs are fixed all the time using information found in duplicates.
Regarding Xcode, it’s got bugs, but it is a pretty good IDE all around, and it’s constantly getting better. Hell, Xcode 9 has a brand new awesome code editor (though it’s missing my favorite feature, focus follows selection, and I hope that comes back soon!) in addition to a lot of other improvements, and you’re trying to claim they’re not investing in their tools? Just because you apparently can’t use Xcode 9 for ill-defined reasons doesn’t mean they don’t care or aren’t using their tools!
There are tons of ways to deal with sensitive data that don’t require hiding the entire bug reporting system. One is to allow links to things that not everyone can see (e.g. internal web sites or protected repositories) but still making the bug report itself and the comment thread entirely public and searchable. A lot of times, all I really need is a quick way to understand that someone else in the universe has my problem and that it’s being worked on.
I’m not even saying duplicates are useless. I’m saying that Apple’s method, taking months to ultimately communicate nothing except an unexplained status of “Duplicate”, is useless. Except it’s worse, because at that point I would have already: (A) painstakingly distilled a much more complex problem into a base test case purely for Apple’s benefit, (B) generated a system profile or whatever else was required, and (C) jumped through several other hoops. Also, during that whole time I must assume: the issue wasn’t known to Apple, hadn’t been seen yet by anyone else, and probably wasn’t going to be fixed; and, I required a work-around in the meantime that ultimately became the only solution that mattered.
Now, Xcode: it kind of doesn’t matter what else they’re doing when basic tools I need every day still have problems. In Xcode 4.x they reinvented their own window/tab manager and to this day I can’t get this “pretty good IDE” to put anything where it’s supposed to be and remember that next time. It still has problems automatically showing a source file and its header file side-by-side. Also, when I open projects explicitly, it likes to display a mixture of tabs showing source files from entirely different projects (a bug I actually did report, many many years ago, still unfixed). A tool that does some things right but fails with the basics is not a well-supported development environment.
The bug report and comment thread itself is sensitive. The only possible way they could do this is if there was a checkbox on externally-reported bugs saying "allow this to be public", but that will just move the goalposts, because maybe 0.0000001% of the bug reporter will end up public, and you'll still have your bugs duped to private stuff, and search will be almost entirely useless.
If you want public bugs, go look at OpenRadar. It's a website where people can opt into posting their Apple bug reports publicly.
> taking months to ultimately communicate nothing except an unexplained status of “Duplicate”
Hyperbolic much? As I already stated, dupes generally happen within a week, often within a day or two. In fact, I've filed well over a thousand bugs and I've had something get duped over a month later maybe once or twice.
> In Xcode 4.x they reinvented their own window/tab manager and to this day I can’t get this “pretty good IDE” to put anything where it’s supposed to be and remember that next time.
What do you mean? The window manager is not custom, and the tabs, if not actually the OS-provided tab functionality at this point, sure seems pretty close. In all my years of using Xcode it's never had a problem remembering how I set up my window.
> It still has problems automatically showing a source file and its header file side-by-side.
It does? I admit I don't use the automatic Counterparts feature very often, but it's always worked for me. What issues are you seeing?
> Also, when I open projects explicitly, it likes to display a mixture of tabs showing source files from entirely different projects
Again, in all my years of using Xcode, I've never even so much as heard anyone mention anything remotely like this. What the heck are you doing with Xcode to cause this to happen?
How can the entire report be sensitive? There’s always something that can become public, e.g. after sifting through a mountain of private data and finding Bug X in NSFooBar, file a bug on that and make that part public so the rest of us know.
Using OpenRadar regularly would even further increase the effort spent reporting bugs, and then: Apple doesn’t maintain it, Apple doesn’t check it, Apple certainly doesn’t synchronize with it, Apple does benefit greatly from it, despite Apple not accepting responsibility and providing a basic, foundational tool of its own.
This thread is starting to feel like a bug report in itself. Yes, everything behaves as I described, yes the issues were logged with Apple, yes it takes them months to respond sometimes (and I was being generous, sometimes it’s over a year), yes Xcode is still buggy in very obvious ways when doing very trivial things, and I’m even using recent Apple hardware and software.
Then your problems won't get fixed.
> Their system is absurdly complex, requiring a lot of information up front
Not really. Everything it asks for is useful information. It used to have a bunch of fields that, depending on the bug, you sometimes ended up just writing N/A in, they recently re-did the bug reporter interface so all of those free-form text areas are now a single text area pre-filled with a template, which makes it a lot easier to trim out an irrelevant section. And it's a lot faster than it used to be as well.
> Bugs stay marked New and untouched for months or longer, only to be closed with Duplicate or some other lame status
When was the last time you actually filed a bug? My dupes are generally marked as such in less than a week (presumably whenever the next bug review session happens, which is usually on a weekly cadence), and many times they get marked as such within one day. I can't remember the last time I had a non-brand-new bug get marked as a dupe.
> with absolutely no way to search or read the apparently-similar bug reports to understand the issue and resolution
This is true. You can, however, post a comment on your dupe asking for an update.
Radar is mostly a black hole. This is just something you have to deal with. But that doesn't mean you shouldn't file bugs. If nobody files a bug report, then the bug will never get fixed. And I've lost track of the number of bug reports I've filed that have actually been fixed as a result of my report (e.g. I get asked to confirm the fix later).
---
> For instance, an ordinary build seems to spawn background tasks that frequently display old errors as new errors, only to mysteriously produce a “Successful” build while still showing all those older errors
Those errors aren't from the build. Those errors are from the "live issues" feature. Xcode does have an issue where a successful build often doesn't actually clear out the "live issues", but you don't need to clean to get rid of them! Just modify the line in question (e.g. add and delete a space), that will clear out the issue and force it to re-perform the "live issues" compilation check. I do hope that some day Xcode will get better at handling this. Perhaps you should file a bug report.
> I can’t stop using Xcode 8.x due to other developer-unfriendly decisions Apple makes, such as ending support for SDKs or changing compilers in backward-incompatible ways, where using the Xcode 8.x suite (faults and all) is unavoidable.
Why do you need an older SDK? The only reason I can think off the top of my head to need the iOS 10 SDK instead of iOS 11 is if you're developing an iOS app, using a launch storyboard, and aren't prepared to support the iPhone X. I do wish Apple had a way to opt out of iPhone X support with Xcode 9 (e.g. an Info.plist key), but honestly, it's been months at this point since Xcode 9 came out, you should just spend the effort to support iPhone X. If you actually need the iOS 10 SDK for another reason, I'm quite curious as to what it is.
What are you referring to regarding "changing compilers in backward-incompatible ways"? I have to assume you mean the Swift compiler, but the transition from 3.1 to 3.2 is pretty painless. In most cases it should just work with perhaps a few warnings thrown in. I only know of a few edge cases surrounding Substring that are actually backwards-incompatible, but those are easy to fix.