Photo by Holmo on Unsplash

I was giving my talk at a conference (the one about running Jenkins on old Android phones with Termux) and the demo had gone well. Jenkins was running, the agent was connected, builds were passing. I was feeling pretty good about the whole thing.

Then someone in the audience raised their hand.

“This is cool, but… what about iOS? Can you do the same thing on an iPhone?”

I paused. I actually didn’t know. I mean, I assumed iOS would be harder. Apple locks things down way more than Android. But I’d never actually investigated the question properly. I gave a vague answer about Apple’s sandbox restrictions and moved on, but the question kept nagging at me.

So I did what any self-respecting tinkerer would do: I went down the rabbit hole.

TL;DR

No, you cannot run Jenkins on iOS. The closest thing to Termux on iOS is iSH (Alpine Linux via x86 emulation), but Java is fundamentally broken on it. The only theoretically viable path involves running a full Linux VM on a 1000-dollar iPad Pro, and nobody has ever documented actually doing it. A 30-dollar used Android phone does natively what a 1000-dollar iPad can barely do in a virtual machine.

If you’re at a conference and someone asks “What about iOS?”, that’s your answer.

Now, if you want to know how I arrived at that conclusion, and all the dead ends I explored along the way… read on.

The Investigation: Let’s Start With iSH

First, I needed to find the iOS equivalent of Termux. After some digging, the answer was clear: iSH Shell.

iSH is an impressive project. 19.2k stars on GitHub, actively maintained, and it runs Alpine Linux on your iPhone or iPad via usermode x86 emulation. It gives you a real shell, a real package manager (apk with 14,000+ packages), and you can install stuff like Git, Python, Node.js, GCC, vim, curl…

Nice! This sounds promising!

Let’s check the important boxes for running Jenkins:

• Shell environment? Yes. Bash, zsh, the works.
• Package manager? Yes. Alpine’s apk, fully functional.
• SSH server? Yes. You can accept incoming connections (wiki).
• Git? Yes.
• Python? Yes.

So far so good. Now the big one:

• Java/OpenJDK? …

Let me check.

The Java Wall

This is where everything falls apart.

I found issue #306 on the iSH repository. Then issue #1560, helpfully titled “Java is very broken.” Then issue #2589. The picture was grim.

Here’s what happens when you try to run Java on iSH:

• JDK 7: Barely works. You need manual heap flags (java -mx256m). Functional but ancient. Jenkins dropped JDK 7 support years ago.
• JDK 8+: Crashes immediately with “Too small initial heap.” Can’t start.
• JDK 11+: Completely non-functional. Dead on arrival.
• JDK 21 (what Jenkins needs today): Forget about it.

Damn!

The root causes are architectural, not just bugs that’ll get fixed someday:

1. Missing SSE instruction support in iSH’s x86 emulator. Modern JVMs assume SSE instructions exist.
2. Missing shared futex support. The JVM’s threading model depends on these.
3. 32-bit only (i386). iSH emulates an old x86 processor, not x86_64.

And the big one: Apple’s W^X memory policy forbids JIT compilation. The JVM needs JIT to function at any reasonable performance level. Without it, you’re running through an interpreter inside an emulator. Even if it worked, it would be comically slow.

Of course… I should have seen this coming. Jenkins is a Java application. No Java, no Jenkins. Investigation over?

Not quite. Let me check a few more things.

The JIT Saga: Apple Says No

Here’s a detail I found fascinating and infuriating in equal measure.

The iSH developers actually tried to get JIT access through the EU’s Digital Markets Act (DMA). In July 2025, they filed an interoperability request with Apple, arguing that JIT compilation is essential for their app to function properly.

Apple denied it in 2025, classifying iSH as ineligible.

There’s a blog post about it if you want to read the details. The short version: Apple controls the platform, Apple says no JIT for third-party apps, and the EU regulations weren’t enough to change that.

Compare this with Android: Termux runs native ARM64 binaries. No emulation layer. No JIT restrictions. pkg install openjdk-21 and you’re done. The JVM runs at full native speed.

You know what? Let’s keep investigating. Maybe there’s another way.

What About a Full VM?

UTM is a QEMU-based virtual machine app that can run full Linux distributions on iOS. Two versions exist:

• UTM SE (free, App Store): No JIT. x86 emulation at roughly 2-5% of native speed. Jenkins would be… let’s say “meditative.” Actually, unusable.
• UTM with JIT (sideloaded or via EU AltStore): ARM64 Linux VMs running at 80-95% native speed on M-series iPads.

The JIT version is interesting! On a 16GB iPad Pro with an M-series chip, you could theoretically run an ARM64 Ubuntu VM with enough RAM for Jenkins.

