ZeroTrace Desktop
Publishing
Saving versions, restoring, exporting a .ztapp.json backup, and publishing to the Store & Hub
Saving versions and reverting
Every app carries its own version history, like a built-in undo that never forgets.
- Commit — save a named point with a short message. The first commit of a new app also names and creates it.
- Automatic snapshots — every time you Run, Desktop quietly snapshots the current code, so even if you never commit, you can step back to a recent state. Snapshots are kept to a rolling recent set; your named commits are kept forever.
- Restore — go back to any earlier version. Restoring brings that version's code back as your current code and records that you did so, so your history stays intact — restoring isn't destructive, it just adds another entry.
- History timeline — review the full list of versions for an app, preview any of them, see what changed from one to the next, and restore the one you want.
Each version is tagged with how it came to exist:
| Kind | How it's created |
|---|---|
commit | You pressed Commit with a message. |
auto | Desktop snapshotted your code automatically when you pressed Run. |
restore | You restored an earlier version, recorded as its own entry. |
import | The version arrived via an imported backup file. |
You can export an app together with its whole history as a single .ztapp.json backup file, and import it again later, or on another machine, to restore the app and all its versions. This is also how you hand an in-progress app to someone else without publishing it to the Hub.
A version is your app's code plus its commit metadata. The per-app store data (see Writing apps: remembering data between runs) lives separately on your machine and is not part of a version, a backup export, or a Hub publish — installing your app elsewhere starts with an empty store.
Publishing to the Hub
When an app is ready to share, you can publish it to the Store & Hub, where other people can install it. Published apps are signed so anyone installing yours can trust where it came from, and so an app cannot pretend to be someone else's. See Store & Hub for how installing and trust work on the receiving end.
Publishing takes the code from your current version — commit it first so what you publish matches a named point in your history, rather than an uncommitted in-progress edit.