AuraBoot
Start free
English简体中文

Mobile Rendering (Mobile DSL Runtime)

This is not a Java SPI. AuraBoot has no MobileRendererExtension / MobilePlatform plugin extension point. Mobile renders the same Page schema with a native runtime, and rendering capability has the platform DslRegistry as its source of truth. Here is the real mechanism.

Same schema, native rendering

The page schema you drag out in the Page Designer (kind / blocks / fields) is rendered natively on iOS / Android by the mobile DSL runtime — not a WebView wrapper, and you do not model the page separately for mobile.

Capability source of truth = the platform DslRegistry

The single source of truth for every DSL rendering capability (BlockType / ChartType / PageKind / FieldType) is the platform Web DslRegistry (Java). The mobile apps re-declare these as native enums (Swift's MobileBlockType on iOS, etc.), mapping each one by code to a native renderer.

To make mobile support a given block / chart / field type, you implement a native renderer in the mobile app (Swift / Kotlin) whose code aligns with DslRegistry.

Silent-fallback risk + parity gate

If Web's DslRegistry adds a capability and mobile doesn't keep up, the mobile renderer silently degrades: MobileBlockType(rawValue:) == nil → UnsupportedBlockView; an unknown chart falls back to a bar. This kind of drift (blockType counts diverging) was the root cause of a past iOS gap round.

A parity gate check-dsl-mobile-parity.mjs (apps/ios/scripts/) guards it:

  • compares the committed Web capability snapshot against the iOS native enums, and fails CI for any code that Web has but iOS neither renders nor explicitly declares;
  • explicit, intentional divergences are written into dsl-mobile-parity.allow.json (marked nativeElsewhere / desktopOnly / deferred) — no silent allowances;
  • --refresh regenerates the snapshot from the OSS DslRegistry.java, and --check-snapshot detects cross-repo drift.

Common mistakes

  • Web gains a capability without syncing mobile: produces a silent fallback (UnsupportedBlockView / blanket bar) instead of an error. The parity gate stops it at CI.
  • Bare count comparison: comparing only "Web 30 vs iOS 28" misses cases — you must compare by the actual code sets (which code Web has that iOS doesn't).
  • Looking for mobile rendering as a Java extension point: there is no MobileRendererExtension — the renderer lives in the mobile app, and the platform only supplies the schema and the DslRegistry source of truth.

Related