Native Surfaces

The current Vango posture for web, macOS, and iPhone targets.

Updated 2026-05-09Edit this page

Native Surfaces

Vango is web-first, but it already has a concrete path for sharing app code across web, desktop, and iPhone hosts.

Shared Layout Principle

For multi-surface apps, shared code stays in:

  • app/

  • internal/

Host-specific shells stay at the edge:

  • desktop/macos/*

  • mobile/ios/*

Web

Web is the canonical launch surface:

  • SSR first

  • thin client runtime

  • progressive enhancement

  • server-owned state by default

macOS

The recommended shape is one shared app plus a native host shell. Vango’s guide treats the bridge and host as separate from the app code rather than duplicating routes or components for desktop.

Native desktop hosts should serve app.Server().Handler() so app server middleware and any custom Server().SetHandler(...) mux behave consistently with the web host.

iPhone

Vango includes a scaffoldable iOS target and an explicit App Store posture:

  • embedded-first for trusted product apps

  • shared app code with a native shell

  • privacy and capability guidance as part of the platform story

  • generated entitlements from platform.ios.capabilities

  • APNs registration and push lifecycle hooks when push is enabled

  • Universal Links delivery through the native deep-link bridge when Associated Domains are configured

  • document import/export dialogs, clipboard read/write, deep-link receive, and local notifications

  • native StoreKit product query, purchase, restore, entitlement refresh, and subscription-management handoff when StoreKit is enabled

Current iOS commands include:

shell
1vango create --with ios
2vango run ios
3vango build ios
4vango archive ios
5vango export ios
6vango audit ios --testflight

Current limitations

  • App teams own their push provider/backend pipeline and product-specific notification semantics.

  • Sign in with Apple can collect native Apple credentials and scaffold an exchange hook, but app teams still need a real backend/provider exchange plus final session-auth wiring.

  • StoreKit runtime support and scaffolding exist, but app teams still own entitlement verification, App Store Connect product setup, and production billing policy.

Launch posture

Vango should be presented as a way to build bespoke product apps, not as a generic website-wrapper story. The framework docs are explicit about that distinction.