Hello Apple Developer Community, I’m trying to connect a Bitbucket repository to Xcode Cloud through App Store Connect, but the connection consistently fails with an HTTP 403 response. Environment Product: Xcode Cloud / App Store Connect SCM: Bitbucket Cloud Integration: App Store Connect → Xcode Cloud → Bitbucket Date: September 15, 2026 Time: 3:51:44 PM IST / 10:21:44 UTC Apple Correlation ID: TIIRWMUD46W7OMZ7UDWXBRFI7E HTTP Status: 403 I have Administrator access in both App Store Connect/Apple Developer and the Bitbucket workspace/repository. What I have already checked I contacted Bitbucket Support and provided them with the browser network/HAR capture from the failed connection. Bitbucket confirmed that the App Store Connect Bitbucket callback returned HTTP 403. However, they explained that the browser capture cannot show the subsequent server-to-server communication between Apple/Xcode Cloud and Bitbucket. Bitbucket therefore asked Apple to investigate the server-side request using the Apple Correlation ID and timestamp. They indicated that the failure could potentially involve: Apple rejecting the Bitbucket OAuth callback. Apple receiving the callback but failing while processing it. A server-to-server request from Apple to Bitbucket returning an error. An OAuth authorization-code or access-token exchange failure. The 403 being generated by Apple's callback service. My question Has anyone experienced a similar HTTP 403 when connecting Bitbucket Cloud to Xcode Cloud through App Store Connect? Also, is there a known Xcode Cloud/App Store Connect requirement for Bitbucket OAuth or access tokens that could cause this type of 403 even when the user has administrator permissions? If an Apple engineer is able to review the server-side logs, could the following details help identify the failure? Apple Correlation ID: TIIRWMUD46W7OMZ7UDWXBRFI7E Timestamp: September 15, 2026, 10:21:44 UTC HTTP Status: 403 Bitbucket has already confirmed that the relevant server-to-server communication is not visible in the browser HAR, so I’m trying to determine which side is generating the 403 and at which stage of the OAuth flow it occurs. Any guidance from someone familiar with Xcode Cloud + Bitbucket integration would be greatly appreciated. Thank you.

I am seeing Xcode Cloud reuse and reassign a single ciProduct when onboarding multiple iOS app targets from one Xcode project. Each target has its own bundle ID, PBXNativeTarget, product reference, and shared scheme. Environment: Xcode 26.6 (17F113) macOS Tahoe 26.5.2 GitHub repository connected to Xcode Cloud Project: pilot-ios/Airtap.xcodeproj Targets / shared schemes: PocketPilot.ai DEV1 — ai.airtap.dev1 PocketPilot.ai DEV2 — ai.airtap.dev2 PocketPilot.ai DEV3 — ai.airtap.dev3 PocketPilot.ai DEV4 — ai.airtap.dev4 PocketPilot.ai QA1 — ai.airtap.qa1 PocketPilot.ai QA3 — ai.airtap.qa3 Every entry above is a separate PBXNativeTarget with a distinct productReference. Each shared scheme is stored under Airtap.xcodeproj/xcshareddata/xcschemes and builds its corresponding target. QA1 and QA3 were onboarded earlier and received independent Xcode Cloud products as expected. Reproduction: In Xcode, open Xcode Cloud Reports and choose Create Workflow. Select target PocketPilot.ai DEV1 and create an archive workflow using scheme PocketPilot.ai DEV1. DEV1 appears under the correct App Store Connect app. Create another workflow for target PocketPilot.ai DEV2 using scheme PocketPilot.ai DEV2. DEV1 disappears as a separate Xcode Cloud product. Both the DEV1 and DEV2 workflows now appear under the DEV2 App Store Connect app. The App Store Connect API confirms this is not only an Xcode UI or cache issue: Before DEV2 onboarding, ciProduct F048BF00-CECF-4926-84DB-D3474CB030A9 was related to bundle ID ai.airtap.dev1. After DEV2 onboarding, that same ciProduct ID became related to bundle ID ai.airtap.dev2. The product now contains both workflows: PocketPilot DEV1 Archive / scheme PocketPilot.ai DEV1 PocketPilot DEV2 Archive / scheme PocketPilot.ai DEV2 No build was started, and both workflows are currently disabled. Expected behavior: Because every target has a different bundle ID, Xcode should create a separate Xcode Cloud product for each target, as described in the Xcode Cloud onboarding documentation. Actual behavior: The newest onboarding changes the existing ciProduct-to-App Store Connect app relationship instead of creating a new ciProduct. This moves all earlier workflows to the newest app. The public App Store Connect API cannot repair this because it supports reading and deleting ciProducts, but not creating one; ciWorkflows can only be created under an existing ciProduct. I also encountered an Xcode crash while adding another product. The crash stack included XcodeCloudNavigableItemCoordinator.removeNavigableItem(for:) and IDENavigableItemCoordinator, which may be related to the product reassignment. I can provide the crash report in Feedback Assistant if needed. A recent forum thread reports the same high-level symptom: previously created workflows migrate to the newest app. In our case, the API relationship change above makes the backend reassignment directly observable. Is this a current Xcode Cloud onboarding/backend regression? Is there a supported workaround, or can Apple Support create or restore separate ciProducts for these bundle IDs?

