4 ms·

I blame strongly Apple’s inability to make developer-focused tools easy and unbreakable. For instance: - I do not file bugs anymore. Their system is absurdly

I blame strongly Apple’s inability to make developer-focused tools easy and unbreakable. For instance: - I do not file bugs anymore. Their system is absurdly complex, requiring a lot of information up front, and is then 100% opaque. Bugs stay marked New and untouched for months or longer, only to be closed with Duplicate or some other lame status (with absolutely no way to search or read the apparently-similar bug reports to understand the issue and resolution). If their goal was to ensure no real participation in the process of helping their products become better, they’ve succeeded. - Xcode 9.x routinely has failing background processes, even in response to explicit actions, and not just for obscure features. 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; I have to Clean and Build to be absolutely sure! - Xcode 9.x failures are somehow better than Xcode 8.x failures where Literally. One. Second. Can. Pass. In. Between. Every. Character. You. Type. Then, SourceKit can enter an unending failure loop, to the point where Xcode must be restarted lest you have to click OK on errors every second. And you would think I could simply move on to Xcode 9.x but 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. Apple is showing signs that a split into sub-companies would be useful (kind of like Claris/FileMaker Inc.). There’s no particular reason why things like bundled apps couldn’t just become preferred 3rd-party downloads from the App Store, where spin-off companies make iThis/iThat or even things like Photos. If that happened, Apple would be forced to actually communicate with several entities on a regular basis and improve their external-facing tools. You can bet that SpinOff, Inc. would not stand for having major problems with developer tools or SDKs for instance.

on_and_off 9y ago
I would love this split especially since being unable to specify a default app for many actions on iOS is a pain IMO (one of the big reasons I don't use an iPhone right now).
Improvotter 9y ago
> I do not file bugs anymore. I've filed a small amount but stopped pretty quickly because the web app where you report bugs is just horrible. I literally ended up making 2 bug reports the first time, 1 for the bug I wanted to report and then another bug report for the web app. I can't even be bothered to check whether those issues have been resolved, but I don't even care anymore at this point.
- eridius 9y ago
  How long ago was this? They revamped their external-facing bug reporter fairly recently.
eridius 9y ago
> I do not file bugs anymore 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.

on_and_off 9y ago

I would love this split especially since being unable to specify a default app for many actions on iOS is a pain IMO (one of the big reasons I don't use an iPhone right now).

Improvotter 9y ago

> I do not file bugs anymore. I've filed a small amount but stopped pretty quickly because the web app where you report bugs is just horrible. I literally ended up making 2 bug reports the first time, 1 for the bug I wanted to report and then another bug report for the web app. I can't even be bothered to check whether those issues have been resolved, but I don't even care anymore at this point.

eridius 9y ago
How long ago was this? They revamped their external-facing bug reporter fairly recently.

eridius 9y ago

> I do not file bugs anymore 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.