What an App contains
An App is a project that can be edited, built, and delivered independently. Daily work belongs in editor Resources, Settings, and Git. You do not need to know how Theseus organizes or compiles that content internally.
When to use this page
- Decide whether something should travel with the project to a teammate.
- Move an App to another development machine or restore it from Git.
- Investigate missing Pages, Objects, QG programs, or packages after opening an App.
- Distinguish saved work, a completed Build, a delivered version, and a running App.
Start with four boundaries
| Content | How a customer should understand it |
|---|---|
| Project content | Maintainable Pages, Components, QG programs, Objects, settings, and assets; collaborate and back them up through Git |
| Local built version | The current result produced by Build; reproducible and not a project backup |
| Version delivered to a Runtime target | The App currently received by that target; saving the project does not update it |
| Site state | Current Saved Variable values, device state, sign-in sessions, and logs; normally specific to that target |
Copying a project therefore does not copy site state. Conversely, being able to open an App on a Runtime target does not prove that the project is backed up.
Where to manage content
| Content | Recommended entry |
|---|---|
| Pages, Components, Objects, QG, Vision, Safety, and assets | Resources |
| App name, Home Page, packages, Variables, Recipes, Queries, localization, users, and roles | Settings |
| Project changes, commits, and team synchronization | Git |
| Build and runtime problems | Problems / Console |
| Delivery target and current runtime state | Runtime target and runtime controls in the editor toolbar |
Create, move, and rename resources through Resources so the editor can update reference checks and diagnostics. Manage package versions through Settings → Packages. Do not bypass the UI by editing internal project files.
What moves with a project
| Content | Travels with project / Git | What to do after migration |
|---|---|---|
| Pages, Components, QG programs, Objects, App settings, and assets | Yes | Open the App and wait for required packages to become ready |
| App users and role definitions | Yes | Recheck sign-in and role branches in the target environment |
| Current Build result and delivered version | No | Build again and deliver to the correct target |
| Current Saved Variable values and persistent equipment state | No | Follow the project's data-migration procedure |
| Runtime target accounts, License, and connection settings | No | Reconnect and configure them on the new machine |
| Editor layout and AI conversation history | Outside the App project | Preserve separately if required |
Migration or delivery workflow
- Save every intended change and inspect the scope in Git.
- Commit the required Pages, Objects, QG programs, settings, and assets. Do not commit passwords, API keys, or temporary files.
- On another development machine, open the project from App Hub or import it from Git.
- Wait for package preparation. If it fails, resolve the explicit error shown in Settings → Packages.
- In Resources and Settings, inspect the Home Page, core resources, enabled modules, users, and external connections.
- Select the intended Runtime target, run Build, then accept the result with Start or Debug.
- Migrate site data, License, target accounts, and connection information separately; they are not Git content.
Acceptance checklist
- App Hub opens the project normally.
- Every required package becomes ready without being replaced by another version.
- The Home Page and core resources are complete.
- Build succeeds with no blocking Problems.
- Start / Debug uses the version just delivered.
- App users, device connections, Saved Variables, and external systems pass environment-specific acceptance.
- A clean environment can restore editing and Build from the team project.
Common issues
Files are visible after Git import, but Design, Preview, or QG Flow keeps waiting
Required packages are usually not ready yet. Keep the original error, inspect the missing version or source issue in Settings → Packages, then retry. Do not install extra dependencies or edit internal project files to bypass the problem.
Work is saved, but the runtime Page still shows the previous version
Save changes first, then run Build. After Build completes, use Start or Debug. Preview, Start, and Debug do not automatically include unsaved drafts.
Site data or target accounts are missing on a new machine
This is the expected boundary. Site state, License, target accounts, and connection settings are not part of the project. Migrate or recreate them through the delivery checklist.
Git contains generated content that should not be committed
These items are not maintainable project content. Confirm their origin, remove them from the commit, and verify that the normal Build can regenerate the runtime version.