Hello Apple Developer Community, I’m trying to connect a Bitbucket repository to Xcode Cloud through App Store Connect, but the connection consistently fails with an HTTP 403 response. Environment Product: Xcode Cloud / App Store Connect SCM: Bitbucket Cloud Integration: App Store Connect → Xcode Cloud → Bitbucket Date: September 15, 2026 Time: 3:51:44 PM IST / 10:21:44 UTC Apple Correlation ID: TIIRWMUD46W7OMZ7UDWXBRFI7E HTTP Status: 403 I have Administrator access in both App Store Connect/Apple Developer and the Bitbucket workspace/repository. What I have already checked I contacted Bitbucket Support and provided them with the browser network/HAR capture from the failed connection. Bitbucket confirmed that the App Store Connect Bitbucket callback returned HTTP 403. However, they explained that the browser capture cannot show the subsequent server-to-server communication between Apple/Xcode Cloud and Bitbucket. Bitbucket therefore asked Apple to investigate the server-side request using the Apple Correlation ID and timestamp. They indicated that the failure could potentially involve: Apple rejecting the Bitbucket OAuth callback. Apple receiving the callback but failing while processing it. A server-to-server request from Apple to Bitbucket returning an error. An OAuth authorization-code or access-token exchange failure. The 403 being generated by Apple's callback service. My question Has anyone experienced a similar HTTP 403 when connecting Bitbucket Cloud to Xcode Cloud through App Store Connect? Also, is there a known Xcode Cloud/App Store Connect requirement for Bitbucket OAuth or access tokens that could cause this type of 403 even when the user has administrator permissions? If an Apple engineer is able to review the server-side logs, could the following details help identify the failure? Apple Correlation ID: TIIRWMUD46W7OMZ7UDWXBRFI7E Timestamp: September 15, 2026, 10:21:44 UTC HTTP Status: 403 Bitbucket has already confirmed that the relevant server-to-server communication is not visible in the browser HAR, so I’m trying to determine which side is generating the 403 and at which stage of the OAuth flow it occurs. Any guidance from someone familiar with Xcode Cloud + Bitbucket integration would be greatly appreciated. Thank you.

I have a workflow where I want to specifically run some tests in the iOS 18 simulator. All while using Xcode 26 on Xcode Cloud. In my Xcode Cloud workflow I can set the iOS version, but just iOS 16, 17 and 26, but no 18? I'm very confused here Not sure which is the right channel anyway to request support to Xcode Cloud too

