The Three App States

Every application in UnifyApps exists in one of three states at any point in time. Understanding the distinction between them prevents accidentally exposing unfinished work to end-users or confusing a preview link with the live application URL.

Working Copy

The Working Copy is the version of the application that lives on the builder canvas. Every time you press Save in the builder's top bar, the platform captures a snapshot of the entire application — pages, data sources, navigation, theme, and all — and stores it as the new Working Copy. The Working Copy is private to the builder; it is never directly visible to end-users.

Preview

Preview is your latest saved Working Copy running as a fully functional application in a separate browser tab. It uses real data connections, real interactions, and real navigation — but it is served from a preview URL distinct from the Application URL that users visit. Preview reflects the most recent Save, not the most recent Publish. This means you can have weeks of saved-but-unpublished changes visible in Preview while users on the Application URL see an older published version.

Published Versions

Published Versions are numbered, immutable snapshots (V1, V2, V3, …) created each time you press Publish. The most recently published version is what users see at the Application URL. Older versions are preserved for auditing and rollback but are not served to users unless you explicitly restore one and publish again.

Note: Preview is ahead of what users see. Never share a Preview tab link with stakeholders as "the live app" — it reflects unpublished edits. Send them the Application URL instead, which always serves the latest published version.

Save vs. Publish

The two most important actions in the builder top bar serve fundamentally different purposes:

• Save — Updates the Working Copy and makes changes visible in Preview. It never touches what users see at the Application URL. Use Save frequently while building.

• Publish — Takes the current saved Working Copy and creates a new numbered version (V1, V2, …) that becomes the live release at the Application URL. Use Publish when you are ready for users to see the changes.

Note: Publishing with no new saves does not create a new version. You must save at least one change after the last publish before a new version number is generated. If no changes have been saved since the last publish, the publish dialog shows "Up to date with V{n} — No changes since the last published version."

App State Reference Table

The table below shows what end-users at the Application URL see after each key action:

Previewing Your Application

Use Preview to verify that your changes work end-to-end — with real data and real interactions — before publishing them to users.

Steps: Previewing a Web Application

1. Make your changes in the builder and click Save in the top bar. A "Successfully updated" toast confirms the save.

2. In the builder's top bar, click Preview Application. The application opens in a new browser tab running against real data.

3. Test your changes interactively. Because Preview reflects the latest save, you can iterate quickly: return to the builder, make a change, save, then reload the Preview tab — the new state appears immediately, even if you have never published.

4. Keep the Preview tab open between sessions. Any subsequent saves automatically update it on the next reload.

Previewing a Mobile Application

For Mobile App types, the builder displays a Live Preview QR code panel instead of opening a browser tab. Scan the QR code using the UnifyApps Preview app on your iOS or Android device to run the mobile application natively. The QR code regenerates whenever you save.

Publishing Your Application

Publishing creates a new numbered version and makes it the live release at the Application URL.

Steps: Publishing a Release

1. Ensure you have saved all changes you want to include. The builder top bar should not show unsaved indicators.

2. Click Publish in the builder top bar. A small publish panel opens.

3. The panel shows the Application URL with a copy button. You can share this link with users once published.

4. Optionally, enter a Version tag — a short identifier for this release. Tags must start with a letter, contain no spaces, and may only use - and _ as special characters (for example, v2-beta or release_june).

5. Optionally, enter Version notes — a description of what changed in this release, useful as a changelog for your team.

6. Review the Changes since last published section. Each row lists an area (Application, Pages, Modules, Walkthroughs, Icons) with addition and removal counts. Click any row to jump directly to that area. Click Review all changes to see every individual change.

7. Click Confirm Publish. The platform creates a new version number, and a "Your app has been published." confirmation appears with a Copy link button.

8. The builder top bar updates to reflect the new version status: the first publish changes "Not Published" to "V1 Published"; subsequent publishes increment the number.

Comparing Versions

