Server Driven UI for mobile apps

Manage your mobile app User Interface via your backend service. The pros and cons, and how does it work?

Traditionally, mobile apps call a server to retrieve domain objects (usually as JSON) and the app then renders these objects to a user interface (UI) which is built and packaged inside the app. The frontend is deciding what should be rendered and the business logic and UI is driven from the frontend.

In a Server Driven UI framework, the UI is also sent from the backend along with the content. The server decides what and how it should be rendered. The server is sending instructions back to the app and driving how it should display. This sounds very familiar, it is how HTML works. Server Driven UI is about finding the right balance between rendering existing components in simple way without having to add too much complexity.

Main reasons for implementing Server Driven UI

Mobile releases take a lot of time. The App store review process takes time, as opposed to a backend release, which only needs internal approval. When releasing apps, Google and Apple manually review the apps. Once they are approved they can be submitted and are available for people to install or update on their phone.

Extra time should be allocated for testing during the release phase, compared to a backend release.

Mobile releases cannot be rolled-back instantly. The only option with a failed release is to send out a new version that fixes the previous release bugs. (This will still require to pass the Google/Apple approval process, plus the user will need to install the latest version)

Not all users upgrade their apps. A small percentage of users will be running older versions of the app. This produces a versioning problem, where you can have your audience seeing a different UI in your app based on the version they have installed.

How does Server driven UI work?

When you look at a traditional MVC (model view controller) architecture. We can think of server driven UI as moving the model and the controller to the server. Then the UI client becomes the view. The business logic is guaranteed by an API contract, which abstracts away the underlying model implementation.

Think about something like a card that appears on one screen. In traditional UI development that might be a post or a book, but in a server driven UI world, that is just a card. It doesn’t matter if it’s a book, or an author or a movie. What matters is how it fits into that view.

That is server driven UI.

Pros of Server Driven UI

There are several benefits of implementing a server driven UI architecture:

• We no longer require members to update the app to show some updated UI (as long as we use the existing layouts and components)
• By having automated tests on the reusable components we have more confidence in the release process
• It becomes faster to release new features
• There is less logic in the frontend making iOS and Android codebases less complex
• Frontend developers can focus on building the components and amazing UI and the deep domain knowledge is kept in the backend

Cons of Server Driven UI

It’s not all roses. You will need to assess if SDUI is right for your app:

• There’s a large investment upfront
• Response times can be affected based on load (especially when your servers also contact downstream services) and customers are used to native apps being fast and always available.
• Your API might require versioning — it’s important to think about making client-side code backward-compatible

Conclusion

Although there is an upfront investment required to build the components and then put all the business logic into the backend, I believe the pros outweigh the cons. Once you start shipping changes to an app by modifying some backend properties in a fast and reliable way, you will never go back.

Information has been prepared for information purposes only and does not constitute advice.