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.
phone.intents — app-to-app deep links Proposed
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 AlbumAssetphone.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-gatedBlob 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 publishCLI 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.
Example app: World Postcard
A complete, real phone app built on the Helix Phone SDK — pick or capture a photo, tag it with your current world, save a draft, unlock a premium frame via IAP, then post to Helixgram, notify, and share.
Keeping these docs in sync
How the Phone SDK docs stay current with the code — an automated drift detector that compares the live SDK surface on the helix3 branch against the documented snapshot and flags anything new, changed, or removed.