Hacker News new | ask | show | jobs
by trws 814 days ago
This is all technically true, but an IDE that cannot compile and run the code on the local device is missing something. The prohibition on JIT or otherwise compiling on device and running the result is a big blocker for a lot of true native dev experiences. I say this as someone who really mostly likes the App Store, but who would really like to be able to compile some code or run a VM with decent efficiency.
2 comments

Efficient VMs on iPhone would be great. I experimented with sideloading Jitterbug (1) and using it to launch qemu, but the process currently requires a second device or setting up a VPN - in practice it was annoying.

I just want/need a Linux environment; coming from my laptop, I really miss rsync… FTP/SMB over VPN work but rsync is usually faster!

Fingers crossed that easily sideloading apps becomes a thing here in the US.

1: https://github.com/osy/Jitterbug

Can ish not run rsync?
Sure, but does side-loading or alternate app stores of notorized apps mean that you'll be able to ship arbitrary JIT-enabled apps and apps which allow arbitrary execution of downloaded native binaries?
Yes. That’s the point. Edit: that’s too glib. The restrictions currently aren’t technical, they’re enforced by what is and isn’t allowed in the App Store. It’s perfectly possible to build the software on iOS today, you just can’t distribute it within apple’s rules
Not a JIT, iirc: from what I understand, without a specific JIT entitlement only Apple can give an app, it’s impossible to mark a memory page writable, write code to it and then mark it executable and run the code. This is a core security feature of the operating system.
That’s correct AFAIK, but assumes a specific kind of JIT. It’s entirely possible for a JIT compiler to produce shared libraries (dyld files in this case) which are then loaded into the process with dlopen. It’s slower to produce a compiled function or module this way, but we actually do it in practice to allow use of compilers that aren’t traditional JIT compilers or to work around similar selinux policies. This means something like luajit wouldn’t work out of the box, but a single-pass JIT binary translation like Rosetta would work fine. Same thing for a JIT like that used in Julia IIRC.