Publishing

Review, build, deliver, and verify a versioned Journey release

Publishing is the boundary between an editable Project and a versioned Journey release. Editing never changes the live app by itself.

Before you publish

The Editor performs fast readiness checks and the server runs the canonical preflight. Publish blocks when the Project has any of these problems:

No starting point.
No named Goal action.
Input bindings that reference missing converters.
Screen parse errors.
A failed generated screen that remains blank.
A platform-specific action that the selected app cannot support.

The server may return additional diagnostics after you submit. Resolve the stated problem and publish again; do not work around a preflight by removing evidence from the review.

Review the exact change

Choose Publish to open the review. Check:

Target app and environment.
Experience name.
Trigger and audience.
Delivery changes since the last successful Version.
Modified or removed Experiments.
Publish targets, when the Project offers Preview and Production separately.

The publish review is the approval boundary. If the subject changes materially, Nuxie requires a new review.

What Publish creates

Every publish creates an immutable Version and queues a build. The build produces the signed release descriptor and assets consumed by the native SDK.

The status moves through Queued, Publishing, and Published, or ends with a failure. You may close the dialog while the build continues.

For a new Experience, the first successful production publish makes a deliverable Version available. For an update, the current live Version stays live until the new Version builds successfully. A failed Version is never activated.

Preview and Production

When target selection is available:

Preview is for validation with Nuxie-owned preview tooling.
Production is the release your integrated app can receive.

Publishing only to Preview does not make the Version live for production users. Choose Go live after the Preview result is approved.

Connect and verify the app

After the first publish, open Connect your app. Choose one path:

Agent install copies an app-specific integration task for a coding agent.
Manual install shows the Swift package, debug and release keys, purchase requirement, exact trigger, and full guide.

Verification has two separate states:

Connected — the app reached Nuxie using one of its publishable keys.
Shown — the integrated app actually presented one of the Versions produced by this publish.

Do not consider first publish complete until both states are observed for the intended environment.

Publish an update

Edit the source Project and choose Publish again. The review summarizes changes since the prior publish. The new Version gets its own build and history entry.

Running Experiments receive additional guardrails because changing or removing an Experiment can invalidate accumulated evidence. Review those changes carefully before approval.

Recovery

If a build fails:

Read the cleaned error in the publish surface.
Fix the Project or target configuration.
Retry Publish.
Confirm that the prior live Version remains active.

Use the Experience Versions tab to inspect history and select another ready Version when an operational rollback is needed.