5 ms·

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)

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.

hnlmorg 2y ago
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)
VHRanger 2y ago
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 2y ago
  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.
apatheticonion 2y ago
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?
- wmf 2y ago
  IIRC Apple also doesn't allow apps to load binary code at runtime. Redistributing derivatives of ROMs also sounds like a copyright problem.
  - apatheticonion 2y ago
    Could you recompile a ROM and embed it with a universal "emulator" game engine? (in the same way the OpenGoal project that recompiled Jak) I guess that would be illegal because you'd then need to distribute the game code. Perhaps a toolkit that allows users to compile the emulator+rom themselves? But then I guess Apple doesn't let users run their own unsigned binaries so that's not possible :/
- danielheath 2y ago
  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.
- avianlyric 2y ago
  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.
layer8 2y ago
You could write a web browser that supports ROMs as script source. <script type="application/snes" src="…"/> ;)
- kevingadd 2y ago
  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 2y ago
  Only if Apple approves it. They have time and money for lawyers.
  - extraduder_ire 2y ago
    Why would they need lawyers? They are writing and enforcing their own rules. I think enforcing compliance is more of an EU concern than yours.
phire 2y ago
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 2y ago
  I wonder how fast something like Forth-style direct threaded code could be on Apple silicon.

hnlmorg 2y ago

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)

VHRanger 2y ago

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 2y ago
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.

apatheticonion 2y ago

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?

wmf 2y ago
IIRC Apple also doesn't allow apps to load binary code at runtime. Redistributing derivatives of ROMs also sounds like a copyright problem.
- apatheticonion 2y ago
  Could you recompile a ROM and embed it with a universal "emulator" game engine? (in the same way the OpenGoal project that recompiled Jak) I guess that would be illegal because you'd then need to distribute the game code. Perhaps a toolkit that allows users to compile the emulator+rom themselves? But then I guess Apple doesn't let users run their own unsigned binaries so that's not possible :/
danielheath 2y ago
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.
avianlyric 2y ago
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.

layer8 2y ago

You could write a web browser that supports ROMs as script source. <script type="application/snes" src="…"/> ;)

kevingadd 2y ago
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 2y ago
Only if Apple approves it. They have time and money for lawyers.
- extraduder_ire 2y ago
  Why would they need lawyers? They are writing and enforcing their own rules. I think enforcing compliance is more of an EU concern than yours.

phire 2y ago

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 2y ago
I wonder how fast something like Forth-style direct threaded code could be on Apple silicon.