Julia on iOS and Android

Internals & Design
62

Note, Julia can already be run on the web:

and since iOS has a web browser, that should mean that demo should also work there. I’m not sure if or how limited it is (its old Julia and could be refreshed to newer), except that the binary is large and thus has some startup cost.

Julia apps are famously large since its runtime that you bundle with is. But it can be made smaller.

You had in mind how to run Julia, or Julia apps? It doesn’t matter really, since you can do either, e.g. this demo:

https://alexander-barth.github.io/FluidSimDemo-WebAssembly/

Apps can be much smaller, because of e.g.:

See WebAssemblyCompiler.jl that has fewer restrictions than other static compilers, since it e.g. has GC support.

See also a Masters thesis on this from this year:

https://dspace.mit.edu/handle/1721.1/150151

Use cases for WebAssembly can be divided into two categories: web and non-web. […] This would also expand support to platforms like iOS, Android, and ChromeOS that do not have native Julia support.

If you think you need an internet connection, then usually for the web, you can also surf from local files, but I’m not sure how that works or if on iOS and Android. But since this isn’t just for the web, can be run somehow locally on mobile.

Note, I can confirm I can run the FluidSim demo on my rather old Android phone. It’s meant for a larger screen though, so I zoomed out. I don’t know about usual progressive web app design methods for mobile and larger sizes. I suppose those could work, might need JavaScript? Some or many demos, likely that one uses Canvas, and you assume a certain size? I don’t know they rather assume WebAssembly can also get access to dimensions of the screen. At least you could make an app for a small screen only, which would look a bit off on a larger one… And the demo ran maybe a bit slower on my phone. I think it’s simply a bit CPU intensive (in my desktop under about:performance I saw it taking 30% CPU until I shoot it down, so most likely 100% on mobile, and CPU limited), and updating as fast as it can? On non-web you might want to sync to vblank etc. for a consistent frame-rate, and I’m not sure how that would work on the web. There’s at least also WebGPU that can be used.

2 Likes
63

Hopefully the new EU law will change this, at least in the EU, the rumours are that they will still block it in the US.

Though this law might only apply to side-loading apps, not sure what it means for compilers.

64

I mean, this is way off-topic, but most of the time big international corpos need to adapt to both EU and US regulatory regime; if side-loading gets possible in EU, then I am pretty sure that it will become globally possible (at worst by shipping in an unlocked phone from europe).

I think that any reasonable implementation would enable JIT compilation. General purpose computation is a package deal, just like there is no “almost turing complete” or “half pregnant”.

Side-loading means that apple doesn’t control the sole signing key for mprotect syscalls, which turns iphone into a von Neumann machine / general purpose computer. Yes, the end-user might need to jump through a scary API to import a new root-cert that becomes valid for mprotect; and the user might need to do this with a locally generated self-signed root-cert and might need to make the corresponding private key accesible to llvm; and then llvm would need to be taught to code-sign each blob of emitted code.

This may sound slightly elaborate, but it is no different from running e.g. burp-suite or any other MITM ssl proxy. Once end-users get emancipated and can import new root-certs with code-signing validity, I promise you that this infra will be set up within weeks. (currently you can only import new root-certs for SSL)

1 Like