Xcode constantly phones home
lapcatsoftware.com
lapcatsoftware.com
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.
And surely we can all agree that a data driven approach is better than gut instinct.
Then when people do the right thing, or have a good instinct about what to do next, we call them leaders (if they succeed), and praise them. Like Steve Jobs.
If the same people fail, even with the data on their side, we kick them down, set on fire and parade them for their failure.
So does firing from the hip, so what? And I'd wager firing from the hip has a higher failure rate. At least by using data I have an actual argument for my position, other than "but muh feelings!" My CEO doesn't give two shits about how I "felt" the project would go, and I can't imagine how poorly that discussion will go when we meet to review what happened.
At the end of the day the companies that are succeeding and growing are using data to inform their decisions.
Is there data to support this conclusion, or is it just your feelings?
Plenty of places mask violating peoples' privacy as "analytics data" to drive decisions about how to manipulate those and other people.
> surely we can all agree that a data driven approach is better than gut instinct.
Generally, sure, but not always. How you get that data matters. Violating someone's privacy is unethical. Violating someone's privacy to make data-driven decisions is still unethical. Telemetry without knowledge or consent to it is violating privacy.
> Plenty of places mask violating peoples' privacy as "analytics data" to drive decisions about how to manipulate those and other people.
Are you talking about a different group of places? Or is this your view of places that collect telemetry?
Do you use Xcode? Are you aware of Apple’s telemetry disclosures? How do you feel that Xcode telemetry has ever or could ever be used to manipulate people? How do you feel peoples privacy has been violated? Do you want to re-state your point in a more concrete way instead of saying something that basically amounts to “I’m upset, so it’s bad!”
I hate rent-a-crowd privacy people.
My point is that telemetry violates developers' privacy. Whether that's in a consumer-facing app or in a developer-facing Xcode, it's still violating privacy and therefore unethical to use for data-driven decisions.
> is this your view of places that collect telemetry?
Yes
> Do you use Xcode?
No, because I don't use macOS.
> Are you aware of Apple’s telemetry disclosures?
Are you? How many developers using Xcode are aware of those disclosures? How many developers using Xcode are forced to use Xcode by their employer and therefore cannot have reasonably agreed to anything?
> How do you feel that Xcode telemetry has ever or could ever be used to manipulate people? How do you feel peoples privacy has been violated?
Monitor who builds what kinds of applications and then use that information to decide what products Apple should focus on. Monitor who tries to compile. Tie their name to "security" or "authenticity". Monitor how those built applications are used or distributed, and then change compilation processes to suit Apple's walled garden.
> Do you want to re-state your point in a more concrete way instead of saying something that basically amounts to “I’m upset, so it’s bad!”
My point was already plenty enough concrete. You just simply decided to ignore it because you hate privacy-focused people, and summarily dismiss it as "being upset" instead of addressing any of the issues that were brought up.
1) The “drunk looking for his keys under the street light“ problem. There is a human inclination to limit the scope of thought to what is visible.
2) The inclination to look for data that supports your conclusions. This is the real intractable problem. For most people, gathering data is a fetch quest for what they want to do anyway. It’s a big problem for academics doing “real science”. In a company where many are trying to launch, get the promotion and move onto another job, (without even the veneer of a check through peer review) it’s an even bigger problem.
This isn’t exactly a replied to your post I know, but I see that everyone else is using your thread to bring up there quibbles with data driven decision-making, so I thought I’d do the same cause I don’t see anyone making these points
Is "gut instinct" better or worse than "data driven approach with a bunch of implicit data collection"? Is "data driven + implicit data collection" better or worse than "slightly less good data but explicit data collection"? Is that worse or better than "qualitative user interviews to drive decision making despite that only capturing a subset of users"?
Nobody wants their apps to be badly designed, insecure, slow, crash all the time, and hard to use. Nobody wants their app to be bad. So then you're choosing how you make your app good. And you choose how much you care about each axis while working on things.
Nobody wants their app to be bad.
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.
The IDE itself is pretty good and personally I prefer it over Android Studio.
If it's my reaction to the use of Xcode then I've associated a stress response and get anxious which is partially why I left my job. The tool was also, in my experience, not a smooth or enjoyable developer experience.
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.
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?
Second, Windows doesn't have it in the same crypto-protected-risk-breaking-boot way, there are well documented ways on debloating Windows both before and after an install.
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.)
Can be turned off by the user usually means you must run your own recursive DNS resolver and firewall
Please note that some Visual Studio Code extensions have licenses that restrict their use to the official Visual Studio Code builds and therefore do not work with VSCodium.
...
In some cases, ... [workarounds] won't help because the extension is hard-coded to only work with the official Visual Studio Code product.
[0] https://github.com/VSCodium/vscodium/blob/master/docs/index....
> I doubt it slows down builds
But we don't really know, do we? Speculation isn't helpful.
Although the title was not changed, if you don't read the actual post, it's misleading.
It makes connections to Apple when you launch it, and when you open project files.
It also makes connections when you build, although that is to be expected, since signing is required for uploading builds to the store.
It does not "constantly" phone home.
As a user, I wouldn't expect any of this kind of telemetry, at least out of the box without opting in to it.
Hi, welcome to our timeline.