Brainstorming on a mobile companion library for LiveView

This sounds really cool and I was going to suggest you look at Elixir Desktop.. but looks like you’re already aware of it Any reason in particular why it’s not what you’re after? Would your project just be for iOS/Android?

Either way good luck, I’m sure a lot of people will be interested in seeing what you come up with

Yes! elixir-desktop is just the opposite of what I’m after: it is an app running on the users device rendering all UI elements with web technologies.

What I want to achieve instead is a wrapper using platform native, navigational UI elements and displaying content and cross platform UI elements generated by a central server. (Like described here for Turbo: Basecamp 3 for iOS: Hybrid Architecture - Signal v. Noise)

And this also answers the second question:

Probably, since I don’t have use for anything else currently, but in the end it would be possible to write such a wrapper for any platform that can display a web view. The main problem will be to define the api making the communication between LV and the “native” components feasible.

A few thoughts (I may be out of my depth):

If you have web views you could use js hooks. There exists something similar with React (have not played with it). But: the client (the webview) needs to interpret what the server wants. So you need a bridge (in fact data that can be interpreted).

I guess the same approach could be taken with a native app.so the LivevView acts like a server"and owns the state. The reply tells the app what to display.

Interesting… Not sure about rendering native UI elements using LiveView, but for interacting with device feature via JS maybe you could reuse Cordova’s plugins?

And there’s also https://capacitorjs.com by Ionic

And regarding UI, if you’re satisfied with using a web view (at least for some parts of the app), then maybe something like CSS Components - Onsen UI - Onsen UI and JavaScript / Web Components API - Onsen UI - Onsen UI would plug-in in to LiveView nicely

ALERT: Unpopular opinion ahead.

For context I work as a Developer Advocate for Mobile API Security, and at work we need to maintain a lot of quickstarts and examples for hybrid frameworks, and what a poor developer experience it is to work with such frameworks, one worst then the other, but all them are a nightmare to maintain and keep them working on each developers machine, especially when sometime elapsed from its creation.

Not wanting to trash any JS suggestions, but if possible my advice is to stay away from them as much as you can. If you really need to choose one go for the one that as the more direct bridge (doesn’t build on top of others) and has the less complex build system, with fewer dependencies and moving parts.

If you build your own JS bridge, don’t go fancy with JS dependencies. Try instead to consolidate them under your own code. Yes, copy paste whenever the license allows. Managing security advisories in a huge tree of dependencies on JS land becomes sometimes impractical until other packages that aren’t direct dependencies of our project update their dependencies to fix the security advisory.

I need to parrot @Exadra37 on this. The beauty of something like turbo-ios is that it is really lightweight and precisely why we did not go with capacitor, react-native, flutter, etc.

Those frameworks are measured in million lines of code. If something goes astray, I don’t want to be the one trying to fix it. That’s one reason why I decided against using a cross platform solution.

The second reason is that you almost always need platform native code in any sufficiently complex project. And e. g. with cordova you then need to write a wrapper / plugin to make it available - so that’s another indirection.

And last but not least, I enjoy using apps which look and feels like the belong on the specific platform.

Precisely. The thing I’m most unsure of is how I could hijack the dom diffs that LiveView sends to then update the native components.

I also advise against wrapping your entire mobile app in an webview, because if then you need to harden the security of your mobile app you will be out of luck. Believe me that nowadays any “serious” app will need it sooner or later… Its not a question of if, but when. The when is normally when companies discover that they are vulnerable to some attack, or indeed under attack, or worst, already breached. At this point developers need to scramble for finding a solution and the business needs to deal with potential financial losses and angry users that may go away and never comeback.

Plan for your Mobile and API security from day zero, even if you don’t implement it, at least take it in consideration on your software architecture decisions to allow for an easier integration of security measures when you need to scramble to find one that is easy and quick to implement to defend against whatever attack you are suffering. A very important thing to keep in mind is to allow for the HTTP stack being used to be customisable with another one. This will come in hand when you need to add certificate pinning and other more advanced security protections to protect the communication of your mobile app with the APIs it uses.

I think it is possible to rewrite the client side of LV in Swift or Kotlin and maintain wire protocol compatibility with the server side LV. It is a much bigger job than turbo-ios but it can be done. The only significant dependency of LV is morphdom which have zero dependency.