Will a Remote Mac SSH Build Stop After Disconnect? 2026 Persistent Task Plan

Do not treat a build started directly in an SSH shell as safe after disconnection. Put an occasional long job inside a reconnectable session with separate logs and artifact checks; move recurring or overnight work to a CI Runner or managed background job. Simulator, Keychain, and graphical authorization tasks need a separate logged-in-session test.

This week, run one deliberate disconnect test, one user-logout test, and one reboot test before trusting the remote Mac with a release.

This guide is for Windows and Linux developers using SSH to run iOS Archive or test jobs without a local Mac. It also suits small teams that need overnight builds, scheduled tests, or TestFlight delivery, and operators who cannot tell whether a dropped connection stopped the process, hid the logs, or left a blocked job behind.

The first mistake is treating “the terminal stopped refreshing” as a process result. An SSH connection, a shell session, a build process, a logged-in user session, a graphical session, and App Store Connect processing are separate layers.

A dropped connection can leave at least three operational outcomes:

• The build process ends with the shell or loses access to a required session.
• The build continues, but the operator loses the visible output and cannot prove the final state.
• The process remains present while a signing, Simulator, permission, or network stage is blocked.

The correct evidence is not a moving terminal window. It is the combination of process state, complete standard output, complete standard error, exit status, and the expected artifact. Apple documents xcodebuild as a command-line interface for Xcode operations, while its environment variable reference describes build result and exit-status behavior; use those references when defining what counts as a completed command rather than relying on screen output alone (Apple’s xcodebuild reference and exit-status documentation).

A one-off Build, Test, or Archive can remain interactive if the developer needs to watch it. The session must still be designed for reconnection. A plain command typed after SSH login has no reliable operational record unless the command itself writes one.

A safer pattern is to create a working directory, a log directory, and an artifact directory before starting the build:

mkdir -p "$HOME/build-runs/<RUN_ID>/logs"
mkdir -p "$HOME/build-runs/<RUN_ID>/artifacts"

cd "<REMOTE_PROJECT_PATH>"

xcodebuild \
  -workspace "<WORKSPACE_NAME>.xcworkspace" \
  -scheme "<SCHEME_NAME>" \
  -configuration Release \
  -destination "generic/platform=iOS" \
  archive \
  -archivePath "$HOME/build-runs/<RUN_ID>/artifacts/<APP_NAME>.xcarchive" \
  > "$HOME/build-runs/<RUN_ID>/logs/archive.stdout.log" \
  2> "$HOME/build-runs/<RUN_ID>/logs/archive.stderr.log"

printf '%s\n' "$?" > "$HOME/build-runs/<RUN_ID>/logs/archive.exit"

The placeholders are intentional. Replace them with a project path, workspace, scheme, run identifier, and app name that do not expose credentials or signing data. Keep standard output, standard error, and the exit result as separate records. If both streams are merged into one terminal transcript, a later review may not distinguish a compiler failure from a shell or upload failure.

A reconnectable terminal session is useful here because it preserves an interactive context that can be attached to again. It is not the same as a CI system. It does not automatically define source checkout, environment variables, credentials, retention, or notification rules.

Before using SSH, confirm that Remote Login is enabled on the Mac and that the account and host address are correct. Apple’s Remote Login instructions show the supported SSH access pattern and the relevant system setting (Apple Remote Login setup).

After an intentional disconnect, reconnect and inspect evidence instead of immediately rerunning:

RUN_DIR="$HOME/build-runs/<RUN_ID>"

ps aux | grep '[x]codebuild'
tail -n 80 "$RUN_DIR/logs/archive.stdout.log"
tail -n 80 "$RUN_DIR/logs/archive.stderr.log"
cat "$RUN_DIR/logs/archive.exit"
ls -ld "$RUN_DIR/artifacts/<APP_NAME>.xcarchive"

If the exit file is missing, the command may still be running, may have been terminated, or may have failed before the shell wrote the result. That is an unresolved state, not a successful build.

