Skip to content

CONCEPT Cited by 1 source

Client release needed only for new primitives

The rule

In a server-driven UI system that adopts UI primitives as platform building blocks and server-owned schema versioning, the release boundary collapses to a single explicit criterion:

A client release is needed only when: 1. A new primitive is introduced, OR 2. An existing primitive's contract is extended to support a new behaviour (new prop, new event, new action type).

For everything else — new screens, new layouts, new variants, new A/B configurations, new tracking schemas — the server deploy is sufficient.

The verbatim version

Appcraft states this explicitly (Source: sources/2024-05-15-zalando-transitioning-to-appcraft-evolution-of-zalandos-server-driven-ui-framework):

"A client-release is only required when there's a need to introduce a new primitive or extend the contract of an existing one to support additional behaviour."

Worked example: Composite Label

The post gives one concrete example of an extension case:

"When a simple label was not enough, we decided to introduce a Composite Label with the ability to add subtexts with their own font styling decoration and sizing and this is currently the primitive used for example to render price due to its flexibility."

This is a new primitive — it goes into the client binary and therefore needs a release. Once shipped, pricing composition across all 13 Appcraft pages happens server-side without further releases.

What doesn't require a release (under this rule)

Change Release needed?
New screen entirely composed of existing primitives No
New layout arrangement No
New A/B cohort No
New copy / imagery No
New tracking parameter in an existing action No
Per-platform rendering variant No
Incident remediation (disable a component) No
Backward-compat logic update No
Deep-link → screen routing change No
New primitive type (Video, Composite Label, …) Yes
New prop on an existing primitive Yes
New event type Yes
New action type Yes

Why this matters

Mobile release cadence is asymmetrical:

  • Server deploy: minutes / hours, reversible within same window.
  • App Store release: days for submission + review + user adoption; rollback is another release, not a flip.

Collapsing the release boundary to "new primitive" means the frequency of App-Store releases drops to the frequency of primitive-vocabulary evolution — which is much slower than screen/content evolution. Zalando's post reports:

  • Two tracking-SDK migrations (2021, 2024) handled with only one mobile change (adopt new SDK); all per-screen tracking shipped server-side.
  • Multiple App redesigns with notably reduced mobile work for Appcraft-served pages.
  • Cyber Week incident remediation via server-side component disable.

How the rule emerges from the two upstream disciplines

The release-boundary collapse is derived, not primary:

Anti-patterns

  • Workaround that avoids the release by stretching a primitive's props beyond its semantic scope, e.g. encoding a "tooltip" into a Label's text via a delimiter because a Tooltip primitive hasn't shipped. This is the SDUI equivalent of god-column anti-pattern: the client has to parse the hack; the release gets deferred but the bug surface grows.
  • Shipping a "generic" primitive to avoid future releases, e.g. a GenericContainer that accepts arbitrary markup as a string prop. Kills the typed contract — now the "primitive" can render anything, meaning the client must understand everything.
  • Treating action types as props on an existing primitive, e.g. Button accepts a customAction: JSON prop. Same shape as above.

The discipline: extend the vocabulary when needed, with a release; don't circumvent it.

Seen in

Last updated · 550 distilled / 1,221 read