Developers using rented or cloud Macs for iOS and macOS builds often hit the same wall: code signing. Certificates live in Keychain; provisioning profiles must match the signing identity and the build machine. On a remote Mac you do not own, managing these without chaos requires a clear workflow. This guide covers how to set up and maintain code signing on a remote Mac so you can archive, notarize, and ship apps reliably.
Why Code Signing Is Hard on Remote Macs
Code signing ties your app to your Apple Developer identity and the device or distribution channel. macOS and iOS require a valid signing certificate in the Keychain and, for many workflows, a provisioning profile that links the app ID, certificate, and devices or distribution method. On a local Mac, you install the certificate once and Xcode often handles the rest. On a remote or ephemeral Mac, the machine may be reimaged, shared, or rebuilt, so certificates and profiles must be reintroduced or managed in a repeatable way.
Common pain points include: certificate and private key only on one machine; provisioning profile mismatches after Xcode or OS updates; and CI/CD jobs failing because the build host has no valid signing identity. Solving this on a rented Mac means treating certificates and profiles as part of your environment setup, not a one-time manual step.
Certificate Types and Where They Live
Apple uses different certificate types for development and distribution. Knowing which you need on the remote Mac avoids wasted effort.
- Apple Development: For running on connected devices and local testing. Stored in Keychain; Xcode can create and manage it via "Manage Certificates."
- Apple Distribution (App Store): For uploading to App Store Connect. Required for archive and upload; must be in the Keychain of the machine performing the archive.
- Developer ID Application: For distribution outside the Mac App Store (direct download, notarization). Required for ad-hoc or enterprise-style macOS distribution.
- Developer ID Installer: For signing installer packages (.pkg) distributed outside the Mac App Store.
Cloud-managed certificates (Xcode 13+) allow Apple to hold the private key and sign on your behalf when using Xcode Organizer for distribution. The codesign CLI and many CI scripts still rely on a certificate in the local Keychain, so for remote Macs used in scripts or automation, importing a .p12 (certificate + private key) into Keychain remains the standard approach.
Provisioning Profiles: What They Do
A provisioning profile binds an App ID, one or more certificates, and (for development) a set of devices. For App Store distribution, Xcode typically downloads or creates the right profile when you archive and upload. For Developer ID or development builds on a specific Mac, you must have a profile that includes the signing certificate installed on that Mac.
Gatekeeper evaluates provisioning profile validity at every app launch, not just at install. If the profile expires, the app will no longer launch. Keeping profiles up to date on the remote Mac is critical.
Profiles are stored under ~/Library/MobileDevice/Provisioning Profiles. Xcode can download them automatically when signing, or you can install them manually by double-clicking or copying them into that folder. On a remote Mac, either ensure Xcode is signed in with the correct Apple ID so it can fetch profiles, or deploy profiles as part of your setup (e.g., from a secure store or CI secrets).
Putting Certificates on the Remote Mac
To sign builds on a rented Mac, you need the signing identity (certificate + private key) in that Mac's Keychain. The usual approach is to export from your primary machine as a .p12 file (Keychain Access: select certificate, export, set a password) and then import on the remote Mac.
Import steps
- Transfer the .p12 to the remote Mac over a secure channel (SSH/SCP, or a secrets manager used by your CI).
- On the remote Mac, double-click the .p12 or run:
security import identity.p12 -k ~/Library/Keychains/login.keychain-db -T /usr/bin/codesign -T /usr/bin/security(adjust keychain path for your setup). - Enter the .p12 password when prompted. Ensure the keychain is unlocked for automated builds (e.g., CI runs as a user whose keychain is unlocked, or use a keychain password in the environment).
For CI and automation, avoid storing .p12 in repo or plain config. Use a secret store (e.g., GitHub Secrets, HashiCorp Vault) and inject the .p12 and password only in the job that needs them, then import into a temporary or job-specific keychain so the key is not left on disk after the run.
Local vs Cloud Signing
Apple's cloud-managed certificates remove the need to install a distribution certificate on the build machine when you use Xcode Organizer for export and upload. Xcode talks to Apple's servers and signs with a key Apple holds. This simplifies setups where the only distribution path is via Xcode's GUI. Limitations: the codesign command and many CI pipelines do not use cloud signing; they expect a certificate in Keychain. So for scripted or headless builds on a remote Mac, you still need a local certificate.
| Scenario | Certificate location | Best for |
|---|---|---|
| Xcode Organizer archive + upload | Cloud (optional) or Keychain | Manual or GUI-driven distribution |
| CI/CD scripted build + archive | Keychain on build host | Fastlane, xcodebuild, Codemagic, etc. |
| Developer ID / notarization | Keychain (Developer ID cert) | macOS apps outside App Store |
Best Practices on a Rented or Cloud Mac
- Use one identity per purpose: Separate Development and Distribution certificates. On the remote Mac, install only what that machine needs (e.g., only Distribution if it only runs release builds).
- Sync with Fastlane Match (optional): Match stores certificates and profiles in a private repo and installs them on any machine. Suited for teams and CI; every environment runs
fastlane match readonlyto get the same signing setup. - Document the keychain: Note which keychain you import into (login vs custom) and ensure the build user has access. For headless CI, unlocking the keychain at the start of the job is often required.
- Rotate and renew: Certificates and some profiles expire. Track expiration and renew in the Developer portal; re-export and re-import to the remote Mac or refresh Match so the build host always has a valid identity.
VNCMac and Code Signing
On a VNCMac dedicated Mac mini, you get full admin and Keychain access. You can import your .p12, install provisioning profiles, and use Xcode or the command line exactly as on a local Mac. Builds run on the same hardware; only the connection is remote. For teams that need a stable, repeatable signing environment without maintaining physical hardware, a rented Mac with a clear certificate and profile workflow removes the usual "it works on my machine" signing failures.
Conclusion
Code signing on a remote Mac is manageable if you treat certificates and provisioning profiles as part of your environment. Import the right signing identity into Keychain, install or fetch the correct profiles, and use either Xcode Organizer (with optional cloud signing) or scripted builds with a local certificate. With a consistent process and, optionally, tools like Fastlane Match, a rented Mac can be a reliable place to archive and ship iOS and macOS apps.