why OTA update OS that frequently?

I've been lately into mobile apps and i am finding that there is no system which combines these 3

1. AOT 2. JIT (for hot paths) 3. Interpreter for non JIT paths or where you explicitly do not want jit.

Imagine, a system which compiles your app to AOT but when you push OTA update, part of the app are selectively replaced to JIT or Interpreted mode.

it's theoretically possible but nobody seems to be doing it. I found react native / expo eas update but i don't think it's like this, it has a Hermes VM which runs bytecode but it has no JIT so you'll write native code for hot path then you'll need to upload a full update to Android. So, only toy level code performance can be can actually be written in JS?

Much better, patch the parts where AOT calls into JIT or interpreter.

Currently i am using react native and flutter. Flutter's UI framework code is in Dart if you load this whole code into JIT, it will consume a lot of resources on mobile device as the framework is big and does lot of work. If all framework code was AOT and your custom patchable code also comes with AOT but upon OTA replaced by JIT or Interpreted code, crazy performance!

But what if we could run the most of the code in AOT and only run changed code in JIT or interpreted mode? arguably it would perform as good as it does not being complete AOT while also providing react native like fast updates.

▲

tcoff91 2 days ago | parent [-]

You can't update any AOT code due to how code signing works in these OS. And Apple completely bans JIT on iOS and iPadOS.

▲

faangguyindia 2 days ago | parent [-]

no, i am not asking for AOT OTA update.

AOT will be in base app and it will include JIT or Interpreted OTA updates.

For Apple, JIT can simply be disabled and OTA update can run patched part in interpreter.

But JIT works on Android (well), so this Hybrid system is capable of being much faster than React Native where your JS code only runs in Hermes VM which isn't JIT.

In this system, all your crazy math and algorithms (on hot path) stay easily updatable as this small part can be run on JIT with snapshot saved for next load if it has not changed!

JIT on average is 100x faster than dumb interpreter for language like Dart.

Does it already exist? otherwise i am seriously thinking about building something like this.

▲

Cloudef 2 days ago | parent [-]

Apple does not allow running code from internet either (even if interpreted iirc)

That said shipping JIT / interpreter with your program to recompile updates / parts of it sounds silly to me.

	▲	faangguyindia 2 days ago \| parent \| next [-]
		>That said shipping JIT / interpreter with your program to recompile updates / parts of it sounds silly to me. why is it silly? modern phones can easily do this (they are running local llm, what issue is with jit?), if it's done one time per update what's the problem? what's the problem with jitting couple of hot paths which have been updated and were not part of base app? >Apple does not allow running code from internet either (even if interpreted iirc) And how is React native expo/eas updates are working then? Isn't it downloading a bytecode bundle? Afaik, interpreter is allowed. JIT isn't?
	▲	tcoff91 2 days ago \| parent \| prev [-]
		There's 2 different parts of their terms about this. One seems to forbid it. The other basically says that you can do it as long as you aren't shipping some kind of update to the app that changes its nature significantly. Basically the generally accepted viewpoint in the industry is that you can OTA bugfixes and small changes but you if you ship whole features without going through app store review first you are definitely on thin ice.