Julia in iPad

Hi!

I talked to some people at JuliaCon and it seems that we will never get a native Julia REPL in an iPad due to Apple’s restrictions regarding JIT :frowning:

That’s too bad, because we have this impressive hardware that can do a lot of things to… play angry birds if you are not a content creator…

However, the bright spot at the end of the tunnel is WebAssembly (WASM). Is there a way to contribute to or check the development of WASM support in Julia? Are there any recent developments in this area? The repositories I’ve found are quite old.

Is it possible to use the interpreter (Home · JuliaInterpreter.jl) to execute Julia code without compilation?

  1. Precompile all of JuliaInterpreter and build it into the sysimage.
  2. Axe the JIT compiler from Julia and make sure the interpreter is used for everything.
  3. Put this interpreter into a Julia IDE, similar to Pythonista or Pyto.
  4. Ship this as an iOS app.

I guess this won’t be fast because interpreters usually aren’t fast, but at least it’s something.

Not worth it.

Why do you want to run julia on an iPad.
I own both an iPad Pro 12 inch and an iPad mini 6 but they had been dust collectors for several years. they are merely toys for children (I think).
They have neither keyboard, mouse, big screen, nor they have sufficient RAM…

When the iPad Pro 2024 with M4 was released it had the first publicly available aarch64 CPU with the SME extension, now also available in MacBooks and Mac Studios. People went crazy doing matmul benchmarks on the iPad, see for example Overview | Hello SME documentation or GitHub - tzakharko/m4-sme-exploration: Exploring the scalable matrix extension of the Apple M4 processor.

Technically, you can get around the no-JIT restriction by bundling a browser (which has to be Safari) with your app. But it wouldn’t help target native code from Julia.

Metal.jl is the easiest way to target GPUs in Apple Silicon Macs. As the others said, the same hardware exists in some iPads. If you could use the same Julia code to target desktop+laptop+tablet, it would open up the device for new applications, especially outside gaming and ML.

Speaking of new applications, the iPad is the only device of its kind with stable, low-latency audio drivers. It’s already possible to create AUv3 audio plugins that work on Mac+iPad from the same C++ codebase. What if you could use Julia instead?

Maybe it’s a dumb question, but would juliac work if cross-compilation becomes a thing?

The tablets (iPads and others) are becoming more and more powerful tools. I guess they will finally replace most laptops in a few years. Having them as work platforms will be important. I would bet Apple will (have to) flexibilize that restriction. And Julia support for these hardware will become increasingly important. (I’m using a samsung tablet as a replacement for most of my travelling work and, not without some glitches, it works).

Why do you need cross-compilation? It’s the same platform as any other Apple Silicon MacBook or Mac Mini/Studio.

I have zero idea how compatible iOS and MacOS are. If juliac on a Macbook works, then that’s one less reason to wait for cross-compilation.

Because it would be a good idea to start growing future Julia developers. I’d agree this isn’t where you want to do intensive scientific computational work, but offering the opportunity to learn mathematical problem solving on a platform that is readily available to schools is a good application. It’s going to be easier to start kids on Julia than convert them from the alternatives, and base Julia has a very approachable syntax, from which you can expand into the much more powerful constructs later as needed.

I agree with @MDSW. Anecdotally, I had the opportunity to work with twelve high school astronomy interns yesterday on an intro to coding activity. When I asked how many had used, or even heard of, Python before, I was surprised to see that very few raised their hands. Same went for Julia (less surprising). Not going to try and make any predictions here, but by the end of the workshop we did have Julia installed on all of their school laptops (big thanks to the folks behind juliaup!)

I’m not sure it would be worthwhile for anything more than a curiosity, but has anyone had any luck with iSH? I know there is not a supported version of Julia for 32 bit Linux with musl instead of glibc, so all I’ve done is try to use gcompat. No luck, but I’m far from an expert

I apologize for resurrecting this old thread, but if anyone has an iPad and is interested in trying a bit of a curiosity, I’d appreciate any feedback on an attempt to put a Julia 1.10 REPL on iOS (apologies for the silly name, naming is hard, and my original plan of naming it “Yulia” ended up being taken):

“It works on my machine” which is an iPad Air M1. But I would like to know if it works on yours as well and if you could see there being any use to this curiosity.

Full disclosure: I wish I knew what I was doing, but since I don’t, this is vibe-coded slop. I understand if that bothers people, but I was trying to do this by myself for the past couple of years (!!) and barely got to the stage of compiling Julia as a framework for iOS, let alone getting that bundled into an actual app. The acceleration possible from using LLMs has changed this from a pipe dream into… something.

As alluded to in this thread and other older ones - due to iOS restrictions the Julia runtime in the app can’t compile any native code and has to interpret everything. Also, I don’t think Pkg.add, the way it’s currently implemented, would be allowed (and it’s not working in this not-even-alpha-quality app) so it may never be possible to install even pure-Julia packages at runtime. But the app does bundle a couple of dependencies into the system image in order to make the app a little more interesting: StaticArrays, StatsBase, DataStructures, Distances, OffsetArrays, Combinatorics, IterTools, Polynomials, Unitful, Measurements, QuadGK, Roots, JuliaInterpreter, UnicodePlots, Compose, and PlotlyLight.

If anyone tries the app, and it doesn’t crash out, and they wish there were additional Julia-only packages in the system image, please let me know. I can start a new thread if that happens.

