Multi-platform delivery
One manifest, four platform targets — what is generated for each build, what stays native, and how the experience is kept consistent.
One configuration, multiple platforms. A community lists its targets in platforms, and the same manifest drives every build. The experience is mobile-first; desktop builds share the same product configuration.
Targets
platforms value | Artifact | Family | Status |
|---|---|---|---|
ios | Signed iOS build for App Store or TestFlight | mobile | Available |
android-apk | Signed Android APK | mobile | Available |
macos | Notarised macOS app | desktop | Available |
windows | Signed Windows installer | desktop | Available |
iOS and Android clients run today in the reference deployment as native SwiftUI and Jetpack Compose apps. A community adds a desktop client by listing macos or windows in platforms; the desktop build shares the same product configuration. Generating a branded build directly from a Symorva manifest is part of the developer preview.
Duplicate entries in platforms are reported as platforms.duplicate and each platform is built once.
What is generated per build
| Input | Manifest field | Result in the app |
|---|---|---|
| Identity | community.name, community.id | Display name, product slug and application identifier stem |
| Icon | brand.appIcon | Launcher icon; a text monogram is used until artwork is supplied |
| Colours | brand.primaryColor, brand.accentColor | Light and dark palettes for every native surface |
| Appearance | brand.theme | Fixed light, fixed dark, or following the system |
| Languages | community.locales | Bundled locales and the default language |
| Navigation | enabled modules | Tab bar in module order, from the deployment plan's navigation |
| Capabilities | each module's options | Feature flags that hide entry points for disabled options |
| Endpoints | deployment.domain and environment | Environment-specific API and real-time endpoints |
The navigation for a manifest is visible before any build:
symorva plan --json["Community", "Meetings", "AI Studio", "Wallet", "DApps"]Chat contributes the Community tab, then Meetings, AI Studio, Wallet and DApps in catalog order. The creator economy has no tab of its own; it appears inside the surfaces of the modules it extends.
How builds are produced
The approach is the one the reference deployment uses for its own clients:
- Validate. The brand manifest and its referenced locale, asset and design-token files are validated as one model.
- Generate. Native constants — identity, palettes, locales, capability defaults, asset keys — are generated into Swift and Kotlin source and Android resources from that single model. Each generated file carries a hash of the canonical model; the Swift and Kotlin hashes must match.
- Check. A check mode regenerates and compares. A hand-edited or stale generated file fails the build.
- Build variants. Each environment gets its own application identifier — for example a
.devor.stagingsuffix — so development, staging and production builds install side by side and never share data. - Sign. Artifacts are signed with the operator's own signing identities.
Generated files are never configuration authorities in their own right. To change a colour or a label, change the manifest and regenerate.
Native UI over a shared core
Clients do not share a UI renderer. Each platform renders with its own toolkit and follows its own conventions for navigation, gestures, accessibility and system integration. Consistency comes from a shared headless core instead:
Manifest + design tokens + UX contracts
│
generated native brand constants
│
headless core interfaces
│ │
SwiftUI product UI Compose product UI
│ │
platform provider adapters
│
community server APIs + messaging SDK- The headless core owns product state and rules: conversations, messages, relationships, membership.
- Native UI modules own rendering, navigation and operating-system integration.
- Provider adapters translate transport and operating-system types at explicit seams, so UI code never depends on the messaging core's models.
Cross-platform agreement is tested at the product interfaces and against shared reference states, not by comparing pixels. See Client SDKs for the preview interface.
Localisation
Product copy is maintained in one shared catalog and generated into native resources for each platform; native string files are build outputs, not separately edited translations. The reference deployment maintains six canonical languages this way: English, Simplified Chinese, Traditional Chinese, Japanese, Korean and Thai. community.locales selects which languages a community ships, using BCP 47 tags such as en or zh-Hans. Languages outside the maintained catalog require operator-supplied translations.
What a brand cannot change
A manifest can change identity, presentation, copy selection and enabled capabilities. It cannot change the business rules of conversations, messages, relationships or communities. Two communities with different brands behave identically for the same module configuration.