Xcode previews

Build your application, then use tuist share to publish it to your Tuist project. Connect your project first using the existing Xcode project or generated project guide.

Build and share#

For a Tuist-generated project:

For an existing Xcode project:

Replace the scheme, project, and workspace names with your own. To share a Release build, use -configuration Release when building and --configuration Release when sharing.

Physical devices#

You are responsible for signing device builds with a provisioning profile that allows installation on the recipient's device. Build with a device destination instead of the simulator SDK:

You can also share an already exported IPA:

Recipients can open an IPA preview link on their mobile device to install the application. Authentication and the project's preview visibility still apply.

CI and build numbers#

Use your existing CI authentication and make CFBundleVersion unique for each new build. For example, use GitHub Actions' ${{ github.run_number }}. Uploading the same binary and build number again through tuist share fails rather than creating a duplicate.

See Run a preview for running published builds, access, tracks, and README badges.

Tracks with tuist share#

For workflows that publish with tuist share, use --track to select a track:

Release notes#

Use tracks for environment groups and release notes for the purpose of an individual build:

Replace App with your app name, application file path, or executable distribution and its --executable option. Release notes are optional plain text, up to 10,000 characters. The first nonblank line appears as a single-line snippet in preview lists, so build numbers and other identifying information are visible at a glance. Long lines are truncated; full notes appear on the detail pages. Search matches display names and full release notes, including lines not shown in the snippet. Multiline notes are supported, for example --release-notes "$(< release-notes.txt)". They do not change the app's display name or its track.

Compatibility#

Release notes are additive metadata, not part of a preview's identity. Uploads from old and new clients still group into the same preview across platforms. The first nonblank notes are retained: a later upload can fill notes that were previously absent, but cannot overwrite existing notes. Omitting release_notes, sending null, or sending an empty or whitespace-only string never clears notes. Existing previews are not backfilled and remain valid without notes.

The list API's optional track query parameter matches a whole track name, case-insensitively, consistent with existing track storage. Omit it or send an empty value (?track=) to list all tracks. Track names remain open strings, not a fixed list of values. GET /api/projects/:account_handle/:project_handle/previews/tracks returns {total_count, tracks: [{name, count}]} with sorted, case-insensitively grouped named tracks, under the same preview-read authorization as listing builds. Counts cover the whole project independently of pagination, search, and the selected track; the total includes untracked previews. Only listable previews with a bundle identifier are counted. The list API also accepts optional search for a literal, case-insensitive substring of the display name or full release notes, combined with the track before pagination. Existing display_name filtering remains exact.

Old clients can continue uploading and listing previews without sending either field. New clients accept older responses that omit track or notes, and ignore unknown response properties added by future servers. API integrations should likewise ignore unknown response properties so additive metadata remains compatible.

Self-hosted deployments need a server version that supports release notes and track filtering, together with an updated client, to use these features. Older servers may ignore notes or unknown query parameters.

Pull/merge request comments#

Once your Tuist project is connected with your Git platform, add tuist share after a successful application build in CI. Tuist will post a preview link directly in your pull/merge requests, so reviewers can test without building locally:

Automations#

Use --json to get JSON output from tuist share:

Use the result for custom automations, such as posting a Slack message from CI. The url key contains the full preview link; qrCodeURL points to a QR code image for opening the preview on a device:

Recipients can use the Tuist macOS app or iPhone app independently of the build-system integration. The iPhone guide also covers in-app update notifications with the Tuist SDK.