I have enjoyed following this community for quite some time (been playing around with Julia since it hit 1.0, and started using it occasionally at work since 1.6) and I’ve learned quite a bit from reading on this forum and through the works of this community. I wish this was a more useful app, assuming it works on other people’s iPads, but given the iOS restrictions it likely won’t be.

Pressing Return (on the on-screen keyboard) to run doesn’t do anything (but manually pressing the Run button works). Pressing Tab to autocomplete doesn’t do anything either.

Otherwise this seems to work, which is a little wild: Julia on iOS?! Amazing!

Some suggestions

  • “Press Return to run” is not great because it doesn’t allow for multiline code, like a function definition. Julia’s REPL itself doesn’t immediately run code when you press Enter. For example, when you’re writing a function but haven’t written the closing end keyword yet, pressing Enter won’t run the unfinished code and display an error. Instead, it’ll just move the cursor to the next line. Perhaps you could hook into Julia’s mechanism of deciding when to send the code for execution.
  • Up/down buttons for scrolling through history would be nice.
  • You (or your LLM) could take a look at some iOS apps that run Python for inspiration: Pythonista and Pyto.

Edit: pushed a new build (5) which hopefully improve soft-keyboard handling

Thanks for the feedback!

I never tested the on-screen keyboard (whoops) and you’re right, it’s pretty broken. I’ll try to push an update today which addresses your feedback.

If you do have a hardware keyboard, your experience should be marginally better - pressing Tab runs autocomplete, Return executes code, Shift-Return inserts a newline (agree that having the parser run and the behavior dependent on whether you’re in an expression or not would be ideal), and up/down does scroll through history.

Since the ipad issue came up last, the situation has somewhat improved. To recap: The fundamental issue is that you dont really own ios devices, you are de facto given lease to temporarily use them at apple’s discretion (I don’t understand how lawmakers in most jurisdictions continue to stand for that kind of practice. Complain, vote accordingly, don’t buy apple).

There is a W^X policy on ios devices. Makes sense, good security decisions. Enforcement point is mmap/mprotect, i.e. when userspace wants a page executable. The kernel only allows loading of code that is signed with certificates that your devices kernel recognizes, or JIT exceptions for certain apps (the exception is signed along the the cert). Laudable.

Alas, the good security tooling is used as a prison because you, as the device “owner”, cannot add new trusted root keys (regulations should attack here: Simply forbid first-party sale and import of devices that don’t allow owners to add trusted root keys. Game console, John Deere tractors, and solar inverters need the same treatment as ios).

There is a somewhat gimped and finicky escape-hatch, in the form of developer certificates. You sign up with apple as a developer, and sign up your ipad as a testing-device for yourself as a developer, and you then can sometimes, after jumping through various hoops, run the code you wrote on the device you “own”.

This is annoying, finicky, silly and plain evil (really, fuck apple). But the hardware is pretty amazing.


By now, some people have packaged most of the finicky stuff into something close to usable. Consider Enabling JIT | AltStore

I think with that, you should be able to create and run a real julia ios port.

All that being said, I don’t “own” any ios devices, so I cannot speak on how well this works at the moment.

Yes, I agree - it sure would be helpful to be able to add my own root key to my own device. I was very disappointed after I got my iPad to discover how locked down it is to developers. The annual fee for Apple’s developer program is silly too - if I could run apps on my own devices without needing them to be resigned every few weeks, I wouldn’t be trying to put this up on the App Store at all. But since I want my apps to work for a while I’m paying for the privilege to be a member.

I actually inadvertently ran into the W^X workaround when trying to get this app going - it would work fine on my iPad + Xcode, but I later discovered (and gained my first appreciation LLM explanations) that App Store apps run with less permissions - or maybe phrased more accurately, local development setups allow running apps with extra permissions.

That’s when getting the Julia runtime working on an Apple device, packaged as an iOS framework, stopped being something that I could do myself and started really leaning into pure vibe-coding. I had gotten Julia 1.10 compiled against iOS by manually modifying the .mk files in the deps folder, but the runtime needed code guards to prevent codegen which I needed the LLM to do. Then I wanted the runtime to default to using Apple Accelerate instead of OpenBLAS. Then I wanted Pkg to work without having to call out to 7z which is blocked on iOS. Now the LLM is hard at work adding a libffi-based interpreter for ccalls. This is all far beyond my personal development abilities.

But: if you do end up using an iPad, this is intended to be a real, although limited, port - slower due to lack of JIT and limited due to the inability to use JLLs.

I’ll push an update later today with the Accelerate changes and the patches to Pkg and ccall handling.

i know this is not very helpful, but i am working on a fork of WasmCompiler.jl designed for a project i am working on, i made it work on Julia 1.12.x, and it can compile a subset of Julia to WASM, not sure it helps, but if it does, ill be happy to publish the fork earlier than i planned

I don’t think an interpreter-only julia adaptation is very worthwhile.

But if you package a jit-enabled port / instructions that require a developer account, then that would be quite cool. ios would be a reasonable “tier 3 support” target to upstream, if the required modifications are minimal.

Of course “requires dev account” is a limitation, but that’s not unsurmountable. People who want to use their ipads as not-toy devices need that anyways.

People / organizations who want to use julia in a classroom setting might be able to finagle something with a mix of dev-certificates and organizational roll-out (the enterprise provisioning stuff – won’t help you hacking on your device, but if your educational institution happens to use ipads, maybe).