Build a Server-Driven UI Using UI Components in SwiftUI

Make changes to your app on the fly without submitting to Apple

Photo by Charles Deluvio on Unsplash

This article will talk about server-driven UI, its implementation using re-usable components called UIComponents, and creating a generic vertical list view for rendering UI components. It will conclude with a brief discussion of how UI components can serve different purposes.

What Is Server-Driven UI?

• It is an architecture where the server decides the UI views that need to be rendered on the application screen.
• There exists a contract between the application and the server. The basis of this contract gives the server control over the UI of the application.

What is that contract?- The server defines the list of components. For each of the components defined at the server, we have a corresponding UI implementation in the app (UIComponent). Consider an entertainment app like Hotstar, whose contract is defined as shown below. On the left are the components from the server, and on the right are the corresponding UI components.

Working — The screen does not have a predefined layout like a storyboard. Rather, it consists of a generic list view rendering multiple different views vertically, as per the server response. To make it possible, we have to create views that are standalone and can be reused throughout the application. We call these re-usable views the UIComponent.

Contract — For every server component, we have a UIComponent.

SwiftUI

Swift is a UI toolkit that lets you design application screens in a programmatic, declarative way.

Server-Driven UI Implementation in SwiftUI

This is a three-step process.

1. Define the standalone UIComponents.
2. Construct the UIComponents based on the API response.
3. Render the UIComponents on the screen.

1. Define the standalone UIComponents

Pictorial representation of UI-component

Input: Firstly, for the UIComponent to render itself, it should be provided with data.

Output: UIComponent defines its UI. When used for rendering inside a screen, it renders itself based on the data (input) provided to it.

UIComponent implementation

UIComponent.swift

• All the UI views have to conform to this UI-component protocol.
• As the components are rendered inside a generic vertical list, each UIComponent has to be independently identified. TheuniqueId property is used to serve that purpose.
• The render() is where the UI of the component is defined. Calling this function on a screen will render the component. Let's look at NotificationComponent.

NotificationComponent

• NotificationUIModel is the data required by the component to render. This is the input to the UIComponent.
• NotificationView is a SwiftUI view that defines the UI of the component. It takes in NotificationUIModel as a dependency. This view is the output of the UIComponent when used for rendering on the screen.

2. Construct the UIComponents based on the API response

HomePageController.swift

• HomePageController loads the server components from the repository and converts them into the UIComponents.
• The uiComponent's property is responsible for holding the list of UIComponents. Wrapping it with the @Published property makes it an observable. Any change in its value will be published to the Observer(View). This makes it possible to keep the View in sync with the state of the application.

3. Render UIComponents on the screen

This the last part. The screen’s only responsibility is to render the UIComponents. It subscribes to the uiComponents observable. Whenever the value of the uiComponents changes, the HomePage is notified, which then updates its UI. A generic ListView is used for rendering the UIComponents.

HomePageView

Generic Vstack: All the UIComponents are rendered vertically using a VStack inside. As the UIComponents are uniquely identifiable, we can use the ForEach construct for rendering.

Since all the components conforming to UIComponent protocol must return a common type, the render() function returns AnyView . Below is an extension on the View for converting it toAnyView.

Conclusion

We saw how UIComponent can be used to give the server control over the UI of the application. But with UIComponents you can achieve something more.

Let’s consider a case without server-driven UI. It's often the case that the pieces of UI are used many times across the application. This leads to duplication of the view and view logic. So, it’s better to divide the UI into meaningful, reusable UI-components.

Having them this way will let the domain-layer/business layer define and construct the UI components. Additionally, the business-layer can take the responsibility of controlling the UI.

You can find the project on GitHub.

Have a look at the article “Android Jetpack Compose — Create a Component-Based Architecture,” which explains UI-Components in detail. As it uses Jetpack compose-Android’s declarative UI kit, it wouldn’t be hard to understand.