Elixir on Mobile

Congrats to @dominicletz for creating the first (that I’m aware of) mobile app (Android and iOS) for Elixir! To find out more you can check out this interview.

I’ve been chatting with Dominic in Slack and here’s a summary so far:

BEAM … on mobile? …how?

The app works using a statically linked file which contains the BEAM. So the BEAM is bundled within the app itself. The app is basically running Phoenix with Liveview to present in a webview to display the app. Then there is some bridging code written in Swift (iOS) and Kotlin (Android) to talk to the platforms.

Webview?

Initially I was skeptical about running in a webview as that’s typically a more limited version of the app. However I think the ‘server’ running inside the app with direct access to the phone reverses most of the inherent disadvantages associated with webviews.

I’ve also been chatting with Shai Almog of CodenameOne fame. His take on this architecture:

If you would have asked me this 5-6 years ago I would have called this architecture bad. In fact Sun had a similar architecture for a product (I think JAF or something) which was a web server in a mobile device with a web UI. It was awful but that was on devices from 10 years ago.The chief problems I can see with this architecture are:

• Web is still problematic e.g. things like WebRTC don’t fully work on iOS web view without native extensions and that sort of weird nuances
• Web is throttled and limited within the app in iOS
• Androids web view is a nightmare between versions. I can’t tell you how much I hate that specific widget…
• Things like virtual keyboard behavior… Ugh, don’t get me started with those in all OSs
• There’s so many security concerns here. Web is generally pretty exposed and your app might be less secure as a result. Cordova apps are copied on autopilot and repackaged. They can also be reverse engineered easily

But on the positive side… Things improved a bit. To a degree that the Codename One Build app on iOS is a web app (built with the Codename One JavaScript port). Yes a native app would have been slightly better but not by much.So if you’re happy with the result then enjoy what you have. Just make sure to test all the rough edges and be aware of the potential problems.

Why not Flutter etc.?

Recently I was thinking about using Flutter as a frontend but now I don’t think that’s a very strong option as people would already know web development so we might as well just leverage that. Also it’s another abstraction, Google kills its projects, etc.

Why not roll our own frontend?

The only thing that’s even close to UI for Elixir (discounting wxwidgets) is Scenic. Eventually this could be an option but we would still have to create our own layout engine while we already have one that people know how to use in HTML/CSS.

Shai Almog on building our own:

I wouldn’t recommend going with the low level drawing approach unless you’re building a game. This took us a decade to get right in Codename One and honestly it’s still far from perfect. You need a huge budget for that and frankly most open source teams just can’t keep up with the amount of code that you need to write. Simple stuff is easy but complexity builds up quickly.
You don’t get away from the config problems here… This is just part of what you pay when you mix. We have similar issues when embedding native widgets into Codename One. I think the tradeoffs are OK for our case but it’s always a set of tradeoffs.
Electron does most of the logic in JavaScript and has quite a few of the problems I mentioned. The native portion in electron is tiny. It’s effectively more like Cordova.

Current Hurdles

Right now one of the biggest problems is going to be loading time. According to Dominic, the first load is around 10 seconds and subsequent cold loads are 3-4 seconds. If the app is backgrounded but not killed it is still running when it comes back. Faster load times would be desirable and figuring out how to hibernate when it gets killed would be good.

Hotswapping

Me:

Also have you thought about the possibility of hot swapping code and over the air updates? With RN there’s CodePush which works to a limited extend. I suspect with Elixir it would be even better eventually.

Dominic:

regarding hot-swapping we’re doing exactly that in our app at diode - all apps including mobile get fresh beam files now and then

Me:

Other things to consider

One of the major headaches in React Native is trying to get the native layer to play nice with the Javascript layer. You have to search for a solution, copy paste someone else’s configs and hope it doesn’t conflict. I would propose we work towards preconfigured solutions. So you want camera access and you have your target OSes, you download the appropriate configs that have been already vetted. Same conceptual idea as Docker hub.

In the longer term maybe we could offer Scenic and webview so you could just have both in your app and if you really want to draw straight to the screen you can.

Once again from Shai:

I’m very much for lightweight UIs. I want to determine where my pixels go. I don’t want a Google/Apple update to screw up my layout or design. But this is often a religious debate and opinions don’t sway here.

All we need now is a catchy name

My suggested name here is Chimera as it’s keeping with the theme of mythical beasts such as Phoenix and it will necessarily be a multi species effort.

Thoughts? Criticisms? Concerns? … Solutions?