Provision associated domains entitlement

[jdpy19]

What does this PR do?

Enables xtool to recognize and provision the com.apple.developer.associated-domains entitlement when generating development provisioning profiles. Adds regression coverage for capability mapping and plist encoding.

How was it tested?

• Ran swift test --jobs 2 --build-path /tmp/xtool-associated-domains-cli-build-4 --filter associatedDomainsEntitlementMapsToDeveloperCapability on Linux.
• The focused test passed.

AI tool usage

• 0 - No AI was used to write code
• 1 - I was assisted by AI. I reviewed the finished result.
• 2 - I set the AI going and left it to it; nobody has read the result - no review, or AI review only

Summary by CodeRabbit

• New Features
  • Associated domains entitlements are now supported when reading and encoding entitlements.
  • App capabilities are selected based on team type: free teams exclude capabilities marked as unavailable to them, while other teams include parsed entitlement capabilities.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 8a9a2012-b499-41db-803e-451cdb471d24

📥 Commits

Reviewing files that changed from the base of the PR and between d802c71 and d0475c2.

📒 Files selected for processing (2)

• Sources/XKit/Model/Entitlements/EntitlementTypes.swift
• Tests/XToolTests/AssociatedDomainsEntitlementTests.swift

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 7 remain after this review.

📝 Walkthrough

The entitlement container now supports AssociatedDomainsEntitlement. A test checks decoding, capability properties, and encoding of an associated-domains entitlement.

Changes: Associated Domains Entitlement

Layer / File(s)	Summary
Register and test associated-domains entitlements Sources/XKit/Model/Entitlements/EntitlementTypes.swift, Tests/XToolTests/AssociatedDomainsEntitlementTests.swift	AssociatedDomainsEntitlement is included in the supported types. The test checks its decoded value and properties, then verifies the encoded plist key and value.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Feature

Merge Risk: ⚪ Minimal · up to d0475

No actionable issue is identified; the change is ready for normal checks.

Pre-merge checks: 4

Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely describes the main change: enabling provisioning for the associated domains entitlement.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[rahul05ranjan]

Static review only — no Swift toolchain on my machine, so I traced the code paths rather than running anything.

The change is minimal — registering AssociatedDomainsEntitlement in supportedTypes (EntitlementTypes.swift:20) plus a regression test — but I checked what that registration actually unlocks, and it fixes a real gap:

• Before this, com.apple.developer.associated-domains fell through as an unrecognized key. Entitlements.entitlements() (Entitlements.swift:29-33) only returns parsed entitlements, so upsertApp's wantedCapabilities (DeveloperServicesAddAppOperation.swift:88) never saw it. The App ID then gets created without the ASSOCIATED_DOMAINS capability while the binary still carries the entitlement, so the dev profile doesn't grant it and installd rejects the install with the generic 0xe8008015. Presumably that's the user-visible breakage motivating this.
• The free-team path (DeveloperServicesAddAppOperation.swift:182) now filters it out via anyCapability?.isFree != false, consistent with isFree: false in the capability mapping (DeveloperServicesCapability.swift:82-86). That matches Apple requiring a paid membership for associated domains. For what it's worth, the pre-PR behavior there was coincidentally the same — the free path rebuilds from parsed entitlements only, so the unparsed key was dropped anyway — so no regression.
• The type was already fully wired up — identifier, [String] codec (EntitlementTypes.swift:87-100), and capability mapping — and .associatedDomains exists in the generated schema (DeveloperAPI/Generated/Types.swift:6743). Values pass through verbatim with no domain-format validation, which I'd say is fine since Apple validates at provisioning time.

Two things I'd like to see addressed before merge:

1. The line was commented out long before this repo existed — it predates the entitlements cleanup in #165 and even the libSupersign -> XKit rename, and NetworkExtensionEntitlement right below it is still disabled, which suggests these slots were commented out deliberately rather than left as TODOs. If there was a concrete reason (some API failure mode with the capability enabled), it would be good to confirm it no longer applies. The PR body doesn't mention it.

2. The test covers the registration round-trip well, but not the consumer paths that motivated the change: nothing asserts upsertApp's capability list picks it up, or that the free-team filter drops it. A small test on the isFree != false filter would lock in the free-account semantics — though I understand that needs API mocking and may belong elsewhere.

One ordering note with #324: its EntitlementsReconciler.knownKeys derives from EntitlementContainer.supportedTypes, so once this merges, associated-domains becomes a profile-checked entitlement there too. The two compose cleanly, but until #324 lands, nothing verifies the fetched profile actually grants this entitlement — relevant for App Store Connect API key sessions where capability creation can silently under-deliver (its doc comment mentions this for app groups).

[jdpy19]

Thanks for the careful review — both points are fair.

I checked the history, and AssociatedDomainsEntitlement has been commented out since the original Supersign implementation in 2019. I couldn’t find a commit message or issue documenting a specific failure mode. The entitlement type, codec, and capability mapping were already implemented, so this change only enables the existing path. I also confirmed that associated domains remain marked as non-free, so the free-team filter continues to exclude them.

I’ll add coverage for the capability list/filter behavior and document the historical context. The interaction with #324 also makes sense: once this is registered, its reconciler will recognize the entitlement when that change lands.