HELIX 3 Docs
Helix Phone

Proposed & in-progress

Capabilities that are mocked, partial, or not yet built — plus proposed new SDK surfaces to round out the Helix Phone. Everything here is clearly labeled and not yet guaranteed.

Read this as a roadmap, not a contract

Everything on this page is Proposed or In-progress. APIs here may change name, shape, or be cut. The shipping surface is the SDK reference; build production apps against that. This page exists so the picture is complete and so feedback lands before the API freezes.

We split this into two buckets:

  • In-progress — the method exists in the SDK today but runs against a mock backend.
  • Proposed — a gap we found while documenting; a new surface we think the Phone should expose.

In-progress (mocked today)

These ship in the SDK now and are marked mock in the reference. The method signatures are expected to stay; only the backend becomes real.

Real camera capture

camera.mockCapture produces a placeholder asset. Proposed: a real camera.capture() that grabs the actual framebuffer of the world the player is in (and, where available, device camera), writing a true photo/video into the album.

Real voice calls

calls.* simulate call state (provider: "mock", status: "pending_voice_api"). In-progress: a real voice stack so calls.start(contactId) opens a live call, with ringing/connected/ended driven by the platform rather than updateStatus.

Real IAP settlement

payments.purchase grants entitlements with mock: true and does not debit LIX yet. In-progress: the platform purchase sheet + server-side LIX settlement. The call signature is final — only the money movement is being added.

Live world presence

presence.getCurrentWorld returns a fixed world. In-progress: real presence wired to the player's actual world/instance, plus a proposed presence.subscribe(cb) for live updates as they travel.

Real social-discovery matching

social.recordSwipe always returns matched: false. In-progress: real mutual-match detection and a social.getMatches() surface.

Placeholder wallet history

The Wallet app's transaction list is deterministic synthetic data until the economy ledger is wired in; shape is final.


Proposed new surfaces

Gaps we found while documenting the SDK. Each would be additive.

Today apps deep-link into themselves via notifications. Proposed: a way to hand off to another app with the player's consent — e.g. a game opening the Camera, or any app opening a Helixgram composer.

// Proposed
await phone.intents.open("camera", { action: "capture", returnTo: "acme.postcard" });
const result = await phone.intents.request("media.pick"); // system picker, returns an AlbumAsset

phone.location — in-world position Proposed

Presence gives the world; some apps want coordinates (a map, a geocache, a "near me"). Proposed: a coarse, permissioned location.getPosition() scoped to the current instance, behind a new location.read scope.

phone.ui.haptic & phone.ui.clipboard Proposed

Small but expected affordances:

// Proposed
phone.ui.haptic("success");                 // light | success | warning | error
await phone.ui.clipboard.write("gg");
const text = await phone.ui.clipboard.read(); // consent-gated

Blob storage beyond 32 KB Proposed

storage is a 32 KB KV store. Proposed: phone.files for larger per-app blobs (saved games, exports) with signed URLs, distinct from the album.

Server-initiated & scheduled push Proposed

notifications.push is client-initiated while the app runs. Proposed: a server endpoint so an app's backend can notify a player who isn't currently in the app, plus notifications.schedule(at, …) for reminders.

Sensors & audio Proposed

Proposed read-only phone.sensors (accelerometer/orientation for motion-controlled apps) and a small phone.audio for SFX/looping clips, each behind its own scope.

Contacts write Proposed

contacts.list() is read-only. Proposed: app-created, app-scoped contacts (e.g. a guild app adding guildmates) — never touching the player's real social graph without consent.

App Store self-serve publishing [#app-store-self-serve-publishing] Proposed

The catalog is first-party curated today. Proposed developer flow:

  • A developer portal + helix phone publish CLI to submit a manifest + bundle.
  • A review queue: draft → in_review → approved → published, with content-rating and permission-justification checks.
  • Versioned releases, staged rollout, and IAP revenue share mirroring the creator economy.
  • Widgets / live activities on the home and lock screen as a later phase.

Have an opinion?

This list is where the Phone SDK is going — if something you need is missing or mis-shaped, that's the most useful feedback you can give before these freeze. The sync pipeline will automatically move items off this page and into the reference as they ship.

On this page