I am trying to use Safari Web Extension Packager to upload a web extension ZIP through App Store Connect, following this documentation: https://developer.apple.com/documentation/safariservices/packaging-and-distributing-safari-web-extensions-with-app-store-connect However, I cannot find the Packager upload section at all. Steps to reproduce: Sign in to App Store Connect as the Account Holder of an active Apple Developer Program membership. Open an existing app, then select Xcode Cloud. Scroll to the bottom of the page. Actual result: The page only shows the standard Xcode Cloud introduction, with “Get started in Xcode” and an “Open Xcode” button. There is no Safari Web Extension Packager section or ZIP upload control. Another app under the same team shows the same introduction page. Additional details: The existing Safari extension was previously distributed as an iOS app using Xcode. I want to use the Packager for the next update while retaining the existing app identity. The source is a WXT project and the Safari ZIP has been generated. I cannot reach the upload or build-validation step. During my September 6 checks, the Developer Program and App Store Connect agreements were accepted, with no pending agreement prompt. Apple Developer Support's account-support team directed me to the Developer Forums because they could not diagnose this technical issue. Could an Apple engineer clarify: Is Packager available to all eligible teams, or still being rolled out? Are there country/region restrictions, including mainland China? What prerequisites control the upload section? Must a team first enable a conventional Xcode Cloud workflow through local Xcode, even if the intended input is only a web extension ZIP? Can Packager update an existing app previously built with Xcode, or does initial setup require a new app record? What is the correct page or navigation path when only the Xcode Cloud introduction is visible? This question concerns access to the web-based packaging UI. A documented activation step or confirmation of availability requirements would be helpful. Screenshot of the missing upload section:

While validating Xcode Cloud with a self-managed GitLab instance, I found what appears to be an OAuth scope issue affecting private repositories. Apple’s documentation says to configure the GitLab OAuth application with: api, read_repository, read_user However, the actual /oauth/authorize URL generated by Xcode Cloud requests only: scope=api+read_user With a private GitLab repository, OAuth completes successfully and Xcode Cloud can call: GET /api/v4/user → 200 GET /api/v4/projects/:project → 200 But repository setup fails with: Repository was not found. Either the repository does not exist or you do not have permission to access it. The GitLab user had Maintainer-or-higher access. I reproduced this from a clean Xcode Cloud setup. As a control test, I repeated the exact same flow but manually changed the OAuth authorization request to: scope=api+read_user+read_repository GitLab then explicitly requested read-only access to private repositories over Git HTTP. After authorization, the same private repository connected successfully to Xcode Cloud, and a build could be queued normally. A public repository works without read_repository, which can hide the issue. So the reproducible difference was: Private repo + Apple-generated api read_user → fails Private repo + api read_user read_repository → succeeds This also appears inconsistent with Apple’s own self-managed GitLab setup documentation, which instructs users to enable read_repository. I’m sharing this mainly for others who may run into the same issue with private repositories.

Hi! I've successfully uploaded my web extension using the Web Extension Packager. However, there was a build error. When I review the list of cloud builds and click "view issues" for the failed build, I get the message: "Exporting for App Store Distribution failed. Please download the logs artifact for more information." However, I can't find any link in the app store connect web UI for viewing the logs artifact for Web Extension Packager builds.

I’m packaging a Safari Web Extension using the web-based Safari Web Extension Packager in App Store Connect. The ZIP uploads successfully, the manifest is accepted, and the Packager automatically creates the related Extension identifier. However, every build fails during export with: Exporting for App Store Distribution failed. Please download the logs artifact for more information. It also shows: Exporting for Development Distribution failed. Please download the logs artifact for more information. There is no Logs, Artifacts, or Download button on the build or issue page. To isolate the problem, I tested: Manifest V2 and Manifest V3 A minimal extension containing only HTML and icons No JavaScript, permissions, host permissions, APIs, or external dependencies A completely new App Store Connect app A new explicit Bundle ID A name-matched extension ZIP Multiple version and build numbers Every test produced exactly the same export errors. The App Store Connect agreement is active, and the Account Holder has access to cloud-managed distribution certificates. Because even a clean minimal extension and a newly created app fail identically, this appears to happen during cloud signing, provisioning, or archive export—not while parsing the extension. Questions: How can I download the logs artifact requested by the error when the Packager interface does not provide it? Can Apple confirm whether the web-based Packager currently has an export or automatic-signing issue? Is there any required certificate, provisioning profile, App ID configuration, or account permission that the Packager does not create automatically?

