Bundled SwiftPM scheme appears in consuming apps' Xcode scheme menus
- Dominant language
- Swift
- Stars
- 630
- Forks
- 26
- PR merge metrics
- No merged PRs in 30d
Description
Adding Semaphore as a Swift Package Manager dependency exposes its own `Semaphore` development/test scheme in the consuming app's Xcode scheme menu. I would expect the dependency to be available to build without adding its internal development scheme to that menu.
### Observed behavior
In **Product → Scheme → Manage Schemes**, the extra scheme has `Semaphore` as its container and is marked **Shared**. **Autocreate schemes** is disabled.
I have also seen unwanted dependency schemes return after unchecking **Show**. The exact event resetting that preference has not been isolated; the bundled scheme's presence is confirmed independently.
### Confirmed upstream file
[.swiftpm/xcode/xcshareddata/xcschemes/Semaphore.xcscheme at 0.1.0](https://github.com/groue/Semaphore/blob/2543679282aa6f6c8ecf2138acd613ed20790bc2/.swiftpm/xcode/xcshareddata/xcschemes/Semaphore.xcscheme)
This file is tracked in the released revision, exists in the downloaded package checkout, and remains on `main`. It references `Semaphore` and `SemaphoreTests`.
### Steps to observe the scheme
1. Add `https://github.com/groue/Semaphore` version `0.1.0` to an iOS app/workspace using Swift Package Manager.
2. Open **Product → Scheme → Manage Schemes**.
3. Observe the dependency's `Semaphore` scheme, even with **Autocreate schemes** disabled.
The later **Show** preference reset has not been reduced to a deterministic minimal reproduction.
### Suggested change and reference
Jesse Squires documents this packaging issue in [How to remove unwanted Swift Package schemes in Xcode](https://www.jessesquires.com/blog/2025/03/10/swiftpm-schemes-in-xcode/) (March 10, 2025). Xcode discovers schemes shipped in `.swiftpm/xcode/xcshareddata/xcschemes/`, and deleting those files locally is temporary because package refreshes/downloads can restore them.
Could this scheme be moved into a dedicated development `.xcworkspace` (updating development/CI references as needed), or otherwise kept out of the package-level location Xcode discovers in consuming projects? The article suggests that approach; I have not tested the migration for Semaphore.
### Environment
- Semaphore: 0.1.0
- Integration: Swift Package Manager
- Xcode: 27.0 (27A266a)
- Host OS: macOS 27.0
- Impact: recurring scheme-menu clutter in Xcode; no app execution is needed to observe it.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with .swiftpm/xcode/xcshareddata/xcschemes/Semaphore.xcscheme and inspect the development and CI references that currently depend on it. Compare the proposed dedicated development .xcworkspace approach with the package layout. Done means consuming projects no longer discover the internal Semaphore scheme while development and CI workflows still use it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- build-system, developer-experience
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100