We should differentiate between Xcode the ide and Xcode tools, which are just git, clang, etc. The tools aren’t apple’s product.

In Linux they would have been separate packages, but I don’t think the App Store has dependencies so how else are they going to get the required packages installed for their ide.

In this case the argument is focused on Apple forcing you into their ecosystem. Even though some packages might be generic, Xcode tools & codesign wont run and build on another OS then MacOS.

This is just like saying clang compiled for Linux won’t run on Windows [1].

[1]: Yes, I know about WSL. No, that doesn’t count.

It's not: for any other OS, you can develop and compile on whichever other OS you want. Sure, MSVC won't run on Linux, but you can just compile it with clang or GCC on Linux and target Windows. There is no way to do that for iOS.

And this is not because no one wants to write a backend to target iOS, it's because Apple won't allow it. If you want to run native code on iOS, it must be built and signed with XCode on a Mac.

Try to create a UWP application or Windows service, or do any kind of debugging or ETW monitoring, like that.

Fair enough with UWP. Might be one of the many reasons no one uses it...

I will still note that debugging and monitoring are usually not going to work cross-platform - try to log to journalfs from a Windows system (wihtout using MinGW or similar).

Plenty of people use it, they don't need help from Linux devs trying to cross compile applications without any tooling for UI/UX.

You only need clang and codesign to build an app.

If it were actually this simple in practice I wouldn't be jumping between AppCode and Xcode all the time

Could you provide a few examples from your workflow that requires you to open Xcode?

If you want to do real-world things, like change your project settings across different compilation targets (AppCode has a buggy/incomplete settings interface that can't be trusted), use the interface builder (inc. previewing your UI, inc. creating/editing the UI if you're not using SwiftUI), debugging the UI hierarchy, performance profiling, etc., you'll be switching over to Xcode. Once again, in theory you could just have everything running off whatever `make` toolchain you prefer, but if you're making apps for a company, and sharing code with other team members, chances are your exotic setup isn't going to cut it.

i think people might be conflating needing to install xcode vs launching xcode

if you want to build ios apps installing xcode is a requirement (to get the proprietary cli tools) but launching xcode is not required

to build native mac apps, neither installing nor running xcode is necessary, as you can build with the smaller cli-only tools which include only mac os headers/libs