For the last 2 months I have been submitting the first iOS builds of my app “Zema Kirar”. However Appstore connect wrongly rejects it claiming it was built bu a BETA version of xcode and / or MacOS. My Dev Environment I am Running macOS Tahoe 26.6.2, and Xcode 26.6 (Build 17F113). Both are the ”current” latest public (GM) versions required by apple. Steps to reproduce: Xcode cloud build/ and transporter upload completes > I select the build > click save > click on Submit. Appstore connect shows error: Unable to add for Review. The items below are required to start the review process: New apps and app updates must be built with the latest public (GM) versions of Xcode, and the iOS, macOS, watchOS, and tvOS SDK. Apps built with the beta versions aren’t allowed.

I’m experiencing a persistent TestFlight installation issue that started after my most recent Apple Developer Program renewal. All builds upload and process successfully in App Store Connect/TestFlight, and there are no apparent issues with the builds themselves. However, when testers try to install the apps, they receive the following error: “The requested app is not available or doesn’t exist.” Since the same problem is affecting multiple apps under the same Apple Developer account, while the builds are uploading and processing successfully, I suspect this may be related to the TestFlight/App Store Connect distribution state or account-level backend configuration after the renewal. I have already checked the builds and TestFlight configuration, but the issue still persists. Has anyone experienced the same issue after renewing their Apple Developer Program membership? If so, were you able to resolve it, and did Apple Support have to fix something on the backend? Any guidance or suggestions would be greatly appreciated.

I'm angry — Apple’s support has been awful. I’ve been trying to get help from Apple for two weeks. Their replies feel canned and automated (they even sign with a first name only), and they only provide basic information that doesn’t address the problem. You put in a response and then a week later, some canned response comes back from someone with a single name (Lisenga) I’m now faced with two unacceptable options: stop supporting Apple Safari users or delete my account and start over. Both options punish my users. For a multi-billion-dollar company, Apple’s support is shockingly limited. I ran this issue past ChatGPT Codex, and it confirmed that this is something only Apple can fix. Recent Apple Developer Forum posts describe Xcode Cloud / App Store Connect requests returning null responses because backend team permissions were broken. One post even referenced a case where Apple confirmed the only remedy was an internal fix on their side. To be clear: I am NOT using Xcode. I’ll say it again in case it was missed: I am not using Xcode. Here’s what happens: In App Store Connect, when I click the Xcode Cloud link it prompts me to “upload archive file.” When I upload, I immediately get “Failed to Fetch.” This happens in Safari, Chrome, and Firefox, in normal and private windows. It happens on a different computer 400 miles away as well. My suspicion is this: if a build is created before agreeing to the developer agreements, and the agreements are answered afterward, the system goes out of sync and breaks — a problem that only Apple can resolve. How do you actually talk to a real human at Apple??

Hi Apple DTS and community, My developer account's app has been granted the Default Mail App managed capability (com.apple.developer.mail-client). The capability works for Development and App Store Connect distribution, but it is not enabled for Ad Hoc distribution. This prevents us from using our Xcode Cloud “Archive & TestFlight” workflow: The archive succeeds. Development and App Store Connect exports succeed. Xcode Cloud then automatically attempts an Ad Hoc export. The Ad Hoc export fails, causing the entire archive action to fail and the TestFlight post-action to be skipped. The export log reports: Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. We have reproduced this in two consecutive Xcode Cloud runs. We also confirmed that: The App ID has the Default Mail App capability enabled. The entitlement is present and correctly spelled in the app’s entitlements file. The App ID’s provisioning support lists Development and App Store Connect, but not Ad Hoc. Our Xcode Cloud workflow does not expose an option to disable the automatically attempted Ad Hoc export. This appears to match these previous reports: https://developer.apple.com/forums/thread/774506 — a DTS engineer enabled Ad Hoc support for the entitlement, after which the developer confirmed the issue was resolved. https://developer.apple.com/forums/thread/800072 — DTS confirmed that the Ad Hoc distribution option must be enabled for the Default Mail App managed capability. We also opened an Apple Developer Support case (102945477410). Developer Support directed us to the forums and indicated that this issue would need to be handled by DTS engineers. I can provide our Team ID, Developer Support case number, Xcode Cloud run identifiers, and any other account details privately if needed. Thank you!

