[rockbruno]

I think you are mixing some different concepts here. It's not that this is a layer on top of Xcode/xcodebuild, it's just that Apple today happens to package everything iOS/Swift-related together with Xcode releases. So even if you couldn't care less about the Xcode IDE itself or the xcodebuild build system, you still need to have it because this is the only way for you to download / install those toolchains. Apple could provide these separately, but they just don't.

[kabiroberai]

xtool creator here, this is correct. it wouldn’t have been possible to support Linux if xtool was just a layer on top of Xcode, as Xcode doesn’t run on Linux.

we only need Xcode to be installed on macOS since it bundles the iOS SDK (ie all the header files.) similarly, we ask the user to supply a copy of Xcode.xip during the setup process on Linux in order to extract the SDK.

it definitely depends on your definition of “replacement” in the end, but I (and most people I’ve spoken with in the iOS community) would consider “Xcode” to be the Xcode build system, user interface, and proprietary tooling. xtool doesn’t rely on any of this, not even for signing and installation. you can (read: must on Linux, may on macOS) use it with the open-source Swift and Clang toolchain + LLVM’s LLD linker and MachO tooling. Codesigning uses zsign, an MIT-licensed x-platform codesign alternative, and installation relies on the open source libimobiledevice project, which is installed by default on many Linux distributions (eg Ubuntu).

[lwouis]

I've been developing a fairly popular macOS app for years. I consider myself in the community for that reason.

Apple has bundled everything together in a big mess.

- Only certain macOS versions can run certain XCode versions

- Only certain XCode versions contain certain SDK versions

- XCode embeds "Command line tools" which contains things like gcc, ruby, python, installed as a package, and conflicting with other versions on the machine

- Interface Builder is built into XCode and has its own compatibility story

It's a big messy blob and you can't pick-and-choose parts. You have to update your whole machine to move to the latest OS so they will let you run the latest XCode, so your app can compile on the latest platform for your users. It's not the best experience for sure. Many ecosystems have SDKs that you can download as you wish. I don't need to update my OS to download a version of the JDK for example.

That being all said, if you require users to download XCode, regardless of which part of it is necessary, i don't think you should mention "XCode free experience" or "XCode replacement".

I'm already developing a macOS app without launching the XCode GUI. I use the xcodebuild CLI that ships with XCode. My IDE is AppCode. I also use xcodebuild on CI to build the app headless. I would never call that a XCode free experience though, as i suffer from all the issues i mentionned above with version upgrades and XCode issues

[rushiiMachine]

I'm not too familiar with the xcode dev environment; could Theos be used instead of the huge xcode bundle? As far as I know, it provides the compilers and frameworks directly.

[kabiroberai]

I’m also one of the maintainers of Theos :)

When you use Theos outside macOS, you have to install a toolchain and SDK. The toolchain is built from LLVM + cctools, and is in fact very similar to the one we use in xtool (I maintain both.) The SDK is hosted on GitHub and I could’ve decided to use this instead of getting the user to supply a copy of Xcode, but the copyright status is iffy; there’s an argument to be made in light of Google v. Oracle but I didn’t want to take any chances.

[rushiiMachine]

That makes sense, thanks!

I'm excited for the possibility of this being integrated with multiplatform frameworks like KMP. I wouldn't need to boot up my hackintosh anymore :)

[notpushkin]

Would it be possible to get just the SDK from the Xcode package? Like Asahi installer streams only the relevant parts of macOS images from Apple’s servers.

[kabiroberai]

I looked into streaming but afaict the XIP format doesn’t support random access the same way that ZIP does. specifically because 1) it doesn’t seem to have a Central Directory like ZIP and 2) it has an optimization where files can be hardlinks to other files (by ID) in the XIP, so if you want to extract a file but all you get is a hardlink ID, you can’t expand the contents until you encounter and expand the hardlink pointee. it’s possible I’ve missed something, open to ideas for sure.

[notpushkin]

I do have an idea that will add a lot of complexity for sure: you can extract Xcode, mapping out whick portions of the archive correspond to the SDKs we need, then use this mapping to only download these relevant parts, reconstruct the archive and expand it. Not sure if it’s worth it!

[isodev]

There are some components that may be downloadable separately but they really are part of Xcode. One ring to rule them all.

[ImPostingOnHN]

It sounds like this "cross-platform xcode replacement" isn't cross-platform, and ios app developers still need macos?

[dadoum]

But that's wrong. You don't need macOS. That's why they say "cross-platform Xcode replacement". You just need the SDK, which can be used on every platform.

[mathstuf]

IIRC, you need to run on Apple hardware for a valid SDK license. VM or Asahi or Hackintosh would suffice, but not a VM on a random Linux box. Or did the terms change lately?

[ImPostingOnHN]

Thank you. I did not make it clear enough that I was asking for clarification there.