The App Store
How third-party phone apps are registered, installed, and managed — the manifest, install lifecycle, and where the publishing flow is today versus where it's going.
The App Store app is how players discover and install third-party phone apps. This page is the developer's side: how an app gets into the store, how installs work, and what the platform guarantees.
What an entry is
A store entry is a manifest plus a hosted bundle. The manifest provides the store card (name, subtitle, icon, accent, content rating), the permission list the player will see, and any in-app purchases.
Install lifecycle
Discover. The store lists every catalog app from GET /api/v1/phone/apps. Each card shows the
declared permissions and content rating up front.
Install. POST /api/v1/phone/apps/:appId/install creates an install record (status: "installed")
and grants only account.basic. The app now appears on the home screen.
Grant as needed. The player grants additional scopes on first use or in Settings.
Uninstall. DELETE /api/v1/phone/apps/:appId/install removes the app, revokes its permissions,
and clears its notifications. Built-in apps can't be uninstalled.
REST surface (first-party / server)
Apps themselves use the SDK; these endpoints back the store and tooling:
| Method | Path | Purpose |
|---|---|---|
GET | /api/v1/phone/apps | List the catalog (built-in + third-party). |
GET | /api/v1/phone/apps/:appId | A single manifest. |
GET | /api/v1/phone/installs | The player's installed apps. |
POST | /api/v1/phone/apps/:appId/install | Install. |
DELETE | /api/v1/phone/apps/:appId/install | Uninstall. |
GET | /api/v1/phone/permissions | Effective grants per app. |
PUT | /api/v1/phone/apps/:appId/permissions | Replace an app's grants. |
GET | /api/v1/phone/permissions/audit | Recent permission events. |
Publishing today
Current state: curated catalog
Today the catalog is first-party curated — an app's manifest is registered in the backend app
registry (phone-app-registry.ts), and bundles are served from Helix. There is no self-serve upload
or automated review queue yet. To ship a third-party app now, you work with the Helix team to register
the manifest and host the bundle.
Publishing, proposed
The self-serve developer flow is designed and tracked on the Proposed & in-progress page:
- A developer portal +
helix phone publishCLI to submit a manifest and bundle. - A review queue with states (
draft → in_review → approved → published), content-rating checks, and permission justification. - Versioned releases and staged rollout.
- Revenue share on IAP, mirroring the platform's creator economy.
Until that lands, build and test against the local sandbox (the bundled studio.example app and your
own bundle under public/phone-apps/), and use the manifest format above — it won't change when
self-serve publishing ships.
Distribution guarantees
Regardless of how an app is published, the platform guarantees:
- Sandboxing. Third-party bundles run in an isolated iframe and reach the platform only through the permission-checked bridge.
- Consent. No scope beyond
account.basicis active without the player granting it, and any scope is revocable. - Auditability. Every permission use is recorded; abusive apps can be cut off per-scope.
Phone SDK reference
Every Helix Phone SDK namespace and method — runtime, account, permissions, storage, notifications, media, camera, wallet, payments, contacts, messages, calls, presence, social, feeds, ui, and lifecycle.
In-app purchases
Sell consumables, unlocks, and subscriptions inside a phone app — priced in LIX, idempotent, and declared in your manifest.