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?