Skip to content

Instantly share code, notes, and snippets.

@bitemyapp
Forked from michaelfairley/ios_and_android.md
Created October 8, 2017 19:47
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save bitemyapp/a0c473fe8b4132eef7bdddbe40318f2f to your computer and use it in GitHub Desktop.
Save bitemyapp/a0c473fe8b4132eef7bdddbe40318f2f to your computer and use it in GitHub Desktop.

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 AppDelegate and 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.” 🙃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment