Skip to content

CONCEPT Cited by 1 source

Same-day UI delivery

Definition

Same-day UI delivery is the cadence property where UI changes (screens, layouts, copy, A/B variants) can be authored, deployed, and visible to users on the same calendar day — independent of the app's native release cycle.

In a conventional mobile app, UI changes are gated by:

  • Sprint cadence — UI changes bundle into release candidates.
  • App Store review — iOS adds 24–72h of review latency; Android Play Store is typically faster but still non-zero.
  • User adoption curve — fleet rollout across iOS/Android takes weeks before the new UI is actually visible.

Same-day delivery shortens this to server deploy latency only, which for a Kubernetes-backed deploy is typically minutes.

How to achieve it

Three architectural disciplines together give same-day delivery:

  1. Server-driven UI — the server decides the UI shape per request; the client is a renderer.
  2. concepts/ui-primitives-as-platform-building-blocks — the client ships a narrow, stable vocabulary of primitives; composition happens server-side.
  3. concepts/server-owned-schema-versioning — all per-app-version compatibility logic lives on the server so clients don't need to re-negotiate schemas on update.

The consequence is the release boundary: client releases are only needed for new primitives or extensions, which happen rarely; everything else ships server-side same-day.

For new screens (not just variants of existing ones), add the fourth piece:

  1. concepts/deep-link-to-screen-config-resolution — deep-link indirection through a routing middleware so new-screen-creation is a server config change.

Appcraft's delivery shape

Appcraft is Zalando's production-proven same-day-delivery framework since 2018 (Source: sources/2024-05-15-zalando-transitioning-to-appcraft-evolution-of-zalandos-server-driven-ui-framework):

"Appcraft is designed to be agile and responsive to user needs, and such delays can hinder our ability to deliver a dynamic user experience. With the introduction of the Appcraft framework, the delivery is not tied to app releases or sprint duration, changes can be made at any point during a sprint."

Observed outcomes reported in the post:

  • Reduced MTTR for incidents via same-day remediation (disable a faulty component server-side).
  • Fast prototyping — new UI designs iterated with engineers + designers within one week.
  • Multiple App redesigns with notably reduced mobile engineering effort for Appcraft-served pages.
  • Cyber Week performance — the capability has survived Zalando's peak sales event multiple years running.

The tracking-migration stress test

A particularly strong proof-point from the post: Zalando migrated tracking SDKs twice (2021, 2024). For Appcraft pages, "all tracking events and their schema are defined on the server. The mobile client's only task was adopting a new SDK or in-house backend solution to pass by the events to the new analytics framework." Two SDK migrations × 13 dynamic pages = ~26 page-migrations that happened without per-page mobile engineering work. This is what same-day delivery buys: an entire class of cross-cutting change is reduced from "per-page client work × N" to "one-time SDK swap".

What it is not

Same-day delivery is not:

  • Hotfix capability in the traditional sense — it's stronger. A hotfix ships a patched app; same-day delivery doesn't need a new app at all.
  • Feature flags — those let already-shipped code change behaviour; same-day delivery lets new compositions ship without any new client code.
  • Over-the-air code push (like CodePush for RN) — same-day delivery is about UI composition changes under a fixed code surface, not runtime code replacement.

Same-day delivery is specifically about the composition surface being server-owned.

Trade-offs

Gains same-day delivery gives you:

  • Tight iteration loop with designers / PM.
  • Server-only incident remediation.
  • Decoupled tracking / analytics evolution.
  • No App-Store delay for content / layout changes.

Costs you pay:

  • Monitoring gap — Appcraft's post names this explicitly: "Sometimes issues arise and reach us only when they become urgent fixes." Fast delivery without matching observability is a footgun.
  • Render performance ceiling — client-side rendering of arbitrary server-composed trees is less optimisable than hand-written screens.
  • Platform complexity — building + maintaining the SDUI framework is non-trivial engineering.
  • Ownership fuzziness — the post names this: web developers authoring app screens blurs team boundaries.

Seen in

Last updated · 550 distilled / 1,221 read