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.
