Earlier quoted context omitted.
A couple of things about native iOS apps. These are all a result of Apple controlling the walled garden and wanting to increase its revenue: -Apple limits what your app can do, e.g. apps can't spawn processes (FU Apple, this is bad for security/pricacy), can't do JIT compilation, can't download code, etc... -Apple rejects apps that compete with their own. -Apple removes apps that some governments want to have removed…
I really disagree with your argument - > -Apple limits what your app can do, e.g. apps can't spawn processes (FU Apple, this is bad for security/pricacy), What's the issue with that? Why would I want some random no-name devleoper randomly spawning processes on my device killing my battery life? How is it exclusively better for privacy? What prevents them from executing privacy-invading code as the separate process? >…
Processes (unlike threads) are for memory protection. There's no relation between the number of processes and battery life.
> What's the advantage when all the devices, your apps are supposed to be running on, share the same OS, platform, ABI etc? What's the point when the hardware is already limited in scope compared to alternative platforms
What if you want your users to be allowed to write code?
> Again, why would you want some random developer be able to download extra code?
Again, to allow users to share code (e.g. allow game mods).
> What prevents them from not misusing it for nefarious purposes?
The same thing that prevents them from having native code doing nefarious stuff: nothing.
> what prevents a third-party from compromising the developer's "update" servers and pushing malicious code?
Nothing, just like an native app can be compromised. That's why Native Apps are in a different process, and that's (one of the reasons) why Native Apps should be able to create their own processes (e.g. run a game mod in a separate process from the rest of the game).
> This is from a bygone era.
Okay, but this may happen again.