3 ms·

Its always been a sort of wink-wink agreement, never allowing exceptions as far as I'm aware. Its much more common to do post-release updates of JS than native,

Its always been a sort of wink-wink agreement, never allowing exceptions as far as I'm aware. Its much more common to do post-release updates of JS than native, but I think every native dev has done some form of dynamic code at some point. In one app we did, we ended up disabling the dynamic update but still ran a handrolled VM with dynamically interpreted code files which we baked into the app. Its all manually reviewed in the end, so no guarantees they would even catch it anyways.

brundolf 4y ago
Interesting. I'll admit I don't have much first-hand knowledge of the process > 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
- JamesSwift 4y ago
  We should be clear here that "JIT"/VM vs sandboxed code are two different considerations. Regardless of how your code is interpreted/compiled/run, you still are operating within the app sandbox. So most arguments about safety etc are fairly useless. The only "valid" line of argument is more in the UX space. Apple isn't able to vet the userflows in the same way if you do a post-release update. 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.
  - avianlyric 4y ago
    Preventing the execution of locally generated native code is a significant part of the iOS sandbox. It allows Apple to statically analysis binaries uploaded to the App Store and potential detect and prevent malicious instructions. Then they just need to harden the OS APIs, safe in the knowledge that you an app can’t execute arbitrary CPU instructions, and potentially escape kernel control. Allowing a JITed web browser on iOS means handing over the right mark arbitrary lumps of memory as executable, which substantially increases the available attack surface. 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.

brundolf 4y ago

Interesting. I'll admit I don't have much first-hand knowledge of the process > 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

JamesSwift 4y ago
We should be clear here that "JIT"/VM vs sandboxed code are two different considerations. Regardless of how your code is interpreted/compiled/run, you still are operating within the app sandbox. So most arguments about safety etc are fairly useless. The only "valid" line of argument is more in the UX space. Apple isn't able to vet the userflows in the same way if you do a post-release update. 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.
- avianlyric 4y ago
  Preventing the execution of locally generated native code is a significant part of the iOS sandbox. It allows Apple to statically analysis binaries uploaded to the App Store and potential detect and prevent malicious instructions. Then they just need to harden the OS APIs, safe in the knowledge that you an app can’t execute arbitrary CPU instructions, and potentially escape kernel control. Allowing a JITed web browser on iOS means handing over the right mark arbitrary lumps of memory as executable, which substantially increases the available attack surface. 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.