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. When real-time collaboration is on, the builder saves your edits automatically as you work, so there is no Save button to press. Each auto-save 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.
If real-time collaboration is off, the builder shows a Save button instead. Save your changes before you publish. Until you do, Publish is disabled.
Preview
Preview is your latest 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 your latest auto-saved edits, not the most recent Publish. This means you can have weeks of 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.
Auto-Save vs. Publish
Saving and publishing serve fundamentally different purposes:
Auto-save — The builder saves every edit automatically and updates the Working Copy, so your changes show in Preview. It never touches what users see at the Application URL. With real-time collaboration on, there is no Save button.
Publish — Takes the current 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 changes does not create a new version. You must make at least one change after the last publish before a new version number is generated. If nothing has changed 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:
| You did | What users at the Application URL see |
| Edited, never published | Nothing — the app is not yet live |
| Published V1 | V1 |
| Made more edits after publishing V1 | Still V1 |
| Published again (with new changes) | V2 |
| Restored V1, then published | V3 with V1's content |
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
Make your changes in the builder. With real-time collaboration on, they save automatically and there is no Save button to press.
In the builder's top bar, click the Preview icon (a play button, labelled Preview Application). The application opens in a new browser tab running against real data.
Test your changes interactively. Because Preview reflects your latest edits, you can iterate quickly: return to the builder, make a change, then reload the Preview tab — the new state appears immediately, even if you have never published.
Keep the Preview tab open between sessions. Later edits appear in 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 with the UnifyApps Preview app on your iOS or Android device to run the mobile application natively. Don't have the app yet? Use the Android or iOS download link at the bottom of the Live Preview panel. The QR code updates as your changes are saved automatically.
Publishing Your Application
Publishing creates a new numbered version and makes it the live release at the Application URL. The Publish button appears only if your role has Deploy permission on the app.
Steps: Publishing a Release
Make sure the changes you want to include are in the builder. Make sure your changes are saved: edits save automatically when real-time collaboration is on, otherwise click Save. Then everything in the Working Copy is included.
Click Publish in the builder top bar. A small publish panel opens.
The panel shows the Application URL with a copy button. You can share this link with users once published.
Optionally, enter a Tag this version — 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-betaorrelease_june).Optionally, enter Version notes — a description of what changed in this release, useful as a changelog for your team.
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.
Click Publish. The platform creates a new version number, and a "Your Application has been published." confirmation appears with a Copy link button.
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 edits — before deciding whether to publish.
How to Access the Comparison
Open the comparison from the publish panel: click Review all changes, or click a row under Changes since last published, to open Compare versions.
Comparison Controls
| Control | Description |
| Base version picker | The version you are comparing from. Options include all published versions, "Last published", and "Current edits". |
| Compare version picker | The version you are comparing to. Same options as Base. |
| Change groups | Changes are grouped by area: Application, Pages, Modules, Walkthroughs, Icons. |
| Split / Unified | Toggle between a side-by-side split view and a unified diff view. |
| Show context only / Show all lines | Limit the diff to changed lines with context, or show every line. |
| Page view: Extracted / Raw | Extracted shows a structured, human-readable representation; Raw shows the underlying serialised config. |
| Breakpoint filter | Filter page differences by breakpoint: Desktop, Tablet, or Mobile. |
| Open in Builder | Navigate directly from the comparison view to the relevant area in the builder. |
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 comparison 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
Navigate to the app detail page and open the Versions tab. The list shows all published versions newest first.
Click the version you want to restore. The version opens in a read-only view.
Click Restore this version. A confirmation dialog explains what will be reverted.
Confirm the restore. The platform shows "Application restored successfully" and opens the builder with the restored Working Copy.
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.
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:
| History type | Location | Granularity | Restorable? | Visible to end-users? |
| Saved Versions | Builder left rail (in-builder panel) | One entry per auto-save — fine-grained edit history | Yes (app-scoped or page-scoped) | No |
| Published Versions | App detail page → Versions tab | One numbered entry per Publish action — coarse release snapshots | Yes (entire app) | Latest version only |
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. For the Saved Versions panel, its filters and comparing saves, see App Versions.