Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XTool – Cross-platform Xcode replacement

github.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: XTool – Cross-platform Xcode replacement

#51

Post by jonhohle »

cosmic_cheese wrote: post #38
cyberax wrote: post #26

Earlier quoted context omitted.

You can't install XCode on non-Apple devices. Or use iMessage.

iMessage can be made to work with a hackintosh. You just have to go the whole way in making your hackintosh fully Mac-like with a fake but plausible/realistic serial number and expected network setup. You can’t stop at just getting macOS installed and booting. I’ve had multiple installs in the past where it worked fine.

Who minds committing a little wire fraud and possibly screwing over some chump who really owns that serial number?

Re: XTool – Cross-platform Xcode replacement

#52

Post by kabiroberai »

rockbruno wrote: post #24
lwouis wrote: post #22

This tool says "Xcode replacement" and "Xcode-free development". I thought there is no way they can build apps without Xcode. How would they replicate the libraries, compilers, etc. 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.…

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 co…

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).

Re: XTool – Cross-platform Xcode replacement

#53

Post by kabiroberai »

notpushkin wrote: post #36
rockbruno wrote: post #24

Earlier quoted context omitted.

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 co…

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.

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.

Re: XTool – Cross-platform Xcode replacement

#54

Post by loic-sharma »

flax wrote: post #2

Would this theoretically allow a Flutter app developer to build and deploy an ios app from Linux? God, I hope so.

This project helps but isn’t enough alone:

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.

Re: XTool – Cross-platform Xcode replacement

#56

Post by cosmic_cheese »

jonhohle wrote: post #51
cosmic_cheese wrote: post #38

Earlier quoted context omitted.

iMessage can be made to work with a hackintosh. You just have to go the whole way in making your hackintosh fully Mac-like with a fake but plausible/realistic serial number and expected network setup. You can’t stop at just getting macOS installed and booting. I’ve had multiple installs in the past where it worked fine.

Who minds committing a little wire fraud and possibly screwing over some chump who really owns that serial number?

How is it wire fraud?

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.

Re: XTool – Cross-platform Xcode replacement

#57

Post by mdaniel »

firecall wrote: post #23

JetBrains used to develop AppCode: 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/

It likely doesn't help the ObjC part of that story, but they moved the Swift part out into a CLion plugin https://plugins.jetbrains.com/plugin/8240-swift

Regrettably I didn't see that they did anything with the ObjC part, choosing to /dev/null it

Re: XTool – Cross-platform Xcode replacement

#58

Post by rushiiMachine »

kabiroberai wrote: post #52
rockbruno wrote: post #24

Earlier quoted context omitted.

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 co…

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…

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.

Re: XTool – Cross-platform Xcode replacement

#59

Post by notpushkin »

kabiroberai wrote: post #53
notpushkin wrote: post #36

Earlier quoted context omitted.

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.

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…

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!
Post reply on HN