Interest in Elixir Mobile Framework?

I have no experience in this, nor any suggestions nor anything useful, but if I had a way of deploying a scenic app in mobile (both android and iOS) in a legit way as well as win/linux/macs I would have definitively gone that route for the game I’m building. I think that for a whole range of games that aren’t frame rate frenzy advanced 3d (tabletops, card games, strategy, even some rpgs and such) scenic could be a great fit. Instead I went for the final prototype as an Elixir backend, vue (static nuxt) for the frontend and pixi.js. The complexity is abysmal (but it only needs a compliant browser which is the reason why I opted for it).

Maybe lumen is a good fit for mobile?

But I don’t think it’s ready yet.

I think @boydm has commented in the past that Scenic is only aimed at devices with known/fixed screen dimensions. Given the variety of mobile devices you’d be targeting, that could be a major issue, but perhaps Boyd can clarify.

Given the amount of low-level work that goes into making these cross-platform mobile frameworks successful (and maintaining compatibility with the moving targets), I think you might be most successful if you piggyback on existing efforts. For example, writing an Elixir to Dart transpiler and supplying libraries that make the relationship to Flutter conventions transparent.

I am enthusiastic about the option to write any type of native code in Elixir, but I also see a trend in the other direction. People are weary of being chained to app stores, so there is more motivation than ever before to improve PWAs, the mobile web, etc.

Hey there.

It isn’t that Scenic is only aimed a fixed size devices… Is more that it doesn’t have a built-in auto layout engine.

You can query the size of the screen when your scene starts. You can also dynamically change the scale factors and other things. It’s just that there are all sorts of compromises and tuning you would want in order to get your UI to look good under a variety of aspect ratios. Any attempt to build a generic auto-layout tool is both difficult and would need to make a set of decisions that didn’t feel like they would be optimal for all cases.

Having said that, you could make an auto-layout engine, and in fact, people are working on just that.

So… If you are looking Scenic on phones where you are effectively running a single app on a variety of screen aspect ratios, you need to think through how to reposition things to keep it looking good. Or just have a lookup table that that picks on of serveral nice pre-made layouts.

Hi Boyd! Thanks for chipping in. I really like Scenic. Kudos for that.

I know in Android and iOS you can query the OS for the screen size so this is kind of what I’m counting on. I’d be over the moon if this was the biggest hurdle. I suspect just getting it to work (reliably) will be perhaps the most difficult.

@boydm Where would you start with getting it to work? I see some positive indications using Android NDK as well as being able to use imported C libs (possible to bring the BEAM in?) in Android and iOS. There are also cross platform build tools like Boden.

Well… there are two hurdles. I think the harder one is just getting the BEAM running at all. Although I haven’t paid too much attention over the past year (been working on a different port)…

After that …

I have a feeling the glfw driver might just work. Maybe? Decent odds of it

You could look at the approach that RubyMotion took. It’s a complete Ruby implementation on top of iOS and Android and compiles down to native code. You can use all the iOS or Android SDK and third-party libraries (depending on which platform your app is running on) plus all the Ruby standard library functions that were ported over, plus any cross-platform RubyMotion-specific third-party gems. I’ve written iOS apps in Objective-C, Android apps in Java, and iOS+Android apps in RubyMotion and I definitely prefer RubyMotion.

If you have a lot of time, you could try doing the same with Elixir

I think if you built an elixir equivalent of React Native, a very many people would be interested! I would say the best approach (for now) is don’t try to get the BEAM on these devices, just take the LiveView approach; and figure out how to handle the “no-connection” situation later.

So if I don’t need to change aspect ratio, can I dynamically change the scaling factor and center the scene and live with letterboxing or scrolling now?

I was in touch with someone that used to be involved in RubyMotion. Here’s their contribution:

I think the challenges are:

1. Exposing the native APIs (ObjC/Swift for iOS and Java/Kotlin for Android) to Elixir/Erlang. For that, you might need the ability to interface at the C level from Erlang, and be able to export the native APIs (for the case of Java, you could do that using JNI, this is how I did for RubyMotion/Android). You will need a way to tell the native world in case you start subclassing things from Erlang. In RubyMotion, I fixed that by reusing the native object system to Ruby (so that a Ruby class would always be an ObjC/Java class), if you use an existing Erlang runtime you will need to work on a bridge.

2. Being able to package the binary so that it can be submitted to the app stores. In the case of iOS, you will need the ability to code sign, and also you will need an Erlang runtime that does not JIT; last time I looked the official runtime has a simple interpreter? (So it might not be an issue.)

3. Probably other things that I can’t think of right now.

If I had to do it, I would look for an Erlang runtime that’s not too big and can be embedded; I believe I saw a few projects but you surely know more. I would also look for a runtime that I can easily tweak, so that I could interface it with ObjC/Swift and Java (through JNI).

Seems doable albeit not easy.