I dug more and of course they don't: "Though we don’t rely on the Xcode build system, you still need to install Xcode for the iOS SDK and toolchain"
I think they should clarify their messaging. This is not a replacement or an alternative. It's a layer on top designed for what they think is a better experience.
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).
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
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.
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 :)
AppCode
A smart IDE for iOS/macOS development
AppCode is no longer available as a commercial product as of December 14, 2022.
https://www.jetbrains.com/objc/
I also think any revival of AppCode is also dead as JetBrains is all in on Kotlin everywhere. iOS multiplatform support hit stable recently.
Regrettably I didn't see that they did anything with the ObjC part, choosing to /dev/null it
*Both US and EU now
(P.S.: Personally, I initially thought Epic Games was stupid for flagrantly violating the ToS on purpose. Was that really needed to actually file the lawsuit? I dunno; I'm no expert. But it looked stupid. It looks a lot less stupid now, but it still kinda looks like a tactical mistake.)
Maybe they needn't be afraid here either, but from a risk perspective it does seem like causing a stink here may not be their best move. They're still going to aggressively try to railroad people into developing on Mac; there's no iPhone Simulator on Windows or Linux after all.
I’ve had multiple installs in the past where it worked fine.
While it’s ultimately up to the person doing the hackintoshing and thus an “honor system” thing, all the guides are pretty explicit about how you should generate serial numbers that are syntactically valid but cannot belong to real machines, for example that of a 12” Macbook manufactured in 2020 in Cork, Ireland (no such machine exists, as they were discontinued in 2019 and manufactured in China). That way there’s a small chance of collision with other hackintoshers, but no threat of accidentally using the serial of someone’s real Mac.
But yeah, I would probably use this for testing only, and do actual releases from macOS proper.
IANAL yada yada.
1. Dart can’t cross-compile from Linux to iOS yet. You could use Dart’s interpreter instead, but that’d significantly regress performance.
2. Flutter iOS projects use the Xcode project format, you’d need to migrate that to xtool’s project format
3. Flutter hasn’t finished migrating its plugin ecosystem from CocoaPods to SwiftPM - any plugin that hasn’t migrated to SwiftPM yet likely won’t work with xtool.
If for no other reason, it would be gloriously ironic.
I thought it was for compilation of ios apps for linux and macos.