For more than a decade, we have been building iOS and Android apps for our clients. We use both native and cross-platform approaches. A few years ago, we added a new method to our app development toolbox: Server Driven UI (SDUI). In short, SDUI combines the best of both worlds: native UX quality with the speed and flexibility of cross-platform.

One of the key reasons for its effectiveness is the speed of development. While it initially takes time to set up, with SDUI, new features can be rolled out without the apps having to lift a finger. The flows are built and released on the server. This allows for faster implementation of new features and complete flows.

Till now, we have been able to apply SDUI in about six different projects. One of them being the parcel tracking app for Dutch postal company PostNL. While SDUI may not be suitable for every project, it has been particularly effective for building an App Clip, widgets and other cool new features we’ve recently added in the PostNL apps. In this blog post, I explain how.

SDUI architecture

The development process of the PostNL apps followed the ‘classic’ approach: two native applications that connect to PostNL’s APIs, with the apps being responsible for presenting the information to the users. However, after the initial release of the app, there was a growing demand for faster implementation of new features in the app.

This is an interesting challenge that we also see with other projects. There are various solutions to this, each with its own advantages and disadvantages. After a few years of app development for PostNL using the traditional approach, it became clear to us that the time was ripe to introduce Server Driven UI (SDUI) to the landscape.

But what exactly is SDUI? My colleague Laurens described it as follows in a previous article: “Server Driven UI moves the responsibilities of what is visible on screen to the server. Effectively, the server defines which components are part of a screen and their order; these are described in the API. The apps render their native implementation of all the components. This allows the apps to deliver a high quality user experience with all features native to their platform.”

So, the ability to share logic is a significant advantage of SDUI, allowing for dynamic adjustments of screens and building complete flows from start to finish once across platforms. While cross-platform alternatives such as React Native or Flutter offer similar promises, they often come at the cost of app quality. With SDUI, you’re able to provide a higher quality user experience with all features native to both iOS and Android.

At PostNL, SDUI allows for a wide range of possibilities. Not only can the order of user interface elements be dynamically adjusted on individual screens, but entire flows can also be built from start to finish.This means that new features can be rolled out seamlessly without requiring any changes to the app source code, reducing app development effort.

In this blog post, I will not delve into the technical details and possibilities of the SDUI architecture itself, but rather focus on how it is implemented at PostNL. You can find more details about SDUI itself in articles by my colleagues Laurens and Sebastian.

Of course, this transition didn’t happen all at once.We have already implemented the vast majority of the necessary flows in SDUI, which means we already have a full toolkit to quickly build new features for the apps. The remaining flows are also on our roadmap for future implementation.

Scan & Go

One of the new features we recently built is Scan & Go. In short, this feature involves scanning and sending your package without having to wait in line at the checkout. For a PostNL pilot, it was necessary to build this new flow in the app. Previously, we would build the same flow for both iOS and Android. This means showing a starting point, such as a CTA button, from within the app and presenting a flow of scree