Pocket System for desktop

One process.
A whole desktop.

Pocket Desktop runs a complete System UI and isolated Pocket apps through one generic native host. Every app gets its own JavaScript Realm. The native compositor keeps the pixels, clipping, focus and scheduling coherent.

Run it in your browser ↗ Read the architecture

1native process

12isolated AppInstances

3host targets

pocket-desktop

Realm 07Hero · running

Compositorsurface · focus · clip

Native on macOSPackaged for LinuxPreviewed through WebAssembly

System architecture

Isolation without an operating-system process per app.

The resolved System plan gives the host one System UI and an installed app catalog. AppSupervisor creates independent AppInstances; the compositor owns their visible surfaces and input focus.

ResolvedSystemPlanProduct intentroles · packages · policy

↓

generic native hostOne process

AppSupervisorSystem UI RealmHero RealmSettings RealmMusic Realm

Compositorsurfaceclippingpainter orderinput focus

From component to pixel

One scheduling lane, not four disconnected pipelines.

The comparison shows Pocket app JavaScript scheduling. The host may use platform service threads, but app Realms advance through one supervised lane inside one native process.

Pocket Desktop1 process / 1 app scheduling thread

P1 · T1Component

→

P1 · T1Realm

→

P1 · T1DrawList

→

P1 · T1Pixel

Process-per-app4 processes / 4 scheduling threads

P1 · T1Component

↗

P2 · T2IPC

↘

P3 · T3Compose

↗

P4 · T4Pixel

Themeable System UI

Change the chrome.
Keep the system.

Theme selection changes geometry, colors, controls and surfaces inside the System UI boundary. It does not change the System manifest, app packages or native host.

XP theme · Luna gradients · 30px taskbar

Complete WebAssembly preview

This is the actual System.

The browser host resolves the same catalog, starts one iframe Realm per AppInstance and composites child rasters under the System UI. Double-click an app after launch.