Here's already another platform that does just fine with sandboxing. It's been running for 27+ years. It's called a the web browser. Restrictions against using private APIs.... you can't call any private APIs, it's impossible. Find an exploit? It's generally fixed in a few days.

Software isn't even installed, new versions are downloaded daily or more so the concept of sandboxing as been throughly tested and proven effective for those 27 years.

The difficulty with that argument is that Apple has gone out of their way to make webapps second class citizens. PWAs can't do everything installed apps can.

And that's before we get into resource usage.

But that's not the point - the point is, sandboxing largely solves these issues without the need for restrictions on side loading, restrictions to a single app store or similar abuses of consumers rights.

Apple should build a better sandbox, the idea that "private APIs" exist and the only thing stopping them from being used is a basic string search on the app store review is pretty horrifying.

And then you notice that your browser demands almost the same amount of resources as a 60+fps 3d game for presenting you a just a bunch of static images and some text. It is apples to oranges comparison, because a performance requires an unsandboxed, non-emulated native env, which is hard to protect from exploits. Replace a browser with any OS in existence and see how secure it is to execute an arbitrary binary on it.

> performance requires an unsandboxed, non-emulated native env

Nope, sandboxing is largely orthogonal to performance.

You can't be serious.

All iOS jailbreaks are a result of security vulnerabilities, which Apple tends to fix almost as soon as they're discovered - and ultimately, it's Apple's responsibility to make their sandbox secure, regardless of what's running in it. I also don't see how installing outside apps would make jailbreaks any easier, given that you can already connect your phone to a computer and temporarily install an app on it (and for people who are motivated to jailbreak, this isn't much of a hurdle).

I haven't done enough iOS development to know for sure, but I'm assuming Apple could prevent private API usage by apps through technical means, rather than just app review.

Kind of. They cannot prevent private API used by their frameworks running in the same process as the app (e.g. an app can use an Apple UI widget, for example). Things that apps should generally not be able to do have already started being locked down using entitlements, which prevent third-party apps from using those APIs regardless of whether they can sneak it past review.

> and for people who are motivated to jailbreak, this isn't much of a hurdle

And also because, once you’re jailbroken, you can setup software to automatically resign the app on-device every few days, so you never need a computer again.

I thought jailbreaking worked by using exploits to disable code signing. As in, there’s no need to sign an app. Have things changed the past few years?

Most Jailbreaks today are "tethered" in some way, which means the Jailbreak disappears (to varying degrees†) once the phone is turned off. For Jailbreaks like unc0ver, this means you need to re-run a bootstrap app every time you reboot your phone, in order to return to "Jailbroken" mode and allow unsigned code.

This, of course, is a catch-22. You need to run an app to allow unsigned apps, but that app can't run if it isn't signed.

---

† The community makes a distinction between "tethered", "semi-tethered", and "semi-untethered" jailbreaks. The jailbreak I described above is "semi-untethered". You really couldn't come up with terminology more prone to getting mixed up...

I’m aware of the distinction between the different kinds of jailbreaks; I just hadn’t been keeping up on the news regarding them. Thanks!