App Lifecycle
Every VibeDepot app goes through a defined lifecycle managed by the shell’s main process.
Installation
Section titled “Installation”When a user installs an app from the store:
Registry Main Process Disk │ │ │ │ 1. Fetch registry.json │ │ │ <──────────────────────────│ │ │ │ │ │ 2. Download ZIP bundle │ │ │ <──────────────────────────│ │ │ │ │ │ │ 3. Verify SHA256 │ │ │ checksum │ │ │ │ │ │ 4. Extract ZIP │ │ │ ──────────────────────>│ │ │ ~/.vibedepot/ │ │ │ apps/{appId}/ │ │ │ │ │ │ 5. Read manifest.json │ │ │ <──────────────────────│ │ │ │ │ │ 6. Update │ │ │ installed-apps.json│ │ │ ──────────────────────>│- The registry client fetches
registry.json(from cache or network). - The app manager downloads the ZIP bundle from the registry’s GitHub raw URL.
- A SHA256 checksum is computed and compared against
registry.json. - If the checksum matches, the ZIP is extracted to
~/.vibedepot/apps/{appId}/. - The
manifest.jsonis read and validated. - The app’s metadata is saved to
installed-apps.json.
If the checksum doesn’t match, installation is rejected.
Launching
Section titled “Launching”When a user launches an installed app:
- Create BrowserWindow — The window manager creates a new Electron BrowserWindow with context isolation enabled and Node integration disabled.
- Load preload — The app-preload script (
@vibedepot/app-preload) runs in the window, exposingwindow.vibeDepot. - Load entry — The app’s HTML entry file (from
manifest.entry) is loaded into the window. - Register mapping — The WebContents ID is mapped to the app ID for permission enforcement.
The app is now running and can interact with the Bridge API.
Running
Section titled “Running”While an app is running:
- IPC calls are routed through the preload → main process → handler chain.
- Permissions are checked on every IPC call.
- Storage operations target the app’s isolated data directory.
- AI calls use the user’s API keys from the OS keychain.
The shell renderer tracks running apps via the runningAppIds set in the app store.
Closing
Section titled “Closing”When an app window is closed (by the user or programmatically):
- The window’s
closedevent fires. - The window manager removes the WebContents → app ID mapping.
- Any open SQLite database connections for the app are closed.
- The shell renderer is notified to update the UI.
App data (KV storage, SQLite databases) persists after closing.
Sideloading
Section titled “Sideloading”Sideloaded apps follow a different installation path:
- The user selects a local folder containing a
manifest.json. - The shell validates the entry file exists.
- The app is registered as sideloaded (not extracted from a ZIP).
- A file watcher monitors the folder for changes.
- On file changes (300ms debounce), the manifest is re-read and the window reloads.
Sideloaded apps are marked with a flag (--sideloaded passed via additionalArguments) so the preload can enable dev warnings.
Uninstalling
Section titled “Uninstalling”When a user uninstalls an app:
- If the app is running, its window is closed first.
- The app bundle directory (
~/.vibedepot/apps/{appId}/) is deleted. - The app’s entry is removed from
installed-apps.json. - Optionally, the app’s data directory (
~/.vibedepot/app-data/{appId}/) is removed.
Updating
Section titled “Updating”The shell detects available updates by comparing the installed version against the registry:
- The Library page compares
installedApp.versionwithregistryEntry.version. - If the registry has a newer version, an update indicator appears.
- Updating follows the same flow as installation — download, verify, extract — replacing the old bundle.
Next Steps
Section titled “Next Steps”- Architecture Overview — How the components fit together
- Security Model — Sandboxing and isolation details
- Bridge API Design — How apps communicate with the shell