Makes sense, and it is annoying, but there’s a lot of annoying stuff in Xcode. Looking at the console can get rather depressing. There’s a lot of “noise” in there, that is basically sound and fury, signifying nothing. I get tired of googling errors and warnings (I compile -wall, and take every warning seriously), only to realize they are meaningless “background noise,” due to the system trying to generate code for platforms other than the target, for instance. In those cases, Xcode usually won’t interrupt the build, just spit out an annoying warning.
Xcode is a huge, chimeric monster. I seriously doubt there’s anyone, anymore, that really knows what’s going on under the hood. It’s larger than many games, which says a lot.
That said, I regularly use it to produce fairly concise, performant applications, and I can bear the pain.
Here’s an example of me encountering an annoying warning[0], and being told “you’re holding it wrong.” I was basically chided for my style, which, I guess, is one PoV, but I feel didn’t actually answer the question, and, in my opinion, is pretty much irrelevant to the point.
> Looking at the console can get rather depressing
Opening Console and watching critical error messages stream in at an alarming rate when you do basically anything in the entire OS, is a great way to remind yourself just how bad Apple’s software quality has gotten. They're absolutely drowning in bugs.
I just opened it, after waking my laptop up from sleep, and about 10,000 errors+warnings have streamed in in the past 30 seconds or so. I'm doing nothing, just a single Safari window with this tab and nothing else going on.
(It would be interesting to see a graph of “errors per second while doing nothing” over each yearly release.)
I'm getting really fed up with all the bugs in Sequoia in particular. I know the usual advice is to not upgrade macOS major versions until .1 or .2, but we're up to 15.3.1 now and it's still terrible.
I hate to be pessimistic but I have to agree. I have filed a number of bug reports, about Logic Pro for example. I try to be detailed and a number of them should have been real gimmes, but it seems that half the time somebody just asks for a crash dump or example file to ignore it.
The example warning is the Swift language warning about style conventions, there's an interesting conversation about whether enforcing style conventions through warnings is appropriate, but that's is a Swift language question, not an Xcode question.
For you maybe. Why it makes sense ? Are Xcode developers not able to test their code ? Does Apple need to know who you talk to, what are you writing or what did you eat ?
I like to ship, and that requires a lot of interaction with Apple servers.
Provisioning is a pain, and, speaking only for myself, I'm fairly happy that Apple has made that easier (by doing a lot of the handshake behind the scenes).
But, yeah, if you don't want to ship, then you probably only want interactions for things like documentation and dependency versioning.
I mean you're going to tell me that this a rehash of what the Stack Overflow people told you but the reason this is a warning is because the external name is meant to aid in readability but the internal name is the one that is actually operated on, so the latter is the one that is actually relevant when documenting what the thing actually is. It would be unreasonable to write documentation for a parameter called "in" (internal name: range) or "behind" (internal name: window). So yeah, you're holding it wrong. If you disagree you should do one of two things:
1. Ask for a way to use the external name as documentation. (This is not a serious suggestion, because if you go do this people will laugh at you and tell you to stop doing that. But you could do it.)
2. Ask for a way to turn off warnings. (This is a reason suggestion, I actually want this. Unfortunately the answer that you really want is "no you can't do this".)
Yeah, you can look at it that way, but API documentation is for external users, and I prefer to reduce the number of inline comments, inside the function, which is not where the external users will be going, anyway.
Most folks will only care about the external name. The internal name is for maintainers. It not only indicates the value is a constant, it also tells you that it has not been altered since entering the function body, and that's pretty important. The "in" prefix regularly saves me from assigning the unprocessed value, instead of one that has had some conditioning applied.
No matter. As long as the warning doesn't bork the build, I can live with it.
I could probably provide protocols for API documentation, but protocols have their own issues[0].
Another annoying Xcode feature is that building a macOS app with Xcode command line tools (xcodebuild) sometimes complains that my iPhone is locked:
"An error occurred whilst preparing device for development -- Failed to prepare the device for development. Domain: com.apple.dtdevicekit Code: 806 Recovery Suggestion: Please unlock and reconnect the device. The device is locked. Domain: com.apple.dt.MobileDeviceErrorDomain"
For those that don't understand exactly how annoying this is, I once took the time to reverse engineer Xcode to figure out exactly where it was coming from and then inject code into it to make it shut up: https://github.com/saagarjha/dotfiles/blob/master/xcodebuild...
I usually avoid logging in to xcode. I prefer to manually configure provisioning profiles and code signing certificates by hand in the developers.apple.com web interface anyways. You can use xcodebuild on the command line to get a signed ipa, and then you can use altool or application loader to upload the ipa to appstoreconnect. I don't trust xcode to not stomp all over my carefully configured provisioning profiles and app ids.
I have never once trusted xcode to get provisioning profiles and certificates right.
It's always manual for me, at least that way xcode won't suddenly tell my app is not registered to a team and refuse to build.
I know it's not relevant to the discussion, but I want to voice publicly how much I loathe the build error system in XCode. How can they possibly think anyone will find their obtuse and downright impossible log system is helpful.
15 years back I used to work somewhere that had an entirely separate engineering network with no route to the Internet. And a build room that was physically airgapped. All for good reasons. Xcode worked fine.
I wonder how they do it now. I imagine Apple’s requirements have made it a lot more complicated.
At some point I tried scripts aiming to disable daemons and firewall blocking MacOS stuff phoning home constantly (especially since I use no iCloud stuff) to make my system run a little leaner. But macOS is just such a complicated blackbox I just forgot about it... :(
Another annoying "phone home" happens when you try to run an app on an iOS device with xcode: the iOS device needs internet to call Apple to verify the app, even though it has just been built and signed with an attached xcode. Eventhough it is just from time to time, this is highly annoying because you can't always work on developing/testing your app offline.
Readit News
Xcode is a huge, chimeric monster. I seriously doubt there’s anyone, anymore, that really knows what’s going on under the hood. It’s larger than many games, which says a lot.
That said, I regularly use it to produce fairly concise, performant applications, and I can bear the pain.
Here’s an example of me encountering an annoying warning[0], and being told “you’re holding it wrong.” I was basically chided for my style, which, I guess, is one PoV, but I feel didn’t actually answer the question, and, in my opinion, is pretty much irrelevant to the point.
[0] https://stackoverflow.com/questions/79275128/is-there-a-way-...
Opening Console and watching critical error messages stream in at an alarming rate when you do basically anything in the entire OS, is a great way to remind yourself just how bad Apple’s software quality has gotten. They're absolutely drowning in bugs.
I just opened it, after waking my laptop up from sleep, and about 10,000 errors+warnings have streamed in in the past 30 seconds or so. I'm doing nothing, just a single Safari window with this tab and nothing else going on.
(It would be interesting to see a graph of “errors per second while doing nothing” over each yearly release.)
For you maybe. Why it makes sense ? Are Xcode developers not able to test their code ? Does Apple need to know who you talk to, what are you writing or what did you eat ?
I like to ship, and that requires a lot of interaction with Apple servers.
Provisioning is a pain, and, speaking only for myself, I'm fairly happy that Apple has made that easier (by doing a lot of the handshake behind the scenes).
But, yeah, if you don't want to ship, then you probably only want interactions for things like documentation and dependency versioning.
1. Ask for a way to use the external name as documentation. (This is not a serious suggestion, because if you go do this people will laugh at you and tell you to stop doing that. But you could do it.)
2. Ask for a way to turn off warnings. (This is a reason suggestion, I actually want this. Unfortunately the answer that you really want is "no you can't do this".)
Most folks will only care about the external name. The internal name is for maintainers. It not only indicates the value is a constant, it also tells you that it has not been altered since entering the function body, and that's pretty important. The "in" prefix regularly saves me from assigning the unprocessed value, instead of one that has had some conditioning applied.
No matter. As long as the warning doesn't bork the build, I can live with it.
I could probably provide protocols for API documentation, but protocols have their own issues[0].
[0] https://littlegreenviper.com/the-curious-case-of-the-protoco...
Deleted Comment
"An error occurred whilst preparing device for development -- Failed to prepare the device for development. Domain: com.apple.dtdevicekit Code: 806 Recovery Suggestion: Please unlock and reconnect the device. The device is locked. Domain: com.apple.dt.MobileDeviceErrorDomain"
Dead Comment
It's always manual for me, at least that way xcode won't suddenly tell my app is not registered to a team and refuse to build.
I know it's not relevant to the discussion, but I want to voice publicly how much I loathe the build error system in XCode. How can they possibly think anyone will find their obtuse and downright impossible log system is helpful.
I wonder how they do it now. I imagine Apple’s requirements have made it a lot more complicated.
there is a couple other obnoxious ones i cannot recall right now