When running a SwiftUI Multiplatform app in Xcode Cloud I'm getting the following error: CIWatcher encountered an error in CIWatcherTests failed with: Failed to install or launch the test runner. (Underlying Error: Could not launch “CIWatcherTests”. Runningboard has returned error 5. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn’t be completed. Launch failed. (Underlying Error: Launchd job spawn failed))) This runs fine on iOS and all those tests pass. The SwiftUI app on Mac is a menu bar app so I'm not sure if this could be the issue as it's not launching for some reason on the Xcode Cloud system? Maybe I need to add some run option to make this work? When run locally both iOS and macOS pass all the tests successfully

My project build failed in Xcode Cloud(works well in my local Mac), and the error shows: Preparing build for App Store Connect failed The error message is not clear enough to help us find the solution to fix it. Can anyone help with it?

My workflow is using Xcode 16.4 and macOS Tahoe 26.2 (25C56). I am trying to change Xcode version to 26.2. When I click Save after some time I get "Something went wrong" error message without any additional details (see screenshot). I get the same error for the following cases: Tried changing a different workflow Tried to deactivate a workflow Tried various combinations of Xcode (26.1, 26.1.1, 26.2) + mac OS (26.1, 26.2) Tried creating a new workflow with Xcode 26.2 (haven't tried any other Xcode versions though)

Hi, our Xcode Cloud runs produce dsyms for test targets that massively increase the artifacts size, more specifically the "Test Products for" zip, that slows down the build due to the "upload artifacts" phase. These dsyms are useless, so we would like to stop producing them on Xcode Cloud builds. Consider that the workflow uses the autogenerated scheme for a package that's part of the Xcode project. How can we tell Xcode Cloud to not produce dsyms?

I'm trying to upload my app build with Xcode Cloud. It builds and runs fine on the simulator, but when I try to upload to the cloud it keeps failing from Ad-hoc and Developer Distr. (Error code 70) I have tried/verified: -Verifying that my workflow archive in Xcode is set to "App Store Connect" (setting it to internal Test flight did not work either) -TestFlight Internal is set as a Post-Action and I created/added a test group -All App Store agreements signed and active -Revoking out-of-date developer certificates (Development Managed) -Running build from command line (using git pull origin main, git push origin main) Excerpts of the Error Output (ip addresses censored) Export archive for ad-hoc distribution 15.9s Run command: 'xcodebuild -exportArchive -archivePath /Volumes/workspace/tmp/3fe6638a-94b8-4944-8406-0e291469f933.xcarchive -exportPath /Volumes/workspace/adhocexport -exportOptionsPlist /Volumes/workspace/ci/ad-hoc-exportoptions.plist '-DVTPortalRequest.Endpoint=http://172.16.XX.XX:XXXX' -DVTProvisioningIsManaged=YES -IDEDistributionLogDirectory=/Volumes/workspace/tmp/ad-hoc-export-archive-logs -DVTSkipCertificateValidityCheck=YES -DVTServicesLogLevel=3' Error Command exited with non-zero exit-code: 70 Another similar error exists for development distribution

I'm attempting to use Cloud Signing to export the Release version of 3 different apps for App Store, as described in https://developer.apple.com/videos/play/wwdc2021/10204/ The process completes successfully, and appears to be signed correctly, with a newly-created certificate in the developer portal of type "Distribution Managed". When I upload to App Store Connect however, I see the following error for several third-party Swift packages, distributed as frameworks: Validation failed (409) Invalid Signature. Code failed to satisfy specified code requirement(s). The file at path “MyApp.app/Frameworks/MyFramework.framework/MyFramework” is not properly signed. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose “Clean All” in Xcode, delete the “build” directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/support/code-signing. If I have a manually created Distribution certificate installed in the keychain at the point of export, the same archive is signed with that certificate, and is accepted by App Store Connect without issue. The xcodebuild command I am using (roughly): xcodebuild -exportArchive \ -archivePath "$ARCHIVE_PATH" \ -exportPath "$EXPORT_PATH" \ -exportOptionsPlist "$EXPORT_OPTIONS" \ -authenticationKeyPath "$API_KEY" \ -authenticationKeyID "$API_KEY_ID" \ -authenticationKeyIssuerID "$API_KEY_ISSUER" \ -allowProvisioningUpdates The plist: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "<http://www.apple.com/DTDs/PropertyList-1.0.dtd>"> <plist version="1.0"> <dict> <key>method</key> <string>app-store-connect</string> <key>teamID</key> <string>$TEAM</string> <key>uploadSymbols</key> <true/> <key>signingStyle</key> <string>automatic</string> </dict> </plist> Is what I’m trying to do supported? Is this a bug?

Is it possible to run an xcode cloud test with arm64 simulators NOT x86? as my app doesnt work on x86.

I have a repo with hundreds of tags (we make a tag for every build and for every version, and it has a browser extension project pulled in as a subtree where all those commits can and do have version tags of their own). I am trying to create a simple tag-triggered workflow to release my app to the external users and the app store, so I want to trigger it every time I update and push an e.g. latest tag. I created a workflow and setup the tag trigger accordingly, but, in the workflow config, it says it can't find the tag. I saved the workflow anyway, however, when I try to manually trigger the workflow and browse the Tags tab, I only see a subset of the repo's tags. I suspect Xcode Cloud might be limiting the number of tags it pulls and consequently shows when searching tags. I think this is a bug/shortcoming of Xcode Cloud. Is there any way to work around this?

I have an app that downloads different pods, but they suddenly stopped: curl: (6) Could not resolve host: dl.google.com Warning: Problem : timeout. Will retry in 1 seconds. curl: (6) Could not resolve host: dl.google.com Warning: Problem : timeout. Will retry in 2 seconds. 1 retries left. curl: (6) Could not resolve host: dl.google.com Earlier it did not find https://cdn.cocoapods.org Temp issue or do you have to setup DNS of some sort?

I'm experiencing a persistent issue with Xcode Cloud where my iOS app (Spellboard) builds and archives successfully, but all three export steps fail with exit code 70: Export archive for ad-hoc distribution — exit code 70 Export archive for development distribution — exit code 70 Export archive for app-store distribution — exit code 70 Environment: Xcode Cloud Build 45, branch: main Project: Spellboard.xcodeproj Team: EinsteinAI Target: Any iOS Device (arm64) Automatic code signing (managed by Xcode Cloud) Building on a Remote Mac (additional code signing constraints) Error details from logs: The xcodebuild -exportArchive command fails during the signing phase. For example, the development distribution step shows: xcodebuild -exportArchive -archivePath /Volumes/workspace/tmp/ec4c2b30-ebd1-435f-8d8f-621326235df1.xcarchive -exportPath /Volumes/workspace/developmentexport -exportOptionsPlist /Volumes/workspace/ci/development-exportoptions.plist -DVTProvisioningIsManaged=YES -IDEDistributionLogDirectory=/Volumes/workspace/tmp/development-export-archive-logs -DVTSkipCertificateValidityCheck=YES -DVTServicesLogLevel=3 Command exited with non-zero exit-code: 70 The same pattern repeats for ad-hoc and app-store distribution exports. What I've verified: The build itself compiles successfully (all modules compile, command executed successfully) No code changes were made that would affect signing The workflow is configured with automatic signing managed by Xcode Cloud Post-action is set to TestFlight External Testing Additional constraint — Remote Mac: I'm building on a Remote Mac, which adds complexity to code signing and keychain access. The Remote Mac environment has known limitations with certificate and provisioning profile management compared to a local Mac. This may be a contributing factor to the export failures. This appears to be an issue with how Xcode Cloud is handling the Apple Distribution and Apple Development signing certificates during the export phase, not a build compilation issue. Has anyone encountered this recently, or is there a known issue with Xcode Cloud's managed signing on Remote Mac environments? Any guidance on resolving exit code 70 during the export step would be greatly appreciated.

I'm currently using another provider for CI/CD. They've been offering Apple Silicon builds for over a year now. When we switched over, we saw our build times cut in half. I've seen similar results locally, back when I bought an M1 Mac. So, recently, I tried to use Xcode Cloud on my project. My build time is nearly 45 minutes, where my build time on my current system is about 15 minutes, max. Since I work on a team, and we make regular commits, having a 45 minute turnaround is not ideal. When I looked at the logs of my Xcode Cloud project, I saw a lot "x86_64" stuff in there, which led me to believe that Xcode Cloud is still building on Intel machines. Additionally, I run tests on my builds. The build time alone (before running tests) was almost 20 minutes. The 15-minute time I cited with my current CI/CD included build time & tests running. So, a whole cycle finishes on my current setup before tests are even run. I noticed that there was a bunch of x86_64 in the logs, which made me think that Xcode Cloud is still using Intel. Is this true? I've just gotten really used to faster build times, and I can't move onto a system like this, where the times are so drastically different. Like, I wouldn't mind build time that would add only a few more minutes to what I have now. But going from 15 -> 45 minutes is a real problem.

We have been using Xcode Cloud Build to test an internal app. A new build is triggered automatically by a merge to main in github. Up until a few weeks ago everything was fine, we would get a notarize button and a download link. On 1/29/2026 the process started timing out at the finalizing step. The logs in the UI show no errors just a "cancelled" flag after 8-12 hours. Clicking the logs tab shows all green up until the step you would normally expect a "stapling". Any thoughts on were to look to triage this?

With Xcode 26.3, and beta 26.4 (under macOS 26.4 Beta (25E5223i)) my loaded platforms for canvas and simulators keep disappearing. Try to add platforms, and the download just sits there.

I've yet to encounter these errors when running UI tests locally, but I'd estimate that 80-90% of my test runs on Xcode Cloud fail due to it. I'm just testing with iPhone simulators, I've set it to retry on failure, but no luck. Is there a setting or something I can tweak in my test code to improve the situation? I am on the latest xcode/iOS dev betas - but it was doing this before I switched to them from.

Hi everyone, I’m encountering an issue with Xcode Cloud when trying to notarize my macOS app. As shown in the screenshot, there are no errors in the logs, but the process gets stuck indefinitely. The message says: The post-action could not be completed because the build was canceled. No artifacts are generated at all. This problem started recently. Notarization works perfectly when I submit from my local Xcode, so it seems to be specific to Xcode Cloud. Has anyone else experienced this?

I am unable to connect Xcode Cloud to my GitHub organization repository despite being the organization owner. Error: CI.SCM.Error.RepositoryNotFound Xcode Version: 16.2 (or your version) Steps I have taken: Verified I am an Owner of the GitHub organization Uninstalled and reinstalled Xcode Cloud GitHub App multiple times Cleared all local Xcode caches and preferences Signed out of Apple ID on Mac and restarted Signed back in to Xcode only (not system level) Tried granting access again Attempted with multiple organization owner accounts Following API shows: 401 Unauthorized on https://appstoreconnect.apple.com/olympus/v1/providerSwitchRequests Additional context: GitHub App shows as successfully installed on organization Repository access set to "All repositories" Has anyone else encountered this or found a workaround? Thank you!

We build TestFlight/App Store builds of our app through Xcode Cloud. Our app uses Metal shaders so we install the Metal toolchain through a ci_pre_xcodebuild.sh script which simply runs: xcodebuild -downloadComponent metalToolchain in our Xcode Cloud builds. This has been working well for us for the last 6 months or so, but since yesterday (March 5) we have been seeing consistent failures when running this script in our Xcode Cloud builds: Beginning asset download... 2026-03-06 04:14:34.727 xcodebuild[13315:58523] Writing error result bundle to /var/folders/6h/_32gb9js77g6c54h3q7g6q1h0000gn/T/ResultBundle_2026-06-03_04-14-0034.xcresult xcodebuild: error: Failed fetching catalog for assetType (com.apple.MobileAsset.MetalToolchain), serverParameters ({ RequestedBuild = 17C7003j; }) Prior to Mar 5 it looks like the toolchain image which was being downloaded/installed was 17C519 but this has now changed to 17C7003j. We haven't changed anything with our Xcode Cloud workflow setup, and the same macOS/Xcode images are being used for the workflow runs (macOS Tahoe 26.2 (25C56) and Xcode 26.3 (17C529) respectively) now as when our builds were succeeding a few days ago. What's the best way to resolve this issue? Looks like we can't even pass an image identifier to xcodebuild -downloadComponent so we're a bit stuck here.

Showing All Messages [!] Error installing FBSDKLoginKit [!] /usr/bin/curl -f -L -o /Volumes/workspace/tmp/d20260316-6574-ros9od/file.zip https://github.com/facebook/facebook-ios-sdk/releases/download/v18.0.2/FacebookSDK_Dynamic.xcframework.zip --create-dirs --netrc-optional --retry 2 -A 'CocoaPods/1.16.2 cocoapods-downloader/2.1' % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0 curl: (35) Recv failure: Connection reset by peer Command exited with non-zero exit-code: 1 Running ci_post_clone.sh script failed (exited with code 1). Executable scripts are run using the interpreter specified in the shebang line.

We're investigating using xcode cloud to do our CI builds. We have our own on-prem self-managed GitLab behind a private firewall. Some questions on this: I see some IP's for Apple here: https://developer.apple.com/documentation/xcode/setting-up-your-project-to-use-xcode-cloud#Use-a-remote-source-control-repository Do these IP's ever change? Are there specific ports Apple uses? Would be nice to limit to only what's needed. Do we have to open in-bound access or can we instead have our builds reach out with an outbound only setup?

Hello, Our build in Xcode Cloud uses gradle via a custom script. Today we're seeing persistent errors when our build job attempts to download the Gradle binary in the Xcode Cloud env. Run custom shell script 'Build Shared KMP Framework' Downloading https://services.gradle.org/distributions/gradle-8.13-bin.zip Exception in thread "main" java.net.ConnectException: Connection refused at java.base/sun.nio.ch.Net.pollConnect(Native Method) So we're currently blocked from submitting an app update. Can an Xcode Cloud engineer please comment regarding whether this is an ephemeral issue related to other networking issues reported in the forum here or if this warrants other investigation on our side?