Apps

From the web to Android and iOS, without a frame

An OpenVibe app is never a web page in a frame. Every platform draws the same parts with its own views: the tokens, the components, the patterns and the icons on this site. The web stays the source of truth, and an app follows it screen by screen.

One screen, three sizes

Not three designs: one set of parts, arranged by how much room there is.

Four layers every platform shares

1TokensColour, type, space, radius and motion as data (DTCG JSON). Android gets a Compose theme, iOS gets OvTokens and OvScale, the web gets CSS variables: one source, three files.2ComponentsEach part described by what it is: its pieces, the tokens they wear, its states and how a screen reader hears it, with code for the web, Jetpack Compose and SwiftUI.3PatternsThe rules production taught, each with the bug behind it, a live demo, and SwiftUI and Compose specs generated from the same tokens.4IconsOne glyph set for every platform: SVG and a font for the web, vector drawables for Android, PDF vectors for iOS, the same names everywhere.

Size classes

The platforms’ own window classes. The web’s bar folds at 760 px today; apps follow these.

ClassWidthPlacesAddingAn open item
Compactunder 600 pxA bottom tab bar, five places at mostA floating New over a sheetFull screen; Back returns to the list
Medium600 to 839 pxA navigation rail of iconsNew at the top of the railSide by side from 720 px
Expanded840 px and widerA sidebar with wordsNew at the top of the sidebarThe list and the open item together

What each platform does its own way

Back
Closes the top sheet or menu first, then leaves the screen. Android’s predictive back shows where it goes; on iOS a sheet swipes down and the edge swipe goes back; on the web, Back closes the menu before it leaves the page.
Safe areas
Nothing sits under the notch, the home indicator or a system bar: bars pad themselves by the insets, content scrolls under them.
Text size
Dynamic Type and Android font scale up to 200%. Rows wrap and grow; nothing clips or truncates a name to an ellipsis it did not need.
Motion
Durations from the motion tokens (180, 260, 360 ms); reduced motion removes entrances and keeps state changes as instant swaps.
Touch
Every target is 44 px (48 dp on Android). A press becomes a drag only after 6 px.
Haptics
A light tap when something is confirmed or sent (apps only); never for scrolling or ambient changes.
Your look
The theme you wear on openvibe.design reaches apps through the same tokens (GET /api/me/theme), so the app looks like your sites.
Notifications
Web push on the web; FCM on Android and APNs on iOS through OpenVibe.Network, with the same quiet hours and the same Do not disturb.

The road from here

  1. NowPhones first on the web

    Every site at 390 px: no sideways scroll, 44 px targets, sheets instead of popovers, Back that closes them. Measured site by site.

  2. NextInstall from the browser

    A manifest and an offline shell for each site people use daily, so it opens like an app and the last screen shows without a network.

  3. PlannedAndroid

    A Compose shell. Native screens first where the web cannot reach: messages, the Live player, the camera, and Link’s phone automation (accessibility). Other screens render kit documents with native views. A direct APK first; Google Play when the account is opened.

  4. PlannediOS

    A SwiftUI shell with the same screens and the same documents. The App Store when the account is opened.

  5. PlannedDesktop

    The OpenVibe app: Codes and Link in one native shell, with your machines, your agent and your files.

A screen as data

A screen can travel as a tree of kit components. The web draws it with the kit; an app draws the same tree with Compose or SwiftUI, so a new screen reaches every platform without a release.

{ "type": "rail", "title": "Trending",
  "children": [
    { "type": "card", "title": "A rainy night walk", "meta": "23 views this week", "href": "https://openvibe.video/v/6119" }
  ] }

Ready to become an app screen?

  • It is made of kit components, not one-off markup, so each part has a native twin.
  • Every colour, size and duration is a token; no literal hex in a rule.
  • At 390 px nothing scrolls sideways and nothing is hidden to make it fit.
  • Adding is one button; its choices are in a sheet.
  • Back closes what is open before it leaves.
  • It reads well at 200% text.
  • It works with reduced motion, and with JavaScript off on the web.
  • Its data comes from a documented API, so an app can ask for the same thing.

Components for Android · Components for iOS · Tokens · Patterns