Here’s the problem:

Jenkins needs roughly 1.5-2GB minimum (512MB heap plus the OS overhead). So you’d need at least an iPad Pro to even attempt this. And there’s a fun detail: hardware-accelerated VMs on UTM have double RAM overhead due to JIT mirror mapping. ¯\_(ツ)_/¯

And the background execution story is rough. iOS aggressively kills background apps. There’s some hope with iPadOS 26’s BGContinuedProcessingTask API (WWDC 2025 session), and there’s an open UTM issue tracking this, but as of early 2026, a VM-based Jenkins would die every time you switch to Safari.

The kicker: nobody has documented actually running Jenkins this way. Not a blog post, not a forum thread, not even a tweet. Zero evidence of anyone successfully doing it. I looked hard.

So the “best” iOS path to Jenkins requires a 1000-dollar iPad Pro, sideloading or EU DMA provisions for JIT access, a full Linux VM with careful RAM management, and… hope.

The Dead-End Parade

For completeness, I checked everything else I could find. Let me save you the trouble:

Every. Single. One. A dead end for running Jenkins.

“But What About Jailbreaking?”

Sure, let’s go there. Jailbreaking could theoretically give you launchd daemon persistence, a real SSH server on port 22, and Linux chroot environments.

But here’s the state of jailbreaking in early 2026:

No jailbreak exists for iPhone 12 or newer on iOS 17.1+. Jailbreaking is effectively dead for modern hardware. And even if you could jailbreak, there’s no official OpenJDK package. You’d need to manually compile it.

So that’s not a realistic answer either.

Before we wrap up the investigation, there’s one more recent development worth mentioning.

A Glimmer of Hope: OpenJDK Mobile

The OpenJDK Mobile project has made progress. InfoQ reported in November 2025 that OpenJDK can build and run on iOS using the Zero interpreter (pure C++, no JIT) enhanced with AOT-compiled methods from Project Leyden. Gluon has built automated build pipelines.

Interesting! But (and this is a big but) it’s designed for embedding Java in iOS apps, not running standalone JVM servers. Jenkins is far too dynamic for AOT compilation (hundreds of plugins, dynamic class loading everywhere). This doesn’t help us.

The Comparison That Says It All

So after exploring every possible path (native apps, emulation, VMs, jailbreaking, even emerging OpenJDK efforts), let me lay out the complete picture in one table:

Look at that last row. Free versus a thousand dollars, and the free option actually works.

Why iOS Is Fundamentally Different

This isn’t a matter of finding the right app or the right workaround. The gap between Android and iOS for this use case is architectural:

1. No JIT compilation (W^X memory policy). Kills JVM performance. Apple denied the EU DMA exemption request.
2. Aggressive background app killing. iOS suspends apps after minutes. You can hack around this with location services in the background (cat /dev/location > /dev/null &), but it’s unreliable.
3. No boot-time auto-start. There is no equivalent to Termux:Boot. You cannot have Jenkins start when the device boots.
4. App sandbox isolation. Apps cannot spawn arbitrary processes or access system directories.
5. No raw syscall access. Everything must go through Apple’s approved APIs.

Android’s architecture is simply more open. Termux runs native ARM64 binaries, manages services via runit, and persists across reboots, all without root. That’s not a feature gap. It’s a philosophy gap.

The Punchline

So here’s what I’ll say next time someone asks “What about iOS?” at a conference:

iSH is the closest thing to Termux on iOS. It runs Alpine Linux with a real package manager and even accepts incoming SSH connections. Pretty impressive! But Java is broken on it due to Apple’s ban on JIT compilation and missing CPU instruction support in the emulator. The only way to run Jenkins on an iPad would be inside a full Linux VM using UTM on a 16GB iPad Pro, and even that has never been documented working. Meanwhile, a 30-dollar used Android phone does natively what a 1000-dollar iPad can barely do in a VM.

How cool is that? Well, not cool for iOS users. But it definitively validates the Android/Termux approach.

Those old Android phones gathering dust in your drawer? They’re not e-waste. They’re infrastructure waiting to happen. And no amount of Apple silicon can change the fact that an open platform beats a locked-down one when you need to run actual server workloads.

Suite au prochain episode. I’m already thinking about multi-device clusters and load balancing across a fleet of phones. But that’s a story for another day.

The project: termux-jenkins-automation on GitHub

The research: The full technical comparison document with all sources and links is in the repository at docs/IOS-EQUIVALENT-RESEARCH.md.

The talk: If you want to see Jenkins running on a phone and ask your own tricky audience questions, come find me at the next conference. I’ll have a better answer for the iOS question this time.