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.

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.

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