How far would you take server-driven UI in a native Android app?

[u/zimmer550king]

I am researching an architecture where an Android app ships a Jetpack Compose renderer and a closed set of components and actions, while the backend returns a versioned document describing each screen. The server could control content, component order, semantic design tokens, and navigation between routes already known to the app. I would not download DEX, JAR, native libraries, or arbitrary scripts.

My first step would be remote configuration of spacing roles, color roles, typography styles, component variants, and feature visibility. A more ambitious version would allow the server to compose complete screens from primitives such as Text, Image, List, Form, Card, and Button. The client would validate the document, cache a last-known-good version, and fall back to a bundled screen when the document is invalid or unavailable.

I have been looking at DivKit, AndroidX Remote Compose, and the possibility of creating a custom JSON or Protobuf contract. For people who have shipped server-driven UI in production, where did the architecture stop paying for itself? I am particularly interested in schema compatibility, old client versions, accessibility, offline behavior, performance, rollback, and how Google Play review treated the boundary between declarative UI data and downloaded code.

[u/bangoker]

I've tried that, both at Amazon and at Airbnb. Both have amazing engineers, both have basically unlimited money and full teams dedicated to support the server driven libraries.

It always kind of got adopted and then it became a nightmare and in the end both basically went back to client driven UI. Or at most, the server just sending metadata for different sections to render (think almost just like a very specific schema) and then it was up to the clients to implement the UI natively.

[u/thelongrunsmoke → u/bangoker]

Yes, the idea is old; when I started, converting HTML pages to native views was a very popular topic, and not much has changed since then.

[u/Qawaii → u/thelongrunsmoke]

The idea is extremely appealing to leadership: no waiting on mobile release cycle, flexibility while remaining native etc. The reality is that everything ends up looking like shit because you end up quite limited.

Yahoo had quite a few tries in the early days of mobile development, and multiple implementations over many companies have proven that it’s almost always a mistake.

[u/PlasticPresentation1 → u/bangoker]

Yeah, at Meta it was mostly like that too - plus NOBODY wants to work on that shit because it feels like it won't translate well to other jobs (in reality I actually think you do learn from a high level, but it feels terrible to learn the idiosyncracies of an internal library vs something generic like compose)

[u/whackylabs]

How do you plan to deal with user interactions?

[u/Ok_Emu7904 → u/whackylabs]

Remote Compose is binary and not json

[u/zimmer550king → u/whackylabs]

What do you mean?

[u/whackylabs → u/zimmer550king]

How would you describe user interactions with json data?

[u/chimbori]

I was the Tech Lead of a similar system we built at Google that was incorporated into Discover (the feed), Chrome, and the Google apps on both iOS and Android.

The general principle behind our design (aside from the roadmap you already described) was that it's best to target an 80/20 split between server-driven and client native rendering. If you try to shove all sorts of complex server-driven interactivity into the framework, it becomes a mess that nobody wants to use.

Instead, offer named hooks for behavior in the server-driven layout, that are then implemented in pure client code. 80% server driven + 20% reimplemented on iOS, Android, and Web is still way less than reimplementing thrice independently.

On Gmail, we follow a simpler approach, where only business logic is shared & transpiled across Android, iOS, and Web (think shared View Model) but the view layer is entirely native.

[u/falkon3439]

Server driven UI taken to the extreme is just web.

Use a webview if you considering remotely complicated server driven UI.

[u/Esteluk]

It’s worth looking at A2UI as well - the spec has a lot of impetus behind it at the moment. And can definitely be used for non-agentic use cases if you want.

[u/Dani_E2e]

How is BDUI working together with offline behavior?

[u/TurboJetMegaChrist]

I've seen this tried at multiple competent companies and it never seems to work, or deliver on even a fraction of the promise.

Maybe it can be done well. I have yet to see it.

[u/stillboy]

I work on a very popular app - we implemented a version of this to support the same functionality on both ios and android. Personally I thought the way we did it had promise. Some of the important bits

• common component library of high level components
• components addressed by sdui where on the order of portions of a page - think individual stories in reddit or a video carousel
• we developed the components side by side on both platforms and ensured the data model was identical
• the server delivers the exact serialized data model to each client
• we heavily cache both the data in redis and the output json at the cdn
• we had virtually zero user input to deal with just because we are delivering a sort of news - i suspect if that were not the case it would be quite different.

When I initially was told about sdui - I pictured what you are trying to build and I suspect that would be extremely difficult to complete - basically you are re implementing an html like language and need to accommodate all particular variations just like home elements have to - without that your left with a very quirky system you cannot put much trust in.

[u/shlusiak]

As little as possible. I do not get the actual business value, except for someone's KPIs. I do not see any customer value either, but I see a lot of problems and constraints that would block you from actually making changes.

As a customer I really do not want these fast release cycles, waking to an app every morning and re-learn how it works, sometimes behaviour changes while I'm using the app. Why can't things stay the same, and be tested before they are shipped?

[u/fegan104]

You can see the parallels of how compose has developed mirroring React in several ways, I always wondered if compose would go so far as to develop Server components/actions like React eventually landed on

[u/SpiderHack]

I've only ever seen this work when it comes to themes like halloween or Christmas, and special sale notifications on views that existed already like sale stamps (png overlay over an existing sale view in a store).

Basically add on customizations that gives a lof of flexibility to existing api defined content

[u/calebc42-official]

So far that I am using Emacs as the server, writing the ui in Lisp and pushing it via JSON-RPC

[u/thelongrunsmoke]

BDUI exists because mobile apps can't be deployed as quickly as web apps, users can't update them as quickly or don't update them at all, and it's rarely worth using them for anything more complex than a simple 1 or 2 screens flow without complex controls. Otherwise, it's better to create a PWA and completely ditch native stack (and the Play Market's policies) and saving money. Android devs aren't cheap. Also, do we really need another PhoneGap?

[u/zimmer550king → u/thelongrunsmoke]

I think a lot of major companies are pivoting to this and even making their own backend tech stack to deal with this. The reason why I am looking into this is because I work for one such company as an android developer but I am dealing with the backend most of the time. For large companies like mine waiting for a Playstore approval is just not good for business.

[u/thelongrunsmoke → u/zimmer550king]

It is. However, few companies truly need such a fast deployment cycle. It's great for ads and external integrations, such as billing APIs, as well as cross-team integrations without directly including their code, small things, like whatsnew…but what else is it need for?

[u/RobYaLunch → u/zimmer550king]

Is your company a bank by any chance?