Skip to main content
Client App BuilderVersion: v3

Client App Builder

Apps built with Client App Builder: projects, builds, changes and code

📄️Write, patch or delete one file in the app's sandbox.

Writes, patches or deletes one file in the app's sandbox. A small change to a text file is a `patch`: exact replacements, without resending the file. After a set of edits, save them with `POST .../sandbox/checkpoint`, then start a run with `externalAgent: true` to check, build and deploy them. A React Native app (`react_native_app_kernel_v1`) writes only under `apps/mobile/app-extensions/` and `apps/mobile/application-assets/`; its `routes.ts` is generated, so register its screens with `POST .../sandbox/extension-routes` instead of writing that file.

📄️Register, rename or remove a React Native app's screens.

Changes the screen list of a React Native app (`react_native_app_kernel_v1`) once its screen files are written with `POST .../sandbox/edit`: `app-extensions/routes.ts` is generated from these changes, never written as text. Send several changes as one `batch`: all of them apply or none does, and a resent batch that is already in effect changes nothing (a repeated single `add` is refused as `duplicate_id`). The run started next with `externalAgent: true` checks the screens, saves them as a mobile revision and deploys the preview.

📄️Publish an app to its live site.

Publishes the app to its live site: its managed address, and every custom domain attached to it (`changes` kind `domain`) once that domain is `active`. A domain that becomes active later joins the live site without another publish. Check `GET .../publishability` first and send the `sourceRunId` it returns, so the build the creator approved is the one that goes live. Returns a publish job: poll `GET .../infra/publish-jobs/{publishJobId}` until `status` is `succeeded` (`publishedUrl` is the live site) or `failed` (`error` says why). Send the same `idempotencyKey` to retry safely.

📄️Build a signed Android APK of a published phone app revision.

Idempotent per Idempotency-Key. For a project whose current revision carries generated screens, the build is instead identified by the revision and the generated sources it carries (sha256(locationId:projectId:revision:sourcesSha)): repeating the request for the same revision and sources returns the same build whatever the key, and a failed one is queued again. Such a build is made from the React Native kernel commit the screens were generated against, and must be requested for the current revision. Generated screens reach members only through a new APK; they are never delivered over the air. At most one build may be active per project; sibling projects in the same location may build in parallel. Deleting a project while its build is still queued or building fails that build. A project compiles one signed APK for now: after a successful build the binary is final. A project without generated screens keeps reaching installed apps by publishing a revision; a project with generated screens cannot build another APK yet. Failed builds do not consume the allowance.