[KMnO4]

iSH has compiled the binaries for arm64 so they actually run natively. When they do a syscall to malloc they are actually doing a syscall to malloc.

iDOS is interpreting the bytecode and wrapping the unavailable things with its own implementation. When a DOS application runs malloc, the memory is assigned by iDOS instead.

I’m not saying Apple is consistent, but your example doesn’t show that well.

[meindnoch]

False. iSH is an x86 "bytecode" emulator.

"Possibly the most interesting thing I wrote as part of iSH is the JIT. It's not actually a JIT since it doesn't target machine code. Instead it generates an array of pointers to functions called gadgets, and each gadget ends with a tailcall to the next function; like the threaded code technique used by some Forth interpreters."

https://github.com/ish-app/ish

[kmeisthax]

You're thinking of a-Shell, which does offer compiled & locked binaries in a command line environment on iOS (via "ios_system"). Even then, they also support running WASM/WASI modules in a-Shell's command line environment.

[jmah]

Though it doesn't invalidate the gist of your saying, malloc is a user-space function not a syscall. (Its implementation will occasionally do a syscall, such as to sbrk or vmmap.)

[basique]

Isn't iSH literally an x86 emulator?

[doctorpangloss]

Yeah I mean, people think it’s a legal or engineering issue. If an App Store Editor (aka category manager) likes you, you will do alright.

[kmeisthax]

This is why App Store needs 'conceptual approvals'. I would never build anything 'cool' on iOS knowing that 'cool' things tend to piss off Apple.