Headline buries the lede imo, should be "Xcode slows down builds by constantly phoning home". Given the walled garden nature of Apple and the app review process it's not really surprising that Xcode would be full of forced telemetry
Also not the worst thing for Apple to measure average build times or whether developers are discovering some new feature they added, that can be actually helpful for improving the product.
> Also not the worst thing for Apple to measure average build times or whether developers are discovering some new feature they added, that can be actually helpful for improving the product.
That have always been the point of telemetry. The issue is when it’s hidden and /or the collected data is misused.
Or even used at all. Feels like a lot of telemetry is getting collected simply because it can. "What if there is value we could unlock?!" Never mind that all decisions will be made on a manager's gut instinct.
a) There is no correlation between a walled garden and telemetry. I use plenty of open source software that asks for analytics and crash reports. In fact I take it as a positive sign as it means they are committed to making a better product.
b) In this case the provisioning profiles are essential to the build process so it makes sense for Apple to check for updates as you are building.
> Also not the worst thing for Apple to measure average build times
There's no evidence that Apple is measuring average build times. As the screenshot in the article shows, gather provisioning inputs is actually one of the earliest build phases. Moreover, build time is not a useful measure, because it depends crucially on the number of source files, the programming languages, clean vs. incremental builds, run script build phases, and various other factors that vary almost infinitely from project to project.
The article does not even claim that the connections are telemetry. Gather provisioning inputs is without a doubt exactly what it says it is. Nonetheless, it's not necessary for Xcode to gather provisioning inputs on every build, especially not for non-archive builds, and a side effect of doing it on every build is that Apple receives personally identifiable data about developers and their everyday activities, regardless of whether that was Apple's intention.
There appears to be a common assumption that every privacy violation has to be intentional, some kind of conspiracy, but that's not true. A lot of privacy violations are just thoughtlessness, laziness, or incompetence. That doesn't excuse them, however.
I sincerely don't understand how devs that use macOS put up with this crap. I remember getting a Macbook M1 from the company I used to work for and the battery life was amazing, but as soon as I needed to install Xcode I just gave up. It's unbelievably bad, fuck that.
At the risk of nitpicking, Xcode isn’t explicitly necessary unless you’re looking to target iDevices specifically. A minimal llvm/clang toolchain can be installed with a terminal command or Homebrew.
And “unbelievably bad” is how I feel when trying to get various projects built from source on any platform all too often. If I’m lucky the maintainer has made a point of getting up and running a matter of running a couple commands but all too often there’s a mountain of assumptions about the user’s environment that cause the build to fail, sending me down rabbitholes. At least with SwiftPM Xcode projects, building is usually as simple as opening the project and hitting ⌘R and doesn’t involve a side trek to Mordor.
It's not even necessary for iDevices. I have successfully built, signed, and deployed simple apps without Xcode at all, using Bazel. I think CMake has support as well.
I've just reinstalled a PC with windows and coming from macOS and about 10 years of XCode, I certainly prefer the mac camp over the absolute smouldering hot garbage of a wasteland that the windows ecosystem is.
Just the BIOS settings nightmare I had to get through for it install Windows properly was beyond belief. I guess OEM installs have won. But building your own hardware like "back in the days", oh the sweet sweet old days, what a nightmare.
My BIOS even has AI in it (WTF).
Even Microsoft holds its own debloating list [1]! How bad is that?
I tried to clean windows right after install and that took much longer than setting a brand new mac. And the macOS doesn't cost $150, for ad-riddled cortana/AI nightmare feeding my clicks to random houses and shipping with minecraft and king.com games!
At some point, "both camps" have to agree to disagree but there are lot of rose tinted glasses everywhere.
The issue here isn’t the telemetry itself but the fact that it’s making builds slower.
I think Xcode is pretty inefficient and Apple makes assumptions about computer and internet speed that mask these issues for them. I once tried opening a project on a network volume and it was unusable because for some reason Xcode is constantly using the disk, which you probably would never notice on a project stored locally on an SSD.
This “gather provisioning inputs” step completely prevented me from building a project of mine yesterday. I let it sit there for over 20min with no movement. No amount of rebuild attempts worked, nor did restarting Xcode. Only a full reboot of my machine fixed it. I didn't see any network issues at the time this was occurring.
Coincidentally, looking for a trustworthy open source Web browser solution (I'm on a rampage this weekend, after Mozilla misalignment last straw), I just had to allude to what seemed like Apple's attitudes towards developers ranging from indifference to hostility, throughout the iOS developer experience:
(I'm sure there are some great people working on parts of Apple, and doing great work. But would they say that the holistic experience, as well as various business moves by Apple, are currently third-party developer-friendly? With the platform power Apple wields, and often heavy-handedly, I think that needs to be acknowledged.)
Readit News
Also not the worst thing for Apple to measure average build times or whether developers are discovering some new feature they added, that can be actually helpful for improving the product.
That have always been the point of telemetry. The issue is when it’s hidden and /or the collected data is misused.
b) In this case the provisioning profiles are essential to the build process so it makes sense for Apple to check for updates as you are building.
There's no evidence that Apple is measuring average build times. As the screenshot in the article shows, gather provisioning inputs is actually one of the earliest build phases. Moreover, build time is not a useful measure, because it depends crucially on the number of source files, the programming languages, clean vs. incremental builds, run script build phases, and various other factors that vary almost infinitely from project to project.
The article does not even claim that the connections are telemetry. Gather provisioning inputs is without a doubt exactly what it says it is. Nonetheless, it's not necessary for Xcode to gather provisioning inputs on every build, especially not for non-archive builds, and a side effect of doing it on every build is that Apple receives personally identifiable data about developers and their everyday activities, regardless of whether that was Apple's intention.
There appears to be a common assumption that every privacy violation has to be intentional, some kind of conspiracy, but that's not true. A lot of privacy violations are just thoughtlessness, laziness, or incompetence. That doesn't excuse them, however.
And “unbelievably bad” is how I feel when trying to get various projects built from source on any platform all too often. If I’m lucky the maintainer has made a point of getting up and running a matter of running a couple commands but all too often there’s a mountain of assumptions about the user’s environment that cause the build to fail, sending me down rabbitholes. At least with SwiftPM Xcode projects, building is usually as simple as opening the project and hitting ⌘R and doesn’t involve a side trek to Mordor.
The IDE itself is pretty good and personally I prefer it over Android Studio.
Just the BIOS settings nightmare I had to get through for it install Windows properly was beyond belief. I guess OEM installs have won. But building your own hardware like "back in the days", oh the sweet sweet old days, what a nightmare.
My BIOS even has AI in it (WTF).
Even Microsoft holds its own debloating list [1]! How bad is that?
I tried to clean windows right after install and that took much longer than setting a brand new mac. And the macOS doesn't cost $150, for ad-riddled cortana/AI nightmare feeding my clicks to random houses and shipping with minecraft and king.com games!
At some point, "both camps" have to agree to disagree but there are lot of rose tinted glasses everywhere.
[1] https://github.com/microsoft/windows-dev-box-setup-scripts/b...
Because you can't debloat a Mac since bloat is part of a protected system partition, so time saved?
I think Xcode is pretty inefficient and Apple makes assumptions about computer and internet speed that mask these issues for them. I once tried opening a project on a network volume and it was unusable because for some reason Xcode is constantly using the disk, which you probably would never notice on a project stored locally on an SSD.
From my three years of experience as a developer of iOS applications, this is the root cause.
How the mighty have fallen
https://news.ycombinator.com/item?id=43224305
(I'm sure there are some great people working on parts of Apple, and doing great work. But would they say that the holistic experience, as well as various business moves by Apple, are currently third-party developer-friendly? With the platform power Apple wields, and often heavy-handedly, I think that needs to be acknowledged.)