Archive, export, binary upload, and App Store Connect processing should be treated as separate jobs. A successful Archive creates an .xcarchive; export creates an installable distribution output; upload transfers a package; App Store Connect then performs its own server-side processing. One completed stage does not prove that the next stage finished.

A controlled sequence might look like this:

xcodebuild -exportArchive \
  -archivePath "<ARCHIVE_PATH>" \
  -exportOptionsPlist "<EXPORT_OPTIONS_PLIST>" \
  -exportPath "<EXPORT_PATH>" \
  > "<LOG_DIR>/export.stdout.log" \
  2> "<LOG_DIR>/export.stderr.log"

printf '%s\n' "$?" > "<LOG_DIR>/export.exit"

Keep the archive path, export directory, logs, and delivery record together under the same run identifier. Apple’s distribution documentation describes the Archive and export flow, so the acceptance record should map each local output to the stage it proves (Apple’s Archive and export workflow).

Do not rerun the entire pipeline simply because the SSH connection failed during upload. First check:

• Whether the .xcarchive exists and has the expected timestamp.
• Whether the export directory contains the expected package.
• Whether the upload command has a recorded exit result.
• Whether the App Store Connect record shows the expected version and build number.
• Whether a retry would create a duplicate delivery or conflict with an already accepted build.

A recovered shell does not recover App Store Connect processing. Apple describes distribution to testers and releases as a separate publishing flow, so local upload completion and backend processing must remain separate evidence items (Apple’s App Store Connect distribution guidance).

Operational reminder: Never remove an archive or overwrite an export directory during recovery until the previous run has been classified as failed, complete, or awaiting backend processing.

Interactive SSH is a poor permanent trigger for frequent commits, night builds, and scheduled releases. It depends on a human login, a terminal context, an available network path, and an operator who knows how to recover an ambiguous state.

A CI Runner is better suited to repeated work because each job can define:

• The source revision and checkout directory.
• The Xcode command and destination.
• The signing and Keychain context.
• Separate logs and retained artifacts.
• A job identifier and failure status.
• Rules for retrying a failed stage without repeating completed stages.

The Runner still needs acceptance testing. A process that starts correctly from an SSH shell may fail when launched by a service account because its home directory, PATH, Keychain access, developer tools path, or graphical session differs.

launchd is useful when the Mac must start a defined background job under a known operating-system context. Apple’s documentation describes launchd job configuration and the distinction between system and user contexts (launchd job configuration and process contexts). Use it to establish a managed trigger, not as proof that the iOS build environment is fully release-ready.

For a reboot-aware job, define the executable using an absolute path, define the working directory, send output to known files, and record a start marker containing the run ID. The job should fail visibly if the project path, signing identity, or required secret is unavailable. Silent fallback is worse than a failed build because it produces an apparently healthy service with no trustworthy artifact.

Pure command-line compilation is not the same as Simulator testing or signed distribution. A process can remain alive while the user session it needs has ended. A Keychain item may require authorization. A Simulator may need a valid user and graphical context. A workflow that depends on a graphical prompt may wait indefinitely when launched from an unattended service.

Separate the tests by context:

• Command-line build: run xcodebuild with a known project, scheme, destination, and output paths.
• Simulator test: confirm that the selected Simulator runtime is available and that the test produces an .xcresult.
• Signing: confirm the intended Keychain and signing identity without weakening access controls as a first response.
• Graphical operation: test under the actual logged-in session that the workflow requires.
• Upload: verify the local package and remote delivery status independently.

Apple’s Xcode testing guidance treats test execution and result interpretation as distinct parts of the workflow, so retain the .xcresult bundle instead of keeping only a console transcript (Xcode test results documentation).

If a permission change is proposed, record its scope, affected account, affected Keychain or job, and rollback command before applying it. Do not turn off a security control merely because a disconnected SSH session made the failure difficult to diagnose.

The right recovery action depends on the stage that was running, not only on the fact that the network failed.

Does xcodebuild keep running after an SSH connection drops?

