Over a week ago I released LiveView Native v0.3 which is finally the version we recommend for everyone to use. Over the next few weeks and months, we’ll be rolling out educational content in blog posts and videos as well as continuing to ship improvements to LiveView Native such as the Jetpack (Android) client. In this post let’s start simple and outline what this project is and what benefits it will bring to your organization.
LiveView Native is Not a WebView
LiveView Native is a framework for building 100% native UI on multiples of devices. With LiveView itself being a server-side rendered framework for building web applications it is easy to draw the conclusion that LiveView Native is simply a WebView running on a device that uses HTML/CSS for rendering native-like UI.
That couldn’t be further from the truth.
LiveView Native renders an actual first-class native UI view on the device. We accomplish this by representing those native views in our own markup format alongside a stylesheet system for representing how each UI framework styles its applications (i.e. modifiers for SwiftUI)
Using the LiveView programming model, we send very small UI diffs over a socket connection to the device and build actual Native UI view trees to merge into the device’s UI framework primary view tree.
This approach has several benefits:
1. Build State Management and Event Handling Once
Because we are leveraging the LiveView programming model, if you already have a LiveView application built you already have 75% of the work done to build a LiveView Native application. State management and event handling are shared between target destinations.
It doesn’t matter if the connected client is a web browser running LiveView, an iPad running LiveView Native SwiftUI, or a Samsung phone running LiveView Native Jetpack. All of the code for establishing the connection, setting up the data, managing the data between events, and making state changes (whether they’re the result of an event from the client or a PubSub event the LiveView is subscribed to) — all of this is done once. Then you simply add templates to represent the UI that each device should display.
2. Faster Time to Market, Lower Costs
Because the vast majority of native application building is being removed in favor of a single, server-side solution, implementation and ongoing maintenance costs are drastically reduced. In fact, in our internal testing we saw cost savings over other common industry solutions of at least 40%. The more devices and the more platforms you add support for, the greater the savings.
3. Immediate Mission-Critical Updates
We do not skip the app store’s review process, but we do offer a server-side solution that will allow you to make permitted changes (per app store rules) on critical bugs that may otherwise take days to clear the review process. You can roll these changes out immediately.
4. Keep Your Team Small and Focused on a Single Technology Stack
Technology costs are becoming unsustainable for many companies, and if you want to have your brand and products everywhere your customers are you likely need to manage multiple divergent technology stacks. One team for your back-end server, one team for your front-end web, another team for Apple (Swift) products, and yet another team for the Android (Kotlin/Java) products.
With LiveView Native, you can optimize your entire technology team on a single stack. This brings down operational costs significantly, increases developer performance, and creates a greater and more cohesive team building your products, all while requiring fewer people overall to get the same job done.
We are not a build-once-run-everywhere framework, but we can deploy to more devices than anyone
Our approach is simple, we do not believe in the one UI framework approach. History has spoken on this issue: people do not like it. You know when you’re using an application that is not built using the first-class UI framework. It is easy to spot—I call this the Uncanny Valley effect of native application development. They feel very close but something is always quite not right.
Don’t get me wrong, there is appeal from a cost perspective of not having to repeat work. But there are also UX expectations for customers on their devices. Is the risk of turning people away because the application “doesn’t feel right” worth the benefit of not having to write an additional device-specific UI?
In the case of most other native unified UI frameworks, the answer is “yes” because the alternative is you must go and use SwiftUI and Jetpack directly then have to write all of the native app state management logic over and over again.
With LiveView Native, we wrap the first-class UI frameworks. In other words, we are letting Apple and Google do all of the really hard work of defining how applications should look, feel and behave on their own hardware. In fact, because we are targeting the first-class UI frameworks directly we can also deploy to every single device those frameworks compile to. With the release of LiveView Native v0.3, we can build applications for every single device in the Apple family today:
- iPhone
- iPad
- Apple TV
- Apple Watch
- Mac
- Apple Vision Pro
Yes, including their AR headset. We can do this because we do not need to rebuild the entire ecosystem. For example, if we need maps we simply wrap Apple’s own MapKit (which we’ve already done) library. If we need augmented reality we simply wrap Apple’s own RealityKit (mostly done, should be released before EOY).
This keeps LiveView Native way ahead of the other native unified UI solutions (such as Flutter & React Native). If Apple were to release a new product with a screen (e.g. the often speculated HomePod update) odds are they will use SwiftUI and we will immediately be ale to build for it because we are using SwiftUI.
This exact same principle will apply to Jetpack and the Android family of devices. And it will carry through when we build our Windows client. Imagine building LiveView Native apps for Xbox!
We invite everyone to give LiveView Native a spin and see for themselves. We’re building something different here that has vast potential to enable brands to always be on the latest and greatest hardware with the best experiences for their customers.
Take note of some navigation performance improvements that are coming in v0.3.1 of live_view_native_swiftui.
Keep an eye on the DockYard blog for more LiveView Native content. Follow @liveviewnative for updates!
