fwiw: the App Store also prohibits JITed code or in general code pulled in after app publishing. I guess the idea is that (at least in theory) that Apple sees all code that an app runs.
For example you can write a mini-app that connects to bluetooth. It's essentially loading dynamic code that bridges to native code.
https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...
https://apps.apple.com/us/app/bluefy-web-ble-browser/id14928...
So what? Apple has never required review of every web page you load with safari, regardless of which browser APIs they use... the browser is the browser. That is the farthest Apple goes on "dynamic content" but yes, it is potentially a pretty wide net given the various APIs and extensions. But from Apple's perspective it is also a defined boundary.
The only exception they've crafted is for educational purposes.
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
But I think they draw the line at native (read: unsafe) code, which, is not totally unreasonable
> but I think every native dev has done some form of dynamic code at some point
This is a little ambiguous; theoretically a VM - even a custom one - would still be above-board because the native code is static. My understanding was that the main problem with third-party browsers is third-party JS engines, but only because any modern JS engine has to JIT in order to perform the way people expect; the app developer takes responsibility for generating unsafe native code, which has the potential to wreak all kinds of havoc on the user's system in a way that dynamically-updated JS code for example can't
It would be interesting to try and submit a fully-custom browser with a non-JIT JS interpreter to the App Store. I bet they'd allow it; just, nobody would use it because it would be slow as mud
And to be clear when I say a handrolled VM, I mean that the VM knows how to interpret dynamic things into native things. This is a lot more powerful in Objective-C since it uses message passing anyways so you could theoretically build a full app in some JSON payload. So sure your native code is static, but thats because its just 1 function called 'eval'. This is still possible in Swift but requires more explicitness since it doesn't have the same dynamicism built in.
It doesn't have to be entire apps that are custom though. Most app devs use it for things like customer-editable content. Think of things like the ability to update home screen layouts, or tab layouts/behavior. Depending on how much baked-in customization you build this can be extremely robust.
Having said that, I strongly suspect concerns around arbitrary code escaping kernel control only applies to older iPhone running substantially less sophisticated SoC than you find in a modern iPhone. Certainly any Apple SoC during the M1 era, and a good few generations before, have all the modern accoutrements needed to allow arbitrary code execution, while ensuring the kernel can always intercede and halt execution or block dangerous calls. If they didn’t have these abilities, then there’s no way an M1 Mac could efficiently run a VM, or be considered a secure platform by modern standards.
> Dynamic testing includes everything from battery usage to file system access and privacy requests to access device hardware like the camera and microphone, while static analysis checks app size, entitlements, in-app purchases, keywords, descriptions, and more.
> In 2015, Apple discussed acquiring SourceDNA, a company that made a tool to allow companies to see the code inside apps. Apple did end up purchasing the company and using its engineers to design a new tool for app oversight.
https://forums.macrumors.com/threads/apple-rejected-approxim...
We know this because when dev submit apps that call private APIs they get very quick rejection. But hiding private API call behind obfuscated blobs of dynamic code can get you through app review, provided you don’t expose the functionality in your UI.
Additionally the modern App Store deployment process involves uploading you app in an intermediate format, only partially compiled, so apple can dynamically recompile your app to target new CPUs, and optimism your app to use new hardware without intervention by the dev.
[1]: https://apps.apple.com/us/app/pyto-python-3/id1436650069