Where you able to produce a binary directly from the Rust build tools that you could submit to the app/play store?
Not quite, but I tried to get as close to that as was reasonably possible. Alas, things ended up a little convoluted.
For iOS, I have a nearly empty Xcode project with a build script that copies my
cargo produced executable into the
.app that Xcode generates (before Xcode signs it). The build script also uses
lipo to merge the executables for each architecture I’m targeting (e.g. armv7 and aarch64 for non-simulator devices) into a single, universal binary.
On top of that, there are various iOS-y things that need to happen before my application’s main method is called. SDL2 provides the Objective-C code that does all of that. In a C or C++ game, SDL2 renames main to SDL_main, and then inserts its own main which does all of the
LaunchImage and whatever other iOS shenanigans, and then eventually calls SDL_main (all of which happens behind the scenes if you’re just using C or C++). With Rust, I had to ask rust to not include a
main method in my application (there’s a
#![no_main] directive for that) and instead I provided my own
SDL_main for SDL2 to call. When the linker links my application and the SDL2 library files, the resulting binary ends up with the SDL2 provided
main, which makes everything happy. So, in a way, I am just producing a library that’s getting called by an Objective-C application, but I was able to make it not really feel like that.
And Android is a similarly janky setup. I pass a flag to the linker (
--export-dynamic) that has it include a dynamic symbol table in the executable that allows it be loaded as a dynamic library. SDL2 provides an
Activity Java file that loads the executable as a dynamic library, does a bunch of Android setup stuff, and then use JNI to invoke another shim that eventually calls SDL_main, letting me again pretend that I’m just making an application when in reality it’s actually a library.
And like the Xcode build, I do have to do an
ant build to package up my executable and the Java code into an APK.
As I said in the blog post, “My current solutions to packaging are very, very duct-tape-y.”