The mobile application development space is a fast-changing and ever-evolving environment. Over four billion people worldwide access the internet through their mobile devices. This accounts for more than ninety percent of all internet users, making the mobile experience very important. That’s why new technologies and frameworks are continuously emerging to simplify and improve the user’s experience on mobile.
Mobile development teams are always looking for faster, easier, and more consistent ways to develop and ship mobile experiences across multiple platforms (Android, iOS, and web). Iterating faster means the team can experiment more and provide a better user experience to their end-users. This in turn also improves the app’s conversion, retention and engagement. Server-driven user interfaces (SDUIs) are a relatively new approach in mobile development that can help you achieve this.
This article introduces the problems associated with the traditional app development approach and explains how SDUIs can help solve these problems and why you should start using them for dynamic content in your apps today.
In the traditional app development process, the app merely acts as a presentation layer, operating on data that is retrieved, stored, and manipulated on the backend.
During development, the code for an app’s user interface (UI) is written, which includes logic on how to display the data received from the backend. This code is compiled into a build, tested, and then submitted to Apple’s App Store or the Google Play Store.
Apple’s App Store has a review process that can last up to a few days, and the Play Store has a similar process. The review process involves the app being tested in its entirety, regardless of the change submitted (minor change or complete upgrade) against the app store’s increasingly restrictive guidelines. If approved, the app is made available for download to users. After this point, any changes to the UI will require your team to write, compile, and test new code, which you must again submit to the app stores for further review. Such changes include layout or colour modifications or even something as simple as a copy change. Upon approval, an update is made available and users have to manually update the app from the store.
A few problems are evident here:
SDUIs were developed to solve the problems of the traditional approach. The SDUI approach radically reduces the time taken to make UI changes by letting the server control and define the UI. In this approach, the server provides both the data and the UI of your app.
Using SDUIs, the server can control an app’s layout (in other words, the order and arrangement of the views displayed). This is done by defining standard components for different clients (eg, Android, iOS, or web) such as cards, list items, carousels, and buttons.
The server will then provide details on how and where to display these, creating a UI, which can be updated at any time on the server without writing additional code or going through a lengthy app approval process.
There are a number of advantages to using SDUIs.
The traditional process for updating an app is time-consuming. It also puts an extra burden on the user to update the app from the app store. With SDUI you can easily update your app's UI without going through the app store and users will instantly get the new changes.
With SDUIs, you can iterate faster on your UI. This gives you a significant edge over any competitors who are still using the traditional process. It also allows you to better address your users’ issues and consistently provide the best experience.
A/B testing, also known as split testing, compares different versions of your app to see which one performs better.
For example, you may want to experiment with different layouts on your home page to see which one leads to more conversions. Since SDUIs are controlled from the server and not hard-coded onto your app, it’s easier to present people with different screens and see which UI performs better. With SDUIs you can create interfaces beyond what was bundled with the app when released on the stores. This means you can make many different versions and use them to instantly track and learn what your users like.
If implemented well, SDUIs can significantly reduce your mobile development team’s workload. By leveraging SDUIs, you can reuse components and save time. Code for the components is written once, and new layouts and compositions can be created with minimal effort.
SDUIs also make developing UIs a team sport, allowing non-developers to be more involved in the process.
While you can implement SDUIs using a variety of libraries that are available, such as Airbnb’s Epoxy and Flipkart’s Proteus, the following sections will explain a basic (and framework agnostic) way of implementing SDUI in your app.
To implement SDUI in your app, two main things are required—predefined components and a layout schema:
These are ready-made views and widgets that can be composed into layouts. These components include elements such as buttons, list items, and grids. These are the core of your design system and can be arranged and rearranged to create new screens.
Though the predefined components are bundled into your app code, the server controls how they're arranged on your screen.
The server uses the layout schema to properly define view hierarchies and arrangement. This schema is essentially how you define a layout. A sample schema might look like this:
This crucial piece of data is passed from the server and is responsible for how your screens are rendered. From the example above, the data received from the server informs the app that it has to render a `LinearLayout`; within that layout, the app renders the child components, such as a `TextView` and a `HorizontalProgressView`. The dimensions and attributes of the views are also included so that you can easily customize your components.
The schema is a standard way of defining your screens; the server uses the schema to communicate how screens should be rendered to the app. Each screen has its own layout definition (representation) and can even have multiple definitions to take into account the different device sizes or A/B tests being conducted.
Some interesting challenges arise when implementing SDUI, which need to be considered if you want to make the best use of this architecture.
The UI for your app must be cached to ensure that your app works offline and also to reduce its data usage. Once the particular layout for a specific screen is received, it can be cached on a device to speed up subsequent renders and support offline usage.
The challenge here comes with implementing an efficient cache policy. The policy should allow for the fast rendering of the app but also needs to make sure the app always has the latest update of your layout. Too many updates and your app will be slow to render, too little and users will get new versions of the app late. This policy is further complicated if your app’s UI includes images and videos. The cache policy would need to be adapted for CDN storage and retrieval as well as on-device storage and refresh.
Additionally, your app must be designed/set up to update its UI whenever a new version of it becomes available. This should be done efficiently so that checking for updates does not consume too much of the user’s data.
While SDUI reduces the work required to code UIs, it doesn’t completely eliminate it. You might need to define new components or alter existing ones once your app is live. When new app updates are pushed to the store, it’s very important to maintain the server’s backward compatibility with existing versions of the app, which could contain older versions of the predefined components.
Controlling the UI interface from the server also comes with the extra overhead of supporting different theming options (*eg*, light and dark mode) for the defined layouts. It also means taking extra care to make sure all iterations are thoroughly tested for accessibility.
All components developed in our component library have to take into account accessibility concerns, different screen sizes and orientations, as well as the nuances of SwiftUI and Jetpack Compose. It may take months to develop a comprehensive component library. On top of this, there is a need to maintain and develop new components to cater for changes in your app and team.
---
In addition to all the complexities mentioned above, for a complete and effective SDUI system that can be used by the entire product team, an online dashboard would be needed. This dashboard could be used by product managers and designers to preview and deploy changes, as well as implement user segmentation and A/B tests. All this makes implementing SDUIs a daunting task for most mobile development teams.
While SDUIs do have significant benefits, the challenges outlined above mean that their implementation is beyond the capacity of smaller companies; the substantial resources needed for this approach tend to be feasible for larger and more established companies, such as Airbnb, Flipkart, and AliExpress.
This article introduced SDUIs, a relatively new mobile architecture that allows for faster iteration on products by bypassing app stores for UI updates.
SDUIs let you define reusable UI components on both Android and iOS; once defined, new screens can be designed once and deployed to both platforms instantly. SDUIs also allow you to experiment with different screen layouts without inconveniencing your users with continuous app store updates.
As a bonus, other team members (such as product and marketing) are given the opportunity to contribute to the development process, which reduces the burden on the dev team.
While SDUIs are hard to implement and traditionally used mainly by large companies like Spotify and Airbnb, platforms like Unflow help simplify the process and bring it within reach for smaller businesses.
Unflow handles the complexity of implementing SDUIs and gives you an easy-to-use SDK on Android, iOS, React Native, and Flutter. It comes with ready-made components for onboarding, banners, feedback forms, product updates and much more. The built-in functionality targets your users through preset and custom attributes. It also supports A/B testing out of the box. Try Unflow today.
A digital product manager by day, Michael is a tech enthusiast who is always tinkering with different technologies. His interests include web and mobile frameworks, NoCode development, and blockchain development.
