Components
One design system, drawn natively everywhere
Every OpenVibe component is described by what it is: its parts, the tokens they wear, its states, and how it reads to a screen reader. The web draws it with the kit; an Android or iOS app draws the same component with its own views, so an app is never a web page in a frame.
Empty state
What an empty list says: a title, one line, and the one thing to do next.
Parts and their tokens
- icon optionalcolor
color.accent.base - titleweight
type.weight.bold - text optionalcolor
color.text.muted - action optionala primary button
How it behaves
- Role
- status
- Props
title*texticonaction* required- States
- default
- Name
- its title and line
- Keys
- the action is one Tab stop
- Target
- 44 px
- Phone
- centred in the space
- Computer
- the same
Code
SwiftUI, on the theme file from Tokens (iOS): OvTokens (the theme you wear) for colour, OvScale for sizes.
// OpenVibe kit for SwiftUI: add the theme file from openvibe.design/tokens (iOS) and say which half the app wears.
typealias OvTokens = VibeDarkTokens // or VibeLightTokens, from @Environment(\.colorScheme)
enum OvKind { case primary, quiet, danger }
struct OvEmpty: View {
let title: String
var text: String? = nil
var body: some View {
ContentUnavailableView { Text(title).fontWeight(.bold) } description: { if let text { Text(text) } }
}
}Shared interfaces
Web, Android and iOS definitions for the navigation, composer, sheets, settings and motion used across OpenVibe. See the whole registry, or read it as JSON at /api/v1/components.
Kit documents: screens as data
A screen can be sent as a tree of these components, for example { "type": "rail", "children": [{ "type": "card", … }] }. Every OpenVibe client renders the same document with its own views, so a screen can change without an app release (the server-driven UI pattern of Airbnb and DivKit). Documents are checked strictly: known components and props only, typed values, which children each takes, a size limit, and https or same-site links.