Open Source PC Emulator UTM Blocked by Apple for Notarization, Including Through EU Marketplaces
Michael Tsai:
This is confusing, but I think what Apple is saying is that, even
with notarization, apps are not allowed to “download
executable code.” Rule 2.5.2 says apps may not “download,
install, or execute code” except for limited educational purposes.
Rule 4.7 makes an exception to this so that retro game
emulators and some other app types can run code “that is not
embedded in the binary.” This is grayed out when you select “Show
Notarization Review Guidelines Only”, meaning that the exception
only applies within the App Store. Thus, the general prohibition
remains in effect for App Marketplaces and Web Distribution. But
it seems like this wasn’t initially clear to Apple, either,
because the review process took two months.
This also seems inconsistent with the fact that the Delta emulator
is allowed to be notarized outside the App Store. It doesn’t
make much sense for the rules to be more lax within the App
Store. I first thought the mistake was that Apple didn’t mean to
gray out 4.7 for notarization. Then everything would make sense.
But the clarification states that 4.7 is not intended to apply
to notarization.
The bottom line for me is that Apple doesn’t want general-purpose
emulators, it’s questionable whether the DMA lets it block them,
and even siding with Apple on this it isn’t consistently applying
its own rules.
Apple’s stance on this seems inscrutable and arbitrary: retro game emulators are, at long last, acceptable, but general PC emulators are not. Such arbitrary policy decisions related to the purpose of the app are fine for the App Store (legally speaking), but clearly not compliant with the DMA. That’s one of the few areas where the DMA is clear. Apple can, of course, ban (say) porno apps from the App Store, but can’t refuse to notarize them for distribution outside the App Store in the EU.
Apple has a security leg to stand on when it comes to JIT compilation, but the version of UTM (UTM SE) that was held up in review for two months, and ultimately rejected by Apple, doesn’t use a JIT. And because it doesn’t use a JIT, performance is poor; hence the UTM developers’ deeming it not worth fighting about. Apple goes into depth on the security challenges pertaining to JIT compilation in its documentation for BrowserEngineKit, the framework for developing non-WebKit browser engines for distribution in the EU. That’s ostensibly the reason why developers need a special entitlement to use a custom browser engine — JavaScript engines need a JIT to perform well but JITs pose a security risk.
In an earlier revision of this post, I suggested that Delta — Riley Testut’s excellent and wildly popular retro Nintendo console emulator for iOS — uses a JIT. There is a JIT in Delta’s source code repository, but Testut informs me that it’s currently only enabled through the version of AltStore distributed through sideloading. Delta’s JIT is removed from the versions of Delta in the App Store and AltStore PAL (the EU app marketplace), because of Apple’s restrictions on JIT compilers. No app with a JIT is going to pass review by Apple, including for distribution outside the App Store in the EU. That restriction might be permitted under the DMA on security grounds. But how the no-JIT version of UTM could be rejected for notarization, I do not see.
(Thinking about BrowserEngineKit makes me wonder: Now that over four months have passed since Apple announced its initial DMA compliance plans, has even a single browser developer announced plans to bring their own rendering engines to iOS in the EU? As far as I know the answer is no. It’s entirely possible Apple went to all the trouble of creating BrowserEngineKit for compliance with the DMA, but no one is actually going to use it because no browser developer deems the EU market worth forking their browser for, solely for distribution outside the App Store — while on the hook for the Core Technology Fee if such a browser becomes popular.)
★
Michael Tsai:
This is confusing, but I think what Apple is saying is that, even
with notarization, apps are not allowed to “download
executable code.” Rule 2.5.2 says apps may not “download,
install, or execute code” except for limited educational purposes.
Rule 4.7 makes an exception to this so that retro game
emulators and some other app types can run code “that is not
embedded in the binary.” This is grayed out when you select “Show
Notarization Review Guidelines Only”, meaning that the exception
only applies within the App Store. Thus, the general prohibition
remains in effect for App Marketplaces and Web Distribution. But
it seems like this wasn’t initially clear to Apple, either,
because the review process took two months.
This also seems inconsistent with the fact that the Delta emulator
is allowed to be notarized outside the App Store. It doesn’t
make much sense for the rules to be more lax within the App
Store. I first thought the mistake was that Apple didn’t mean to
gray out 4.7 for notarization. Then everything would make sense.
But the clarification states that 4.7 is not intended to apply
to notarization.
The bottom line for me is that Apple doesn’t want general-purpose
emulators, it’s questionable whether the DMA lets it block them,
and even siding with Apple on this it isn’t consistently applying
its own rules.
Apple’s stance on this seems inscrutable and arbitrary: retro game emulators are, at long last, acceptable, but general PC emulators are not. Such arbitrary policy decisions related to the purpose of the app are fine for the App Store (legally speaking), but clearly not compliant with the DMA. That’s one of the few areas where the DMA is clear. Apple can, of course, ban (say) porno apps from the App Store, but can’t refuse to notarize them for distribution outside the App Store in the EU.
Apple has a security leg to stand on when it comes to JIT compilation, but the version of UTM (UTM SE) that was held up in review for two months, and ultimately rejected by Apple, doesn’t use a JIT. And because it doesn’t use a JIT, performance is poor; hence the UTM developers’ deeming it not worth fighting about. Apple goes into depth on the security challenges pertaining to JIT compilation in its documentation for BrowserEngineKit, the framework for developing non-WebKit browser engines for distribution in the EU. That’s ostensibly the reason why developers need a special entitlement to use a custom browser engine — JavaScript engines need a JIT to perform well but JITs pose a security risk.
In an earlier revision of this post, I suggested that Delta — Riley Testut’s excellent and wildly popular retro Nintendo console emulator for iOS — uses a JIT. There is a JIT in Delta’s source code repository, but Testut informs me that it’s currently only enabled through the version of AltStore distributed through sideloading. Delta’s JIT is removed from the versions of Delta in the App Store and AltStore PAL (the EU app marketplace), because of Apple’s restrictions on JIT compilers. No app with a JIT is going to pass review by Apple, including for distribution outside the App Store in the EU. That restriction might be permitted under the DMA on security grounds. But how the no-JIT version of UTM could be rejected for notarization, I do not see.
(Thinking about BrowserEngineKit makes me wonder: Now that over four months have passed since Apple announced its initial DMA compliance plans, has even a single browser developer announced plans to bring their own rendering engines to iOS in the EU? As far as I know the answer is no. It’s entirely possible Apple went to all the trouble of creating BrowserEngineKit for compliance with the DMA, but no one is actually going to use it because no browser developer deems the EU market worth forking their browser for, solely for distribution outside the App Store — while on the hook for the Core Technology Fee if such a browser becomes popular.)