I use Xcode Cloud with my Github repo to automatically trigger workloads any time I create a new PR or make changes to the PR. This has been working for a few years now but this week it stopped working from one day to the next with no explanation. If I trigger the workflow manually via Builds > Start Build > my PR build workflow, and selecting my Pull Request from the list. This means that Xcode Cloud has access to my Github account, it's not an auth issue or anything like that. The only thing that doesnt work is the auto detection of when a PR is created or updated.

所请求的app不可用或者不存在

Hi, I am curious about why don't you provide an arm64 version of homebrew to your developers. To install arm64 homebrew in xcodecloud requires to compile packages from source. After 35 minutes still running ci_scripts/ci_post_clone.sh to install some packages: arm-brew install coreutils arm-brew install bash awk grep cat arm-brew install make arm-brew install gnu-tar gzip bzip2 xz arm-brew install automake autoconf m4 libtool arm-brew install llvm arm-brew install perl perl-build pod2man python3 meson ninja sqlite libtasn1 openssl libiconv gettext Further I need continues integration to build universal binaries and libraries. Maybe run the integration test suite, too. I think xcodecloud should provide arm64 and x86_64 versions of homebrew. Please consider this change.

I was previously able to test my app on Xcode 27 / iOS 27 by setting the Xcode Version to "Latest beta or release". I needed this to test PrivateCloudCompute on my apps in TestFlight. As of a few days ago this stopped working and only shows the stable 26 release, which removes PCC and my ability to test it. Am I doing something wrong? I didnt change any settings, I just noticed PCC wasnt working, checked the workflow and noticed that it no longer shows Xcode 27.

My app has been sitting in Beta App Review for an extended period with no update. I opened a support ticket through the developer contact form and never received a response. I also called Apple Support through the consumer line, but they weren't able to access developer/App Review case details and redirected me back to the same channel that already isn't responding. Has anyone else run into a review request that stalls with no reviewer feedback and no response to a filed ticket? Looking for: Any way to escalate beyond the standard contact form Typical wait times others have seen for a stuck Beta App Review before it's worth re-submitting a new build vs. waiting Whether there's a different queue/contact specifically for TestFlight (as opposed to full App Store review) Appreciate any pointers.

I've been getting intermittent failures on Xcode code compiling my app on multiple platforms because it fails to compile a metal shader. The Metal Toolchain was not installed and could not compile the Metal source files. Download the Metal Toolchain from Xcode > Settings > Components and try again. Sometimes if I re-run it, it works fine. Then I'll run it again, and it will fail. If you tell me to file a feedback, please tell me what information would be useful and actionable, because this is all I have.

Hi, My full build with all dependencies takes approximately 2 hours plus about 1 hour to run integration tests. Sorry 120 minutes build timeout is too short. Is there a way to adjust build timeouts? by Joël

I'm trying to start using Xcode Cloud from a project, but the only thing I get is the message saying "Failed to create workflow" with the actual error being "Could not find item. Domain: XcodeCloudKit.XcodeCloudCommandHandler.CommandHandlerError Code: 5". Initially, it did lead me to configuring permissions on GitHub. But it failed in the end probably because the git remote of the project was pointing to another organisation, that transferred the ownership to me. I switched remote to my org, but it didn't help. So, I revoked the permission and deleted Xcode Cloud app from my GitHub in hopes that the config process would start again. It does not. All I get is this senseless error. Is Xcode Cloud functionality functioning at all in Xcode beta 27 for anyone?