Not as a universal rule. The result depends on the shell, session ownership, command wrapper, user state, and build requirements. A direct foreground command should be classified as unsafe until tested. A reconnectable session can preserve interactive work, while a managed job can provide a more explicit lifecycle. In every case, verify the process, logs, exit result, and artifact.

Recovering a build after a network interruption

Reconnect to the Mac and identify the run directory or job ID. Inspect the process list, the newest log entries, the exit record, and the expected .xcarchive or .xcresult. If an Archive exists, continue with export or delivery instead of rebuilding. If the stage is uncertain, preserve its files and start a new run with a new identifier.

Reconnecting to a running iOS build

Use a reconnectable terminal for occasional interactive jobs. Attach to the existing session rather than launching a second build. For recurring work, query the CI Runner or managed job status, then open its retained logs. A terminal that appears idle is not enough evidence; the log timestamp, process state, and output directory must agree.

Overnight builds: terminal or CI Runner?

A reconnectable terminal is acceptable for a manually supervised task with a clear end point. Overnight tests and repeated releases belong in a CI Runner or managed background job because the trigger, environment, logs, and failure state can be recorded without one developer remaining attached to SSH. The Runner still needs a reboot and logged-out-user test.

Restoring service after a remote Mac reboot

Use a defined launchd job or CI service integration with explicit paths and log files, then perform a real reboot. Check whether the job starts, whether the correct account owns it, whether Xcode tools are available, and whether signing and Simulator operations work. Automatic process restart alone does not restore a valid release environment.

Run these tests against the actual remote Mac, project, signing setup, and delivery path. Do not substitute a harmless shell command for the real operation if the production failure involves Archive, signing, or upload.

• [ ] Record the Mac account, project path, scheme, destination, Xcode command, run ID, and expected artifact paths.
• [ ] Confirm Remote Login access and record the SSH command used for the test.
• [ ] Start a real Build, Test, or Archive inside the selected reconnectable session or managed job.
• [ ] Save standard output and standard error to separate files.
• [ ] Save the shell or job exit result as its own record.
• [ ] Disconnect SSH while the build is active.
• [ ] Reconnect without starting a second build.
• [ ] Verify process state, recent log entries, exit result, and artifact existence.
• [ ] Confirm that the .xcresult or .xcarchive is readable and belongs to the current run.
• [ ] Test export separately from Archive.
• [ ] Test upload separately from App Store Connect processing.
• [ ] Log out the user while a suitable test is running.
• [ ] Repeat a signing and Simulator test under the intended account context.
• [ ] Reboot the Mac and verify that the managed job starts with the expected environment.
• [ ] Record whether the job failed, completed, retained logs, retained artifacts, and could resume without duplicating delivery.
• [ ] Document rollback steps before changing Keychain, permissions, or background-job configuration.

This comparison is a decision tool, not a claim that one mechanism behaves identically on every macOS release. The task owner, login context, installed Xcode tools, signing assets, and service configuration must be included in the acceptance record.

If the current setup cannot stay online, retain complete logs, or restart its build service after a reboot, continuing to depend on a personal computer creates three avoidable costs: the machine must remain powered on, recovery depends on one operator’s local session, and a network failure can leave release evidence scattered across a terminal and an unverified filesystem.

After the tests above, choose the smallest reliable arrangement. Keep a reconnectable session for occasional work. Use a CI Runner for repeated builds. If the team needs a continuously available Mac without purchasing and maintaining another machine, review the JEXCLOUD remote Mac options and select an environment that fits the required online period and recovery workflow. Regional availability can be reviewed through the JEXCLOUD Mac access page.

A rented Mac is not a substitute for designing logs, artifacts, signing boundaries, and reboot tests. It is useful when the existing device cannot remain available long enough to support those controls. Once the environment passes the disconnect, logout, and reboot checks, the decision becomes straightforward: use the temporary reconnectable path for occasional work, or keep a managed remote Mac environment for repeatable iOS delivery.