Illustration of caucasian man in shorts climbing a mountain sign at top says phoenix liveview native

Note: This post reflects my experience working in LiveView Native before the recent (official) 0.3.0 release.

I recently tried my hand at creating a Phoenix LiveView Native app. This new technology promises to bridge the gap between web and native application development, allowing developers to write Elixir code for both platforms. And while the concept is exciting, I quickly learned that getting there wasn’t as easy as I’d hoped.

The Hope: A Seamless Transition

My initial plan was straightforward. I’d take an existing Phoenix LiveView web app and seamlessly transform it into a native iOS app. I’d simply write Elixir code once and then deploy it to multiple platforms. The reality, however, was a bit more complex.

The Reality: Struggling with Versions and Dependencies

The first challenge I faced was upgrading Elixir, Phoenix, and LiveView. The app to which I wanted to add LiveView Native was an old personal project, so the versions of each of the above were pretty outdated. Once updates were complete, I could actually install and configure LiveView Native, which in and of itself wasn’t too bad, but this led me to my next issue: a dependency pickle. 

Without going into too much detail, I had a dependency that required the latest version of LiveView Native, but I had started this project when LVN was still on 0.2.0. The problem was, at the time, the latest version was still a “release candidate”, so some of the documentation was hard to find. (If I had waited a few weeks, the full 0.3.0 release would’ve been out, complete with all the docs.) It was at this point that I sort of flailed around for a while, looking for answers. Eventually, I found a pull request for the new documentation in the LiveView Native repo! While it was a work in progress, the PR had enough information to fill in the missing pieces I needed to get my app working on mobile.

Xcode (aka Challenge #2)

Another frustrating aspect of the project was working with Xcode. It’s, without a doubt, a powerful tool, but it’s also notoriously difficult to navigate, especially for those who are new to iOS development. I spent several hours troubleshooting build errors, configuring simulators, and dealing with Xcode’s quirks. However, one of the nice things about LiveView Native is that all of the Xcode project files are generated for you.

A Hard-Fought Win

Despite the challenges, I eventually managed to get my app running on the iOS simulator. It was a small victory, but it gave me a sense of accomplishment. I was able to use the same core logic that I’d developed for the web app, only needing to write some new templates for the mobile layout, demonstrating the value of LiveView Native.

A few key takeaways I recommend considering if you’re thinking of giving it a try:

  • Embrace the community. There is a vibrant community of LiveView developers that can provide support and guidance.
  • Don’t be afraid to experiment. The best way to learn LiveView Native is to dive in and experiment with different approaches.
  • Be patient. Building a mobile app, especially with a new technology, takes time. Don’t get discouraged if you encounter setbacks.
  • Start Fresh. I think my experience would have been much smoother if I had started with a totally new app, rather than trying to adapt and upgrade an old project. (not to mention starting with the latest version of LVN.)

The Future of LiveView Native

I believe LiveView Native has the potential to bring Elixir to mobile app development, and into the Phoenix / LiveView ecosystem as a whole. The ability to use a single codebase for both web and mobile apps can significantly reduce development time and costs.

Want to chat more on this topic? Let’s connect. We love this stuff!

We're building an AI-powered Product Operations Cloud, leveraging AI in almost every aspect of the software delivery lifecycle. Want to test drive it with us? Join the ProdOps party at ProdOps.ai.