I’m as suspicious as anyone of Apple’s “high regard” of privacy, but all of these accesses are legitimate.
App Store Connect is sending the bundle ID to Apple, to automatically fetch provisioning profiles based on your account.
The images domain is checking for newer versions of the iPhone, iPad, iThing, [etc.] emulators.
This isn’t some “mysterious boogeyman”, it’s all noted and in public. Frankly, anyone fussed enough about their bundle IDs being sent to Apple probably shouldn’t be developing for the Apple platform anyway, considering all the documentation they require to open an Apple Developer account these days. And if you don’t have an Apple Developer account, then you aren’t signed in, and none of this matters anyway as there is no identifiable information.
Yes, dissidents and activists should be aware of this, but I’d expect that sort of developer to run air gapped anyway. Not doing so is going to spell trouble from a lot more than a bunch of connections to Apple.
A lot of times when I am downloading little projects to play with from GitHub or wherever, rather than fire up Xcode I will use xcodebuild at the CLI just to test it out. I believe there are ways to do nearly everything from the CLI. One doubt I have is deploying to device; that might require the GUI. I’ve been meaning to look into it more.
I don’t use Mac and I won’t touch app development with a 10 foot pole so I can’t check, but just because it’s CLI-based doesn’t necessarily mean it doesn’t phone home. It’s still part of XCode, right?
For xcodebuild, no, it’s not doing anything network-related. It’s mostly an XML Xcode project parser and an LLVM frontend for building projects. Everything as far as dependencies (SDKs, headers, libraries, etc.) must exist on the filesystem but all of that is put there by “Xcode Command Line Tools” which can be independent of the Xcode IDE.
Doing device provisioning stuff for iOS/iPad is a different story, as that requires crypto-based profiles and certificates and such, which Xcode frontends and is much of this “phoning home”, as mentioned above.
But the configuration and building of projects and such still feels very UNIX-y with these CLI tools.
I’m as suspicious as anyone of Apple’s “high regard” of privacy, but all of these accesses are legitimate.
App Store Connect is sending the bundle ID to Apple, to automatically fetch provisioning profiles based on your account.
The images domain is checking for newer versions of the iPhone, iPad, iThing, [etc.] emulators.
This isn’t some “mysterious boogeyman”, it’s all noted and in public. Frankly, anyone fussed enough about their bundle IDs being sent to Apple probably shouldn’t be developing for the Apple platform anyway, considering all the documentation they require to open an Apple Developer account these days. And if you don’t have an Apple Developer account, then you aren’t signed in, and none of this matters anyway as there is no identifiable information.
Yes, dissidents and activists should be aware of this, but I’d expect that sort of developer to run air gapped anyway. Not doing so is going to spell trouble from a lot more than a bunch of connections to Apple.
It wouldn’t be as bad if you weren’t required to use XCode to even build anything targeting iThings.
But anyway, I suppose this sort of thing has become “the New Normal”.
A lot of times when I am downloading little projects to play with from GitHub or wherever, rather than fire up Xcode I will use
xcodebuildat the CLI just to test it out. I believe there are ways to do nearly everything from the CLI. One doubt I have is deploying to device; that might require the GUI. I’ve been meaning to look into it more.I don’t use Mac and I won’t touch app development with a 10 foot pole so I can’t check, but just because it’s CLI-based doesn’t necessarily mean it doesn’t phone home. It’s still part of XCode, right?
For
xcodebuild, no, it’s not doing anything network-related. It’s mostly an XML Xcode project parser and an LLVM frontend for building projects. Everything as far as dependencies (SDKs, headers, libraries, etc.) must exist on the filesystem but all of that is put there by “Xcode Command Line Tools” which can be independent of the Xcode IDE.Doing device provisioning stuff for iOS/iPad is a different story, as that requires crypto-based profiles and certificates and such, which Xcode frontends and is much of this “phoning home”, as mentioned above.
But the configuration and building of projects and such still feels very UNIX-y with these CLI tools.
Most apps do this. Either they use the common Sparkle self-update framework, or something custom like VSCode or Zoom or whatever.