Skip to content

Add Swift Package Registry (SE-0292) configuration support#1626

Open
bdolewski wants to merge 1 commit into
yonaskolb:masterfrom
bdolewski:add-swift-package-registry-config
Open

Add Swift Package Registry (SE-0292) configuration support#1626
bdolewski wants to merge 1 commit into
yonaskolb:masterfrom
bdolewski:add-swift-package-registry-config

Conversation

@bdolewski

Copy link
Copy Markdown

Motivation

Swift Package Registry (SE-0292) dependencies are resolved by SwiftPM through a registries.json configuration file. Xcode has no project-level (pbxproj) representation for registry packages, so today there is no way to make an XcodeGen-generated project resolve .package(id:) dependencies from a registry without hand-placing registries.json after every xcodegen generate (and re-placing it whenever the project is regenerated).

This PR lets XcodeGen own that configuration.

What it does

Adds a top-level registries key to project.yml:

registries:
  default: https://tuist.dev/api/registry/swift
  scopes:
    acme:
      url: https://packages.example.com/artifactory/api/swift/swift-registry
      supportsAvailability: false

XcodeGen serializes this into the generated project's project.xcworkspace/xcshareddata/swiftpm/configuration/registries.json in SwiftPM's schema (sorted keys, unescaped slashes, empty authentication, version: 1). A registry value may be a bare URL string or a { url, supportsAvailability } mapping.

Dependencies themselves are still declared the existing, supported way: a local Swift package whose Package.swift uses .package(id:), referenced from project.yml as a local: package. XcodeGen does not write registry references into the .xcodeproj, because Xcode has no pbxproj representation for them. Authentication credentials are never written (configure them via .netrc/keychain as usual).

Why not a pbxproj registry reference?

I verified on Xcode 26.5 that a project-level XCRemoteSwiftPackageReference with kind = registry is silently ignored by xcodebuild (resolves zero packages, no error), consistent with Apple Feedback FB14699700 ("not supported in Xcode directly"). The supported mechanism is registries.json plus SwiftPM resolution, which is what this PR generates.

Validation

  • swift test passes, including new parsing and serialization tests.
  • End to end: a generated iOS app consuming a dependency from the public Tuist registry (https://tuist.dev/api/registry/swift) builds with vanilla xcodebuild build -destination 'generic/platform=iOS Simulator' (BUILD SUCCEEDED); the dependency is fetched from the registry, not from git.

Changes

  • New registries project spec model with parsing and serialization.
  • FileWriter writes registries.json after the project is written (no-op when unset or unchanged).
  • Docs (Docs/ProjectSpec.md) and a CHANGELOG entry.

Notes

  • No breaking changes; registries is optional.
  • No new dependencies and no change to tuist/XcodeProj.
  • Possible follow-ups (separate PRs): mirrors.json generation; SCM-to-registry transformation scheme/build settings.

This change was developed with assistance from Claude Code (Anthropic). Happy to adjust the registries key name or shape to your preference.

🤖 Generated with Claude Code

Add a top-level `registries` key to project.yml. XcodeGen serializes it into the
generated project's `project.xcworkspace/xcshareddata/swiftpm/configuration/registries.json`,
the file SwiftPM and Xcode read to resolve registry (`.package(id:)`) dependencies.

Xcode has no project-level (pbxproj) representation for registry packages, so this
configuration file is the supported way to point a generated project at a registry.
Dependencies themselves are still declared the existing way, by referencing a local
Swift package whose Package.swift uses `.package(id:)`.

Includes parsing and serialization tests, ProjectSpec docs, and a CHANGELOG entry.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant