Xcode project integration support
Nobody has claimed this yet.
- Dominant language
- Swift
- Stars
- 43
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Description
Problem
ImplicitsAnalysisPlugin currently only works with SPM packages. Native Xcode projects (.xcodeproj) are not supported because:
- The plugin only implements
BuildToolPlugin, notXcodeBuildToolPlugin XcodePluginContexthas fundamentally different API — noPackage, no dependency graph traversal- No way to automatically discover which targets depend on Implicits or locate their
.implicitinterfacefiles
Possible Approaches
Option A: XcodeBuildToolPlugin
Implement the XcodeBuildToolPlugin protocol.
Challenges:
- No dependency graph — need alternative way to discover dependencies
- Could require a config file (e.g.,
implicits.json) listing dependent modules - Need to figure out where Xcode places plugin outputs to calculate interface paths
Option B: External CLI Tool
Standalone tool that:
- Parses
.xcodeprojusing XcodeProj library or similar - Discovers targets and their dependencies
- Adds build phases or generates scripts for each target
- Manages
.implicitinterfacefile locations
Pros: Full control over xcodeproj structure, can automate setup
Cons: Complex setup, requires xcodeproj parsing, user must run tool after project changes
Option C: Build Rules + Run Script
Use Xcode's built-in mechanisms:
- Add Run Script build phase that invokes
implicits-tool - User manually configures input/output paths
- Cross-target dependencies handled via explicit configuration
Pros: No plugin needed, works with any Xcode version
Cons: Manual setup per target, error-prone
Option D: SWIFTC Wrapper
Intercept the Swift compiler via SWIFT_EXEC build setting:
- Set
SWIFT_EXECto point to a wrapper script/binary - Wrapper receives all source files for the module (Swift compiles whole modules)
- Wrapper runs implicits-tool analysis
- Wrapper calls the real swiftc with original arguments
Pros:
- Automatic once configured — no per-target build phases needed
- Gets complete module compilation context
- Minimal project modification (one build setting)
Cons:
- Need to correctly pass through all swiftc flags
- Need to locate .implicitinterface files from dependencies
- May break with Xcode/toolchain updates if argument format changes
- Debugging compilation issues becomes harder (extra indirection layer)
Research Needed
- Explore
XcodePluginContextAPI limitations in detail - How do similar tools (SwiftLint, Sourcery) handle Xcode integration?
- Can Build Rules provide enough info for cross-target analysis?
- Evaluate xcodeproj parsing libraries (XcodeProj, etc.)
- Test
SWIFT_EXECapproach — what arguments does swiftc receive in Xcode builds?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No implementation file or test is named. Start by exploring the XcodePluginContext API and testing the SWIFT_EXEC approach, then compare XcodeBuildToolPlugin, an external CLI, build rules, and the wrapper approach. Done requires selecting a viable Xcode integration path and resolving its dependency discovery and .implicitinterface handling.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- build-system, devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100