The Compare Versions view lets you inspect exactly what changed between any two points in the application's history — including your current unsaved edits — before deciding whether to publish.

How to Access the Comparison

The comparison panel is accessible from the publish dialog. Look for the "Compare any two versions or your current edits with a published version" link near the top of the publish panel.

Comparison Controls

If the two selected versions are identical, the panel shows "No changes". If the comparison cannot be completed, the panel shows "Couldn't compare these versions" with a Retry button.

Restoring an Earlier Version

If a published version introduced a regression or you need to roll back to a previous state, you can restore any past published version. Restoring loads that version's configuration back into the Working Copy — your live application is unaffected until you publish again.

Note: Restore affects your working draft; the live app is unchanged until you publish. After restoring, review the Working Copy in Preview to verify the rollback looks correct before publishing it to users.

Steps: Restoring an Earlier Version

1. Navigate to the app detail page and open the Versions tab. The list shows all published versions newest first.

2. Click the version you want to restore. The version opens in a read-only view.

3. Click Restore this version. A confirmation dialog explains what will be reverted.

4. Confirm the restore. The platform shows "Application restored successfully." The Working Copy now matches the selected version.

5. Open Preview to verify the restored state. Any pages that were added after the restored version will have disappeared from the Working Copy — this is expected.

6. When you are ready to make the restored state live, click Publish. The platform creates the next sequential version number (for example, restoring V1 and publishing creates V3, not V1 again). The content of the new version matches the restored version.

What a Restore Covers

A restore from the Versions tab is thorough — it rolls back the entire application's Working Copy:

• All pages and their configurations

• Navigation menu items

• Theme and styling settings

• Data source definitions

• Application-level settings

Pages that were added after the restored version will no longer exist in the Working Copy after the restore completes. Version numbers do not rewind: restoring V1 and publishing creates the next sequential version (e.g., V3), not a new V1.

Saved Versions vs. Published Versions

UnifyApps maintains two separate version histories, each serving a different purpose:

Use Saved Versions when you need to undo a specific edit or recover a recently deleted element within a working session. Use Published Versions when you need to roll back an entire release that has already gone live.

Frequently Asked Questions

What is the difference between Preview and Publish?

Preview opens your most recently saved Working Copy in a full browser tab with live data and interactions. It is served from a separate preview URL and is only visible to people with builder access to the app. Publish creates a new numbered version (V1, V2, …) that becomes the live release at the Application URL — the address that end-users visit. Changes you save after publishing remain in Preview only until you publish again.

How do I roll back to a previous version if a publish introduces a problem?

Open the app detail page and go to the Versions tab. Click the version you want to restore, then click "Restore this version" and confirm. This loads that version's configuration back into your Working Copy without affecting the live app. Review the result in Preview, then click Publish to create the next sequential version containing the restored content. Version numbers never rewind — restoring V1 and publishing creates the next number in sequence, not a new V1.

Can I publish to a staging environment before publishing to production?

UnifyApps Applications supports environment-based publishing workflows for workspaces configured with multiple environments (for example, staging and production). The publish flow in those setups includes environment targeting controls. If your workspace only has a single environment, publishing goes directly to the production Application URL. Contact your workspace administrator to understand whether multi-environment publishing is configured for your workspace.

Can I share the Preview link with stakeholders who are not in the builder?

The Preview URL reflects unpublished edits and requires the viewer to be signed in to the workspace with at least view access to the app — it is not a publicly shareable link. For stakeholder review, the recommended approach is to publish the changes (creating a new version) and share the Application URL, or grant stakeholders explicit access to the app in its Settings tab so they can open the preview within their own session.

Does publishing require any downtime for users on the live app?

No. Publishing is non-destructive and near-instantaneous. While a publish is in progress, the previous version continues serving normally. Once the new version is live, subsequent page loads serve the new version. Users who are mid-session on the old version typically continue uninterrupted until they reload, at which point they receive the new version.