I’m trying to find out if the following functionality might be on the horizon:
Building pure mojo code into a static or dynamic library. This also implies exposing some mojo functions with a C calling convention.
Support for the above on iOS (CPU only) in addition to the existing platforms.
For context, this would be an alternative to rust for a multi-platform app. Most of the “business logic” would live in a mojo library. The UI layer would be platform-specific.
Apologies if these topics have been covered somewhere, I did check in the Mojo roadmap documentation, FWIW.
Mojo code can be built into a static or dynamic library, those are really just different options in the LLVM backend, however, interfacing with it is hard. Mojo doesn’t really offer guarantees on what is C ABI compatible. This is a lot of stuff which happens to work, but that could change at any time.
IOS support is probably very, very far into the backlog. Windows is likely higher priority, as is AMD GPU support and probably a few other major vendors like Intel GPUs and Apple’s Metal API. IOS is a fairly closed ecosystem, so getting a new language to be able to support it is difficult. Mojo itself has many, many features which break the “no jit compilers” rule, to the point that I’m not actually sure if the full Mojo language would be allowed on IOS.
Better C interop will come, since Modular needs it for their C API for MAX, but it might be a bit.
Thanks for the quick and detailed response. I have a couple follow-up questions.
Regarding C interop, I think a mirror image of what external_call is doing (example), coupled with a way to compile a mojo function to use the C calling convention (a la rust’s extern “C”) would go a long way. Specifically, things like C struct layouts need not be supported initially – allowing scalar types and void pointers to be passed around would be a great step.
My understanding was that pure mojo code is compiled AOT – I would be curious to learn what features that is not true for. At any rate, it seems like mobile OSes would be an interesting target for inference – if a sizable chunk of the language/stdlib could be supported with AOT compilation, that would seem to be a win.
My layman’s assumption was that iOS support for the language/stdlib would be similar to MacOS (in addition to compiling for the correct LLVM target triple, obviously). I see that mojo binaries depend on a few custom .dylib flies on MacOS, which would minimally need special handling.
The priorities you outlined for Modular make a lot of sense. Would enough of the toolchain source be accessible in the near future for the community to contribute features such as the above?
I agree that an extern "C" would be nice, ideally also moving towards an extern "crabi" since that targets higher-level interop for languages that have more expressive type systems than C. Right now you can sort-of make it work, but it’s something that needs to be carefully tested (via abigail or similar tools).
Mojo binaries are mostly compiled AOT, but if you do mojo run, that’s using a JIT compiler. A lot of the stuff in MAX and in the gpu module is what uses a JIT, since they need runtime information about the device they are targeting. There is also the compile and compiler modules, both of which are direct interfaces to the JIT.
Most code would work just fine if you stripped out the JIT, but some code which uses it for higher performance might run into issues. I expect a lot of numerics code to end up going through MAX for performance reasons, so large chunks of the ecosystem may also be locked off.
Modular plans to open source Mojo sometime during 2026, earlier if it works out for them. MAX will stay closed for longer.