Skip to content

CONCEPT Cited by 1 source

Appcraft interoperability

Definition

Interoperability in Appcraft's sense is the problem of mixing Appcraft-rendered content with non-Appcraft (classically-native) content inside a single mobile app session:

  • Non-Appcraft → Appcraft: embedding a classically-native iOS/Android view inside an Appcraft screen.
  • Appcraft → non-Appcraft: embedding an entire Appcraft screen inside a larger non-Appcraft feature (the Zalando example: a Home Screen with tabs, where each tab is an Appcraft screen hosted in a non-Appcraft tab container).

The problem shape is generic to any mixed-stack UI architecture — the SDUI client runtime and the native host code need to agree on a composition seam.

Zalando's framing

Appcraft names interoperability as an open challenge — solved-in-principle but still evolving in 2024 (Source: sources/2024-05-15-zalando-transitioning-to-appcraft-evolution-of-zalandos-server-driven-ui-framework):

"We are currently addressing another significant challenge, known as Interoperability, which refers to the reuse of existing non-Appcraft components in Appcraft and vice versa. To tackle this, we've introduced the capability of embedding non-Appcraft components in Appcraft screens and the embedding of entire Appcraft screens within larger features. Examples of this can be seen on the Tabular structure on Home Screen where each tab is an appcraft screen."

Two directions:

  1. Non-Appcraft-in-Appcraft — an Appcraft primitive effectively wrapping a native component (e.g. a platform- specific map, an AR surface, a complex payment widget that hasn't been decomposed into Appcraft primitives).
  2. Appcraft-in-non-Appcraft — an Appcraft screen embedded as a sub-view of a non-Appcraft screen (the Home Screen tabs example).

Why it's hard

Mixed-stack embedding surfaces every tension that pure SDUI avoids:

  • Lifecycle coordination — when the outer host pauses (e.g. tab switched off), the Appcraft sub-screen needs to pause its Elm update loop; likewise for scroll-coordination.
  • Navigation ownership — does the Appcraft child handle its own deep-links, or does the host intercept them?
  • Event propagation — tap gestures, scroll deltas, keyboard focus.
  • Theming + design-token consistency — both worlds need to render to the same design system.
  • Version-negotiation surface widens — now the server must emit screens compatible with multiple embedding contexts, not just a full-screen Appcraft app.
  • Debugging — a crash in an embedded Appcraft child can look like a host-code bug and vice-versa.

Design decisions (inferred from the post)

The post doesn't detail the implementation; it confirms that:

  • An embedding capability exists in both directions.
  • The Home-Screen-tabs case is a live production instance of Appcraft-in-non-Appcraft.
  • Interoperability is described as an ongoing challenge, not a solved problem — i.e. the seam is working but the design space is still being explored.

Adjacent concepts

Appcraft interoperability sits on this continuum: a prior- generation (2018-era) variant of the mixed-stack challenge, using server-driven JSON rather than cross-compiled code as the cross-platform substrate.

Why this matters for SDUI systems generally

Pure SDUI — where the entire surface area is server-authored — is rare in production. Real apps have:

  • Platform-native integrations (maps, AR, biometrics, OS pickers).
  • Legacy features predating the SDUI framework.
  • Performance-critical features (video players, real-time gaming UI) that benefit from bespoke native code.

Any SDUI framework that wants to serve the whole app eventually has to solve interoperability. Appcraft's 6-year trajectory is a concrete instance: it solved same-day delivery for 13 dynamic pages, then hit interoperability as the next frontier.

Seen in

Last updated · 550 distilled / 1,221 read