Publishing

Publish screens from the Studio to a live campaign

Publishing

When your screens are ready, publish your project to create a campaign that delivers a new version to your app's users. Publishing compiles your project into an optimized bundle served from the edge.

The publish workflow

Publishing is a three-step process you trigger from the Publish button in the project header.

1. Select a target app -- Choose which app receives the published version. If your organization has only one app, it is selected automatically. If the project was previously published, the same app is pre-selected.
2. Review pre-flight checks -- The editor validates your project before allowing you to publish. Fix any issues first.
3. Publish -- Click Launch Campaign (for a new publish) or Update (for re-publishing). The editor queues the build and shows a progress indicator.

Pre-flight checks

The editor blocks publishing until three conditions are met:

Starting screen is set

Every project needs a starting screen -- the first screen users see. If you have not set one, the publish panel shows a warning and the publish button is disabled.

Set a starting screen by right-clicking any screen and choosing Set as starting point, or by dragging the entry marker in Interactions mode.

No binding errors

The editor scans all screens for broken input bindings -- for example, a TextInput bound to a view model property that does not exist. Any blocking binding issue is listed in the publish panel.

Fix binding errors by opening the affected screen's data defaults or correcting the view model property references.

No component parse errors

If a screen has a component tree that failed to parse (due to invalid JSX or a generation error), it blocks publishing. Regenerate the screen from chat or fix the component tree manually.

Tip: Binding errors that affect only display (read bindings) are treated as warnings and do not block publishing. Only input binding issues and hard parse errors are blocking.

Build process

After you click publish, the version build goes through several stages:

Build status updates arrive in real time. You do not need to refresh the page to see progress.

What happens after publishing

When a publish succeeds:

• A campaign is created (or updated) for the target app.
• The compiled version bundle is deployed to the edge for fast delivery.
• The publish panel shows a link to the campaign in the dashboard, where you can configure targeting, segments, and delivery rules.

Your app's Nuxie SDK begins serving the new version to eligible users based on the campaign's trigger rules and targeting configuration.

Re-publishing

Re-publishing creates a new version. The previous version remains active until the new build completes successfully.

Click the Update button in the publish panel to re-publish. The same pre-flight checks run again. If your project passes validation, a new build is queued.

Experiment guardrails

If your project contains experiment actions (A/B tests), re-publishing may affect running experiments. The editor detects this and shows a confirmation dialog listing:

• Modified experiments -- Experiments whose variants changed.
• Removed experiments -- Experiments that no longer exist in the project.

You have two options:

• Continue -- Publish with the existing experiment IDs. Running experiments continue with their current assignment.
• Replace experiments and publish -- Generate new experiment IDs. This resets experiment assignments, effectively starting fresh experiments.

Choose "Replace" when you have made significant changes to your variants and want clean experiment data.

Target app selection

The publish panel needs to know which app will receive the version. It determines the target app in this order:

1. The app from a previous publish of this project.
2. The app associated with the project.
3. The currently selected app in your dashboard context.
4. Your only app, if you have exactly one.

You can override the selection by clicking the app name and choosing a different app.

Tracking build status

After publishing, the publish panel updates in real time as the build progresses. Status transitions flow from Queued to Building to Published (or Error). If you close the publish panel and reopen it, the editor fetches the current campaign status so you always see the latest state.

Next steps

• Campaigns -- Configure targeting, triggers, and delivery rules for your published version.
• Interactions -- Set a starting screen and wire up navigation before publishing.
• Data & Bindings -- Fix binding errors that block publishing.