Yes.
mob is double named
- short for mobile
- a (large) group
GenericJam
abuFahad-vp
This is almost exactly what I’ve been thinking about!
One difference in my approach: instead of embedding BEAM in each app, I’m considering a shared BEAM VM running as an Android service that multiple apps can connect to.
The idea:
-
One BEAM VM service running in background (~80-120MB total)
-
Apps bind to it via HTTP (localhost:8080) or AIDL
-
Each app spawns its own processes/GenServers on the shared VM
-
Or optionally spawn separate BEAM instances for isolation
Why shared VM:
-
One 80MB runtime instead of N copies
-
Apps can message each other via Erlang distribution if needed
-
Update the VM once, all apps benefit
-
Standard Android service patterns
Two modes:
-
Shared: All apps in same VM (lightweight, can communicate)
-
Isolated: Service spawns separate BEAM per app (better isolation)
Questions:
-
Why did you choose embedded-per-app vs shared service?
-
How do you handle the ~80MB ERTS size per app?
I was originally thinking Phoenix LiveView for UI, but your native component approach makes a lot of sense. Avoiding the server dependency and latency is huge.
Haven’t started building yet, just exploring the architecture. Would love to hear your thoughts on the shared VM approach!
0
GenericJam
The main reason why the BEAM needs to be in the app bundle is because the view tree is being directly modified by the BEAM via NIF. This is similar to if I was running Pythonx, Zigler or Rustler. I think this would be complicating my life a lot if I went with one shared BEAM per device and I don’t think devices are really that constrained for storage.
If I wasn’t using BEAM in the app I guess I’d have some sort of internal service that calls it or something just to facilitate maybe multiple apps. That’s too much overhead for a feature I don’t think anyone is asking for just to avoid depositing an extra 80 MB which is not that much given every phone has many GB these days.
I don’t think people are picking app frameworks based on build size.
I asked Claude to give a summary here:
- The BEAM VM itself (libharry.so at 4.2 MB uncompressed) is smaller than Flutter’s engine (~8 MB) and vastly smaller than the V8/Hermes engines React Native ships.
- The OTP stdlib (the ~80 MB on device) is the real cost — that’s all the .beam files for kernel, stdlib, crypto, etc. A production build could strip unused OTP applications and cut this dramatically. React Native has the same problem with its JS bundle + native modules.
- Debug vs release: debug APKs carry unstripped symbols. A release build with --strip would shrink libharry.so significantly.
- NativeScript at 97 MB APK is in a different category entirely — it bundles the V8 engine, the whole Node.js runtime, and the app JS in one shot.
Bottom line: Mob is very competitive. The VM overhead is lower than every cross-platform framework except Flutter, and the stdlib bloat is fixable with OTP app selection at build time. That’s a strong story.
I’m betting on Elixir because I think it brings enormous advantages. Many places are already using Elixir for backend (and frontend with LiveView) so you can also get both mobile platforms natively with the same language.
I’m betting on the BEAM because all the mobile work I’ve ever done I wished I had the BEAM. JS is ok but everything is built on callbacks. It doesn’t have a great fail mode story but it does have a pretty good async story. I don’t know enough about Flutter but people are learning Dart just to use Flutter. One language and one framework seems like a weird stretch to me. The alternative to those are basically native, so you pretty much need two teams or have extremely adaptable people.
This way combines all the benefits of native with the benefits of the BEAM and unifies on Elixir as the language. There will be a bit of platform glue but I’m hoping to keep that to a minimum.
2
derek-zhou
Process separation on the BEAM cannot be used as security boundary because everything can call everything else.. I do not want to share a VM with other apps, say, apps from Meta.
6
GenericJam
So far I’ve got the onboarding generator started which will deliver a hello world style app. It also gives you a random icon. If you knew where to put it you could do your own so that’s already supported but that will be documented later.
If you have the Android emulator and / or iOS simulator open it will push to those devices. I’ve also pushed to my Android phone manually.
I don’t have an iOS device so if anyone wants to give that a shot and report back that would be great.
https://github.com/GenericJam/mob_new
mix archive.install hex mob_new
mix mob.new my_app
cd my_app
mix mob.install
# both
mix mob.deploy --native
# ios only
mix mob.deploy --native --ios
# android only
mix mob.deploy --native --android
Give it a shot and tell me if it works for you.
I’ve only tested it on Mac. I’d be pleasantly surprised if it works on Linux. It would only be Android if it did.
Maybe long term we’d just support other platforms with a cloud service as most mobile development is pretty tightly coupled to Mac due to Apple’s requirement to build iOS apps on their machines.
0
GenericJam
I was wondering if the BEAM was too heavy for mobile - that’s what I had heard - but it’s really not.
From my benchmark, Claude:
With screen-on the numbers were noise, but here you can see:
- E (Nerves) at 202 mAh/h is essentially identical to A (no-beam) at 200 mAh/h — the BEAM overhead is within measurement noise. That’s a very positive result.
- D at 184 mAh/h looks suspiciously better than no-beam, which is probably just battery state variation (different starting voltages, temperatures, cell wear).
- B (untuned) at 250 mAh/h — 25% worse than no-beam, confirming the busy-wait flags matter.
The headline: with Nerves tuning flags, the idle BEAM is essentially free. That’s what you wanted to know
I copied Nerves flags and those seem to be fine.
https://github.com/nerves-project/nerves_bootstrap/blob/main/templates/new/rel/vm.args.eex
2
Damirados
Hi I have been working on Emerge for past few months. I am planning on getting to the mobile eventually with basically same idea you have here. It is just not the priority.
I think BEAM + EmergeSkia can be pretty small. EmergeSkia NIF ends up being around 6mb, there would need to be some stuff around mobile handling but I think it is possible to make whole mobile app base be around 12MB.
I am on purpose not following LiveView model since having templating like heex is direct result of HTML + CSS baggage and assigns model is copy of stateful React model which is not the happiest path to take, especially in functional programming languages. If you ever wrote non trivial LiveView/stateful React application you know that the model start falling apart quite quickly.
If you are interested in making mobile story around it I would be very happy to collaborate on that effort.
0
GenericJam
I’m planning on using a format similar to LiveView; more or less what was in use by LiveView Native. This tracks to users’ expectations and knowledge around how LiveView works and we get native looking apps so there is no second tier appearance like with React Native or whatever JS tools like Cordova that are some version of wrapped html. Users and designers consistently want native looking apps so this is the shortest path to get there.
I briefly considered Scenic which also writes via NIF but if we go that way we have to build our own layout engine but by going with the native view tree we get that more or less for free and it lines up with how developers already work and understand the system. It’s intuitive for LiveView devs and devs coming from other frameworks like React / React Native there will only be a short learning curve.
I have thought about the NIF route and there are interesting things there and perhaps we could use both. For example, if you wrote a mobile game and most of it was happening in the NIF, you could still have 1000s of processes making network calls and handling other aspects of game state. So I’d like to leave the door open to NIFs but that’s not my focus right now.
I need to build this out to stable and I’ll reach back out to you to see what a collaboration would look like there.
0