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.
Everything Apple constantly phones home. (It wasn't always this way.) Will the blog author switch away from using Apple computers and writing software for them. No doubt he has some convincing list of excuses.
Not really, iOS does network magic over the wire.... back in the jailbroken days you could launch a daemon on the phone and it paired with a local app via WiFi to allow wireless debugging.... they did what apple does and rolled that feature in later on.
I think the comments are clear enough - but if interested take a moment and proxy connections from all devices and you'll witness your every move being sent out.
When Apple talks about respecting your "privacy" it's isn't true as they permit most api grabbing your data from model, location, time, actions and so.
This is still bad, When I'm developing I'm building many times during the day but uploading to appstore or TF maybe once a week. And thats as a freelancer if someone part of big team probably uses dedicated CI and special services for releasing build.
Same it shouldn't phone every time I open project files, what for? It would be also enough if phone home when openning Xcode once every 5 days unless dev manually ask for checking updates.
Yes and no. "Constantly" in the title means "with regular occurrence", like, I'm constantly being a pain in the neck with my word explanations. And the "constantly" you mean is more like "continuously". And you are both right, it's just that language in imprecise.
if you are an apple ecosystem app developer, apple already has an awful lot of information about you. you've paid them $100 every year, you pay them at least a 15% cut of every sale. they know your personal address one way or another, and your tax information. you most likely use their IDE, their APIs / development kit, which either they provide or you are paying for as part of our $100 developer fee, depending on your perspective. to get an app on any official Apple App Store you have to submit your app to them to notarize and get it reviewed for approval. you probably use an iPhone, essentially must use a Mac, and have a robust billing history in their stores.
so I'm not sure I totally understand the underlying message here, that apple is possibly phoning home to App Store Connect to secretly record every time a developer launches a project? it sounds a bit strangely conspiratorial in the context of a system where apple controls the entire developer supply chain already. anyway, I understand this is just one of those things that some people decide to care a lot about, and in some cases it makes a lot of sense, but not this one.
It may be poorly engineered and slow, but I don’t see this blog post say it’s poorly engineered, and only that it’s slow for this user.
For all we know from this article, that this step takes 50 seconds could be fairly specific for this user’s setup. If so, this would the kind of issue that can easily slip through QA.
There's a huge difference between having my home address, which a lot of people do, and observing my activity all day while I'm in the privacy of my home.
To turn it around, Apple publishes its own corporate address but is extremely secretive about what goes on inside the building and does not appreciate leaks.
> apple is possibly phoning home to App Store Connect to secretly record every time a developer launches a project? it sounds a bit strangely conspiratorial
It's not a conspiracy. It's just a complete disregard for developer privacy from a company that claims "privacy is a human right". There's a difference between doing something bad on purpose and doing something bad simply because you don't give a crap about the effects.
> I understand this is just one of those things that some people decide to care a lot about, and in some cases it makes a lot of sense, but not this one.
What is not sarcasm, that I once lived in a region in germany where apples are grown. The local government had a project where they created some hiking trails. They wanted to call one of those "Apfelweg" (apple street or s.th. in englisch), because you know, there are apple trees everywhere. They had been sued by apple and had to rename it. Real.
Oh but it's by far not the single instance of fruit related abuse: https://www.popsci.com/technology/apple-swiss-trademark/ No matter how much you like their products, Apple is just another corporation playing the corporate abuse card.
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-...