SDUI stands for Server Driven UI, where the server defines the UI and the client renders it accordingly. On iOS, it’s easy to implement with SwiftUI and Codable.
To implement SDUI, I designed the basic architecture. The overall flow follows this structure: Scene → Layout → Implementation for each SwiftUI Component.
Since SwiftUI components conform to the View protocol, I created a CommonComponent conforming to a shared View protocol, and designed each component to have its own unique properties.
When used with Firebase Remote Config, UI can be updated in real-time.
Thoughts after implementation
Using SDUI allows UI updates even after release, which is very convenient. However, you should implement fallback rendering using a default JSON structure in case of network failure. Also, flexible event handling might be limited.
When developing apps, we often use multiple analytics tools, which makes it important to design a manageable architecture. I studied various approaches through blog posts and synthesized their pros and cons to create a design of my own.
The architectures from those blog posts had similar patterns. Common features included declaring a list of trackable events and custom parameters using enums, implementing senders for each analytics tool, and managing them through a central manager object.
Reference Links
UIColor(resource:) will autocomplete the resource name excluding the word “Color.” For example, if you name it potatoColor, it will be used as UIColor(resource: .potato).backgroundColor might conflict with the existing background, as “Color” is omitted in autocompletion.