[OatmealDome]

Notably, Apple still does not allow non web browsing apps to use JIT recompilers. This precludes emulators for 6th generation and newer consoles (GameCube, etc) from running on the platform even with this guideline change.

I submitted a DMA interoperability request for JIT recompilers, but Apple denied it on the grounds that it doesn't fall under Article 6(7) for "multiple reasons", including that JIT is only used by web browsers on iOS.

[apatheticonion]

I'm not an expert in emulation but I am curious if one could recompile ROMs AOT such that JIT is not required by the emulator?

Say, statically recompile the ROM on your PC then move the emulator-specific binary to the iOS device.

Would such an approach be permissible by Apple? Is it possible to do so while sharing the source code for the JIT layer?

I suppose the binary format must itself be natively compatible by iOS otherwise you'd need to have a JIT layer for your binary format - right?

[avianlyric]

Historically the justification for limiting the use of JIT compilers is for security reasons, which does actually stack up.

JIT compilers are one of few use cases where an application absolutely needs the ability to write data to memory, mark that memory region as executable, and then execute the op codes in that memory region. On iOS, other than Safari, no application, either built in or installed via the App Store is allowed to change memory permissions from writable to executable, and that acts as a cornerstone in iOS application sandboxing.

Now there’s perfectly good argument that the security argument doesn’t really stack up anymore, given that sandboxing technologies have progressed a lot, and it should be possible to properly sandbox a JIT compiler or similar. But there’s no denying the fact that removing the ability for an application to execute arbitrary created op codes is a very good way to completely eradication a huge surface area for exploits. Especially when such restrictions are paired with static scanning of binaries before signing (which happens when any binary is produced for iOS, via Apples signing service).

All of that is to say, there is a possible world where ROM are transpiled for iOS devices (using something like Rosetta), and loaded as signed binaries via emulation wrappers. But at point you’re basically having to create your own App Store, and sign a new app for each transpiled ROM.

In short, it doesn’t seem likely we’ll see JIT powered emulators on iOS anytime soon, and, at least in this specific instance, Apple has a legitimate security reason for restricting their usage.

[wmf]

IIRC Apple also doesn't allow apps to load binary code at runtime. Redistributing derivatives of ROMs also sounds like a copyright problem.

[danielheath]

You could do Rosetta style conversion up front of the complete binary to get around the JIT ban, but that’s still loading code at runtime.

[Wowfunhappy]

> Say, statically recompile the ROM on your PC

Basically impossible.

https://andrewkelley.me/post/jamulator.html

[VHRanger]

Luckily for us both the Nintendo switch and the iPhone run ARM64, so you don't need a JIT to run yuzu/ryujinx on a phone!

The bad news is that yuzus team is disbanded and never got the moltenVK backend done. And Ryujinx never got theirs to work on a phone.

[comex]

That doesn't really help unless you bundle the game code inside the app executable. Otherwise you still need a JIT entitlement in order to map code as executable.

[phire]

There is a lot of space between interpreters and a full JIT that is under-explored. Because developers typically skip straight to a JIT when they find a interpreter isn't fast enough.

Dolphin does have the cached interpreter, which eliminates some of the decoding overhead of a traditional interpreter, but I think you could go a lot further. Convert the PowerPC instructions to a optimal bytecode and apply various optimisations to that bytecode (function inlining, constant propagation). Common pairs and sequences of instructions can be replaced with a single bytecode implementation.

Given how fast Apple's cpu cores are, I suspect it might be possible to get a optimising bytecode interpreter fast enough so GameCube and other 6th gen console emulators can run at full speed.

[int_19h]

I wonder how fast something like Forth-style direct threaded code could be on Apple silicon.

[layer8]

You could write a web browser that supports ROMs as script source.

   <script type="application/snes" src="…"/>

;)

[kevingadd]

Considering the number of ads I see for "gaming browsers" like Opera GX, I wouldn't be surprised if someone tries to sneak an emulator onto the store that way

[amelius]

Only if Apple approves it. They have time and money for lawyers.

[hnlmorg]

Earlier than the GameCube even. The N64 audio was a programmable chipset (it’s late in my timezone so please forgive me for not including the full technical details here)