Hacker News Reader

Comment by kmeisthax | Hacker News Reader

Apple is very weird with how they interpret that part of their rules. iSH is allowed but not iDOS, etc.

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.

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.)

Isn't iSH literally an x86 emulator?

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.

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.

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

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.

Reply on news.ycombinator.com