The four presentations

One installed app, four user-facing presentations. Same identity, grants, bindings and data in all of them.

  1. In-app (embedded) — the default full view inside Iro’s window.
  2. Separate window — an Iro-owned window. One full document moves embedded ↔ window without reload.
  3. Compact — Home widgets and quick-access panels, plus optional menu-bar/tray pins. A widget and panel can coexist with the full view; each has its own renderer but the app’s single session, proxy, identity and limits.
  4. Desktop app — its own macOS bundle with Dock/app-switcher identity (clone of the Electron runtime, ~1 MB per app). A UI host, never a kernel: it connects to the one shared kernel over a private socket with a per-app token. Quitting a host leaves Iro running.

Developers declare ui.layouts (full/compact) and ui.launchTargets (embedded/window/desktop). Users choose presentation and pins; preferences persist across restarts. Closing one document leaves siblings and the kernel alive.

Trust holds in every host: per-app session, iro-app:// handler, per-app egress proxy + WebRTC policy, CSP without unsafe-eval, bounded calls, hang watchdog. Revoking a permission breaks exactly that feature in every presentation.