SDUX ▍
Author your UI once. Render it natively on three platforms.
SDUX is a typed UI tree authored on a Phoenix server and rendered by web, iOS and Android — each in its own idiom, with no shared UI code. Change a screen in production without an App Store release.
One authored page. Three renderers. No shared UI code.
How it works
Typed end to end
One Elixir module generates the OpenAPI contract, which generates the Swift and Kotlin models. A shape that doesn't exist doesn't compile — on any platform.
Semantic, never pixels
Layout is intent: gap, alignment, proportional width, when to collapse. Each platform owns the single map from token to concrete value, so a page reflows correctly on a phone, a tablet and a browser.
No release to change a screen
Your UI is data. Move a button, add a section, retheme a whole tenant — the clients already know how to render it.
This is a Page
No really, it is...Authored on the server. Already renderable by every client.
%Column{surface: :surface_sunken, padding: :xl, gap: :m, items: [
%Heading{title: "Go live on location", level: 2},
%Paragraph{text: "Stream your surroundings to the map."},
%SduxButton{
label: "New Event",
actions: [
%Haptic{intensity: :regular},
%LaunchForm{mode: :new, data_type: :sdux_event_data}
]
}
]}No platform branches, no feature flag, no build. The button's haptic fires natively on the phones and is ignored on the web, because the renderer decides what an action means.
Built on Phoenix and Elixir
A UI tree is data, and Elixir is a language for transforming data — the dispatch that turns one authored page into three native renders is pattern matching, not a framework. Every request renders in its own process on the BEAM, so a page that fails takes itself down and nothing with it, and latency stays flat as traffic climbs. The same PubSub that serves those pages relays live audio to the phones.