Show HN: Rust Toolchain for iOS Bitcode(github.com)
github.com
Show HN: Rust Toolchain for iOS Bitcode
https://github.com/getditto/rust-bitcode
6 comments
Can someone ELIF what's a toolchain for iOS bitcode?
Apple requires bitcode submissions for tvOS and watchOS, this has effectively meant that you needed Apple’s toolchain to build and distribute binaries for those platforms.
Bitcode is an intermediate format produced by LLVM, which allows for optimization passes to be applied to it across different languages. For example, C, C++, Swift, ObjC, and Rust can all benefit from some of the same bitcode optimization passes.
In theory Apple wanted this so they could improve the performance of applications when distributed on some of their platforms, though the benefits and potential of this has been a bit dubious. It did mean that Rust (until this) couldn’t easily target those Apple products.
Bitcode is an intermediate format produced by LLVM, which allows for optimization passes to be applied to it across different languages. For example, C, C++, Swift, ObjC, and Rust can all benefit from some of the same bitcode optimization passes.
In theory Apple wanted this so they could improve the performance of applications when distributed on some of their platforms, though the benefits and potential of this has been a bit dubious. It did mean that Rust (until this) couldn’t easily target those Apple products.
I was under the impression that it wasn't for performance but for distribution, i.e., to optimize for app size. Instead of having a fat binary crosscompiled for different architectures, Apple uses the bitcode to compile and distribute per architecture. It's part of the "app thinning" process.
To expand on this, it also lets them target new CPU architectures without having developers recompile code for that architecture. This lets them make incremental improvements (eg armv7), but would also let them use their own CPU architecture should they move away from Intel/ARM.
As an example here’s Chris Lattner tweeting about that use case:
https://twitter.com/clattner_llvm/status/1091186386634326017...
As an example here’s Chris Lattner tweeting about that use case:
https://twitter.com/clattner_llvm/status/1091186386634326017...
> but would also let them use their own CPU architecture should they move away from Intel/ARM
Only if their new architecture looked a lot like Intel/ARM. Bitcode can’t paper over all architectural differences.
Only if their new architecture looked a lot like Intel/ARM. Bitcode can’t paper over all architectural differences.
Regular bitcode cannot do it. However Apple has naturally customized it for their own purposes.
Not everything that Apple does lands on upstream.
Not everything that Apple does lands on upstream.
[deleted]
I think you’re right that that is the primary reason today. In their marketing material I think they always use the term “reoptimize”, of course, that can mean for size.
Thanks for the correction.
Thanks for the correction.
App Thinning works just as well without bitcode. It’s just a process of removing unneeded architecture slices and resource variants from a downloadable app.
I guess this is good enough for Apple in practice, but LLVM bitcode is not platform independent in general.
Bitcode also enables your old app to run on new Apple Watch hardware with no recompilation required.
This is highly dependent on not much changing. For example, even widening integers from 32-64bit but would break a lot of software.
So to a degree this might be true. But my guess is there is very little benefit here. It’s not clear to me if this could even optimize for the presence of a new vector unit, for example.
So to a degree this might be true. But my guess is there is very little benefit here. It’s not clear to me if this could even optimize for the presence of a new vector unit, for example.
> This is highly dependent on not much changing. For example, even widening integers from 32-64bit but would break a lot of software.
As Apple designs their own silicon and calling convention, they were able to pull this off for the S3 → S4 transition (the latter of which is AArch64 running with ILP32).
As Apple designs their own silicon and calling convention, they were able to pull this off for the S3 → S4 transition (the latter of which is AArch64 running with ILP32).
If I'm reading it right, it lets you build Rust libraries so you can use them in iOS programs.
You can already build for iOS, just not apple tv or watch without bitcode. For building for iphone this is not needed.
Libraries only, or can you write native iOS apps 100% in Rust, no Swift?
You would need at least a bridging layer (of Objective-C) to so that your app code could use the system frameworks and respond to events (user input, network, sensors, etc).
Objective-C shares calling conventions and struct layout with C, so theoretically you could directly call the system frameworks from Rust via extern "C" functions.
Not even theoretically, the bindings for the runtime are out there [1] with some nifty helper macros.
[1] https://github.com/SSheldon/rust-objc
[1] https://github.com/SSheldon/rust-objc
It'd be super cool to see a 100% Rust (with extern "C" calls) Hello, world! iOS compatible app.
Great work! Is it easy to interact between Swift and Rust or UIKit libraries?
Unfortunately, you have to use C or ObjC (or at least the ObjC runtime) as the middleman.
Now that there is a stable Swift ABI, at least it's theoretically possible to add a first-class Swift interoperability support to Rust, but it's a quite a chunk of work that nobody has attempted yet.
Currently the practical approach is to write the UI in Swift and Rust on the back-end, e.g. gif.ski app does it this way: https://github.com/sindresorhus/Gifski
Now that there is a stable Swift ABI, at least it's theoretically possible to add a first-class Swift interoperability support to Rust, but it's a quite a chunk of work that nobody has attempted yet.
Currently the practical approach is to write the UI in Swift and Rust on the back-end, e.g. gif.ski app does it this way: https://github.com/sindresorhus/Gifski
Awesome. I tried tinkering with this a hwile back and failed.
This is very cool!
does apple still require that you submit source code as objective C with your app? i recall google creating a transpiler from java to objective C some years ago so they could use their existing java codebases and still meet apple's requirement for submitting objective C source code.
I wasn't aware Apple ever required source code submission? Not at least in iOS projects I was involved with or know about.