The project workspace: editor, inspector & per-file publishing
Open a project into its own window: the pinned inspector, a real code editor with syntax highlighting and live-vs-deployed gutter markers, and Pending Upload — publish just the files you changed instead of mirroring the whole tree. A Studio feature, the same on macOS and Windows.
Last updated 2026-07-26
Opening a project brings it into its own workspace — one window that holds the project inspector you already know, a real code editor, and, for anything that publishes to a host, a way to send just the files you changed. It's for the edit you make because you're already here: a version constant, a copy fix, a CSS tweak — without a round trip through a separate editor and a full redeploy.
Opening a project
Double-click a card in the Projects grid (or use its Open action) to enter the workspace; ‹ Projects in the header takes you back to the grid. The project name in the header is a search-first switcher, so you can hop to another repo without losing your place. The header keeps the project's identity, its branch, the lane actions, and Build / Release in one fixed spot, with four tabs beneath it:
- Overview
- The project at a glance — identity, what it ships to, and the state of things — the home tab for a project you've just opened.
- Code
- The built-in editor and the file tree (see below).
- Pending Upload
- The files you've changed since the last publish, staged and ready to send. This tab only appears for projects that publish to a host — see When Pending Upload appears.
- Activity
- What's happened in this project — recent runs and events.
The sidebar sections don't go away — Source Control, Test Console, Deployments, Triggers and Logs are still the right home for cross-project work. The workspace is the single-project view that a route-per-task layout can't give you.
The inspector, on every tab
The right rail is the same project inspector you see on a project card — pinned in place on every tab, so a question you have while reading code (is production healthy? what shipped last?) never costs a navigation. It shows the project's identity, the one blocking problem (if any) with its one-click fix, the lanes with their IDE / Debug / Release actions, status rows (working tree, live server, last run, version), quick actions, tags, and Project Settings…. It reads state and takes action; it never configures. For a project that publishes to a host it adds one row the rail couldn't show before — N files ready to publish. Press ⌥⌘I to collapse it when the editor wants the room.
The Code editor
The Code tab is a genuine editor, not a viewer. It gives you syntax highlighting for the languages AppRelay projects are built from — PHP (with markup-aware <?php … ?> islands), Swift, Kotlin, C#, JavaScript, JSON, CSS, HTML/XAML, YAML, shell and markdown — plus multi-file tabs (with an unsaved dot), breadcrumbs, a minimap, find with match counts (⌘F), autocomplete, a comment toggle, and a status bar showing line and column, indentation, and encoding.
The editor themes on its own — Relay Light or Relay Dark, toggled from the status bar — while the rest of the app stays light, the way Xcode does it. It is deliberately not an IDE: no build integration, no debugger, no refactoring. The lane's IDE button (Xcode, Android Studio, VS Code, …) is one click away in the inspector and still owns that work.
Pending Upload — publish only what changed
This is the heart of the workspace. A host deploy normally mirrors the entire folder every time; Pending Upload instead stages the files that differ from the deployed copy and sends only those. The whole workflow is one key:
- Edit and save. Change a file in the Code tab and press ⌘S. It appears in Pending Upload, checked, with its diff.
- Review. Each row shows the change kind (Modified, Added, Deleted), the path, the size, and when you edited it. Select one to see a real diff of the deployed copy against your working copy — unified or split. The footer states the exact destination, e.g.
sftp://user@host:port/remote/path. - Publish. Pick the files to send and click Publish. Only those files go; the rest of the tree is left untouched.
The careful cases
The risky situations are the ones Pending Upload handles out loud rather than silently:
- Newer on the server
- A file changed on the host since your last publish (edited straight on the server, say) is put in its own group, never auto-selected, and its diff is flipped to show your copy → the server's copy with two explicit choices: overwrite it, or pull the server's version back into your working tree.
- Deletions
- Removing a file from a live host is its own group and its own decision — never bundled in with uploads.
- Ignored paths are visible
- Things like
.env,data/, and log folders are shown as ignored, so it's clear they won't be sent — rather than silently skipped. - A blocked connection stops the button, not the transfer
- If a server's password is missing from the OS credential store, Publish is disabled with the fix shown up front — instead of failing ten seconds into an upload.
When Pending Upload appears
The tab shows up only when one of the project's lanes has a server distribution (SFTP, FTPS, FTP, SCP, or rsync). For a project that ships to the App Store, Play, a static host, or a registry instead, there's no Pending Upload tab — the Overview tab's Publishing card tells you what it ships to and offers to add a host lane. If a project has several host lanes, they become a target picker (for example Production (SFTP) vs Staging (FTPS)), and the one you choose drives the remote paths, the diffs, and the button text.
Next steps
- Source Control: branches, diffs, commits & pull requests
- Distribution channels reference — setting up the server lane Pending Upload uses
- Cutting a release — the full build-and-ship flow