My understanding was that iSH is the same kind of thing that e.g. Swift Playground for iPadOS is: both ship with an internal userland of binaries, including a compiler toolchain, embedded into the app (that Apple can audit); and both allow code to be compiled and executed locally. But in neither case can you download and install arbitrary non-Apple-audited third-party packages into the sandbox.

This is why iSH calls itself a "Linux-like environment." There's no package manager! If Apple allowed it, iSH would almost certainly just be a wrapped-up Debian VM. But it's not. (And this is why iSH has always been considered a toy by people wanting to do real software development, rather than being something anyone would recommend you use as part of your workflow.)

False. I've been using iSH before it became available on the App Store. Downloading and executing arbitrary binaries is always possible. Just go install iSH and run any command-line binary to see for yourself.

The reason it's considered a toy is because of the sheer number of bugs in its Linux syscall simulation layer as well as in its implementation of Forth-style threaded code, not because of a package manager. After all its GitHub page says "This code is known to the State of California to cause cancer, birth defects, and reproductive harm."

iSH has nothing stopping you, the user, from wgetting arbitrary scripts or binaries and running them in the VM[0]. It also exposes a file provider so you can drop arbitrary x86 binaries into it if you so choose.

Also, iSH does have a package manager. It used to actually be modified to pull packages from the App Store but now they use a separate server. I don't remember if it's the Alpine Linux package repo or a custom thing for iSH.

[0] In fact, this was the excuse Apple used to ban it a few years ago

> iSH has nothing stopping you, the user, from wgetting arbitrary scripts or binaries and running them in the VM[0]

"Nothing stopping you" in the same sense that there's nothing stopping someone from using a sequence of specific gamepad button-presses to turn Super Mario World into Flappy Bird.

In vulnerability-exploitation terms, sure, the attack surface is there.

But in "would anyone actually spend time doing this" terms: no. The advantages don't outweigh the labor costs. (Especially if you're doing this for work, in anger, and you want to install an app to let you solve a problem right now by popping open a Linux terminal, and installing all the packages you need — including some arbitrary non-packaged SDKs that depend on dev-dependencies from specific known Linux flavors.)

Mind you, in theory, someone could make it easier for everyone else to do this, by writing a bootstrap script that wgets a bunch of stuff and effectively turns your iSH environment into e.g. Debian. But nobody has done this.

Why? I can't say for sure, but I suspect it's precisely because the iSH "sandbox" isn't actually a VM containing a Linux kernel, but rather an older technique — I think involving a userland of binaries compiled to use Darwin libraries; or maybe more likely, a userland linked to some Linux-on-XNU virtualization layer (custom libc, libresolv, etc.) And that's just not a "flavor" of Linux that you can find Debian packages for, or even third-party APKs for. Even if you built up your own apt base-packages repo to allow debootstrap to work, that wouldn't magically enable you to then find install deb packages from arbitrary apt repos that weren't compiled for the iSH "arch".

And I think that iSH continuing to exist on iPadOS, but persisting in doing this complex kind of virtualization rather than switching over to being "just VM software hard-coded to use a specific Linux VM", is perhaps on purpose. I'm guessing that Apple wouldn't allow "just a Linux VM" on the App Store any more than they allow UTM — again, precisely because it would unlock the capability to efficiently utilize arbitrary third-party packages, and thereby to actually use the iPad "in anger" for software-development business productivity. It would be "enough" of a development environment that some businesses might consider buying their employees iPads instead of Macs. And Apple really wants to avoid that.

> Also, iSH does have a package manager. It used to actually be modified to pull packages from the App Store but now they use a separate server. I don't remember if it's the Alpine Linux package repo or a custom thing for iSH.

It's a semi-custom thing for iSH, in that it's a custom "arch", with all the packages containing binaries compiled for the iSH virtualization layer. So you can't switch over/add on any third party repo; binaries from ordinary arm64 APKs wouldn't run. Third parties would need to create an iSH-arch release of their package specifically. And AFAIK there's no published infrastructure to enable third parties to do that.

In essence, though, the packages in this repo are still a "part of" the app. Despite being hosted on a third-party server, those packages still have to be signed — and I have a strong feeling that Apple, not the iSH dev, holds those signing keys. So Apple, not the iSH dev, gets final say over what APKs end up available in the iSH userland. (And that's why those APKs haven't been updated in a while — the iSH dev likely has to go back-and-forth with Apple when pushing out updates to their own repo — just as if they were publishing a new version of the app.)

If you're curious, iSH's source is public: https://github.com/ish-app/ish

You're correct that there is no Linux kernel emulation. They went with reimplementation for that. However, the userland is very much emulated x86 binaries. You can even compile your own C code inside iSH and run it. When you syscall, control passes from the threaded code[0] interpreter into the Linux reimplementation.

The reason why they aren't shipping Debian is that the threaded code technique being used as a JIT substitute in both iSH and UTM SE is far too slow to run a full Debian derivative. Believe me, I tried installing Ubuntu on UTM SE and it took literal hours and flattened my iPad battery in the process. iSH uses Alpine Linux because it's very lightweight[1].

As far as I'm aware there's no secret deal with Apple to lock iSH down. The only limitations I've ran into have to do with MySQL, which wants unaligned atomics, which you can't do on ARM64 without compromising the performance of the emulator. I actually had a discussion with the developer of iSH about this and put in a PR to make MySQL stop crashing iSH.

[0] return-oriented programming

[1] So lightweight it doesn't even ship anything GNU, making it one of the few genuine "Linux distros" with no slash or plus or "I would just like to interject"

iSH does allow you to download packages from the Alpine package repo, but they maintain their own mirror. The only issue is that they haven't updated it in a while, so its stuck at Alpine 3.14, and there's no (at least straightforward) option to upgrade to the later versions or to Alpine edge. I haven't yet tried updating the /etc/apk/ files to make Alpine upgrade though.

This isn't real "arbitrary package downloading", though — Apple still audits all the code that goes into these repos (which is why they can't just keep them up-to-date.) It's essentially just offloading of some of the app's packaged code into separate "DLC" modules, to make the base app download more lightweight.

> I haven't yet tried updating the /etc/apk/ files to make Alpine upgrade though.

I would highly suspect that this wouldn't work.

Maybe it would have in some prior version, back when there was the technical barrier of it being very hard to cross-compile Linux binaries for arm64.

But I would guess, upon the popularization of things like the Raspberry Pi, that Apple required the developer of iSH to modify the version of apk(1) that ships with the tool to only work with APKs that have been signed by Apple.