Apps

Apps are web applications that run inside General Text, embedded in your workspace alongside your files. They give you a tailored way to work with your data: a spreadsheet over a CSV, a diagram editor, a kanban board, a tracker for something only you care about.

Every app in a workspace is a copy that workspace owns, running from its own files. Nothing is installed from a server that could change under you, and nothing phones home.

The Apps page

Apps in the sidebar is the whole surface. It is a set of pages, each with its own address:

Apps (…/apps) lists this workspace's apps. One row per app: what it is, what version it runs, who can see it, and whether the app you forked has moved on. Searching here reaches into the gallery too.
One app (…/apps/{name}) is where that app is managed: its versions and rolling back, its files, who can see it, its data, and the two one-way actions. Versions leads, because the version stack is what an app is.
Gallery (…/apps/browse) browses what other people made public, and forks one into this workspace.
Build (…/apps/{name}/build) is where you work on one app: its files, an editor, and the app's draft running beside them.

+ New app opens one sheet with every way to start: ask an agent, start it yourself from a runnable starter file, paste a single self-contained index.html, fork from a URL, or copy an app you already have. Whichever you pick, you end with an app in this workspace's sidebar.

The sidebar lists the apps themselves under a divider. Two things arrange them, both per person and neither visible to anyone else:

Order. Drag a row on the Apps page by its grip; the sidebar follows.
Groups. + New group makes a named section; drag an app onto a group to put it there, and onto Ungrouped to take it out. A group's heading folds shut in the sidebar, a group owns the order of the apps inside it, and the groups themselves drag by the grip on their heading. Deleting a group leaves its apps in the workspace, just ungrouped.

Hide from my sidebar, on an app's Access tab, takes it out of your own sidebar without touching anyone else's.

Where apps come from

Fork it from the gallery. Forking copies the app's files into your workspace at the version you pick, the way a fork works on GitHub: yours to run, read and change. Before anything lands, the dialog shows which network hosts the app talks to (or that it talks to nothing), the version, and the folder it will land in.
An agent builds it. Give an agent a seat in the workspace (People → Agent seats) and it writes into the app's draft with gt app draft push. You look at the draft, and it becomes a version when it is saved; there is no publish step in between, and every device gets each push as it syncs. See Agent Access.
New app. Three doors: ask an agent (it hands you the prompt), paste a self-contained index.html, or fork from a URL. A fork from a URL copies a built app once; nothing re-fetches it later, so a newer build there is a new fork, not an update.

A free workspace holds three apps. Past that, forking or pushing a fourth is refused with a line pointing at Billing.

The app's folder

An app in a workspace is a folder under _gtApps/:

installed.json, the record: every version's files by content hash, and what each version declared it talks to.
code/{version}/, each version's files, immutable once written.
code/draft/, the working version: the one you and your agent write. One per app.
data/, the app's own files: the only part it can write.
draft-data/, a copy of data/ that an open draft plays with instead, so a half-written version cannot wreck real files. It goes when the draft is saved or thrown away.

The workspace serves the version's files itself, so an app keeps working even if the original source changes or disappears. The folder syncs to every member and every device like any other file, so a fork or a push shows up everywhere, and there is no trickle of updates from anyone else's server.

Versions, and the draft

An app is a stack of versions, and the draft is the working one. It is not a separate kind of thing: it sits in the same code/ folder, in the same list, and runs by the same rules, which is why previewing a draft is simply opening it.

Newest opens. Clicking an app gets its newest saved version. There is nothing to activate and no setting to change: opening an older one is something you ask for, not something you switch the app to. On the app's Versions tab, and under the version number on its sidebar row, every version is a link. Open this version runs it without changing anything for anyone else.

Save freezes the draft under a version number, and that becomes the newest. The sheet shows what differs from the version below it, calls out any network host the new version asks for, and says what else happens: the draft is spent, and its copy of the data is discarded.

Every version is kept, and nothing is pruned for you. Each one shows its size on the Versions tab, and an admin can delete one; deleting the newest falls back to the one under it, which is how a bad save is undone. The last remaining version cannot be deleted, because that is deleting the app.

When the original moves

If you forked from the gallery and its author publishes a newer version, the row grows an Upstream v1.3.0 button. It shows what changed: which files were added, removed or edited, any network hosts the new version gained, and a line diff of the text files. If your copy is untouched since you took it, Take v1.3.0 lands the new version on the same folder (your data stays, and the old version stays in the history). If you have changed your copy, you get the diff and decide for yourself. General Text never merges for you.

Who can see an app

By default an app is shared with everyone in the workspace, and its row says so. The Access tab locks it to a list instead: uncheck "Everyone in {workspace}" and pick the people (and agent seats) who should have it.

A locked app disappears from the sidebar of everyone outside the list, and the server stops delivering its files to them. Three honest edges: a lock is a delivery filter, not a second key (everyone in the workspace holds the one workspace key); it works forwards only, so it cannot recall what already synced to someone's device; and the file names of a locked app stay visible to every member, because the workspace's file list is one document every member holds.

What an app can reach

Its own data/ folder, read and write. This is where its records live.
Shared Files, read-only. Every app in the workspace can read the workspace's own files; only people write them.
Nothing else. Not another app's folder, not its own code or record, not your other workspaces.
Only the network hosts its manifest declares. Most apps declare none and run with no network at all. The list is on the gallery page, in the fork dialog, and on the app's row. Code and styles always come from the app's own folder, whatever it declares, and embedded frames and WebRTC are always off.

There is no per-app permission to grant or revoke: what an app reaches is the same for every app, and the only setting is who can see it. Details on how that is enforced are on Security & the App Sandbox.

Reading an app's files

The chevron on an app's sidebar row expands it to its whole folder (the record, every version's code, and data/), and any of those opens in the editor like any other file. The version number beside the chevron expands the same row to the app's versions instead. It is there so "inspectable" is true in the product and not only on disk.

Publishing

Publishing is per version, and it is a different act from saving one. Each saved version on the Versions tab carries its own gallery state and its own control: Publish… puts that version in the gallery under the workspace's @handle, for others to fork; Unlist takes one back out. An app can therefore open v0.4.2 while the world still forks v0.4.0: what you run and what you offer are separate.

A draft cannot be published: the gallery hands out bytes people pin to, and a draft's bytes change under it. Save it first. Unlisting the only published version is refused for the same reason, since a listing with nothing to fork is no listing. Everyone who already forked a version keeps their copy either way. A fork can be published as your own app, exactly as on GitHub. See Publishing to the Gallery.

App data, reset, and deleting

Each app's data lives at _gtApps/{app}/data/ and persists across versions: opening or taking a different version changes only the code. The Data tab lists those files and opens any of them. Both of the one-way actions live there too, in their own box, and both are for admins.

Reset data clears it. Delete takes the app and its version history out of the workspace; by default its data files stay, so forking it again picks them back up, and a checkbox deletes them too.