Community Forums

Hey everyone,

I'm facing a common challenge in our rapidly growing iOS project: managing external dependencies. We've been using a mix of CocoaPods and direct Git submodule links, but it's becoming a nightmare. Version conflicts are frequent, updates are painful, and onboarding new developers takes forever because of the complex setup.

We're considering migrating to Swift Package Manager (SPM) for all our dependencies. Has anyone successfully made this transition for a large project? What were the biggest hurdles? Any strategies for handling dependencies that are not yet SPM-compatible?

I'm particularly interested in best practices for:

• Structuring SPM dependencies.
• Resolving transitive dependency conflicts.
• Integrating private dependencies.
• Automating dependency updates and checks.

Looking forward to hearing your experiences and advice!

Great question, John! We also went through this with our flagship app, which has over 100 external libraries. Migrating to SPM was a significant undertaking but ultimately paid off.

Biggest Hurdles:

1. Legacy Dependencies: The main pain point was dependencies that didn't support SPM. For some, we found forks that did, for others, we had to contribute SPM support upstream. A few we had to manually integrate as local packages or keep as Git submodules temporarily.
2. Build Times: Initially, SPM seemed to increase build times. This was often due to duplicated dependencies or inefficient package resolution. Ensure your dependencies are well-defined and you're not pulling in the same library multiple times through different paths.
3. Tooling & CI/CD: Integrating SPM into existing CI/CD pipelines required updates. We had to ensure our build agents could correctly resolve and fetch packages.

Strategies:

• Phased Migration: Don't try to migrate everything at once. Start with new dependencies or less critical ones.
• Dependency Management Tools: Consider tools like [Dependency Insights](https://example.com/dependency-insights) (hypothetical tool) to visualize your dependency graph.
• Automation: Use scripts to check for SPM compatibility, generate `Package.swift` files, and even automate PRs for dependency updates.

For private dependencies, SPM supports them directly via Git URLs or local paths, which is much cleaner than submodules.

I agree with Alice. SPM has been a game-changer for us. One thing to watch out for is the dependency resolution. Sometimes, SPM might pick a version that causes subtle bugs. Regularly testing your builds and running integration tests with different dependency versions can catch these issues early.

We found that explicit versioning in `Package.swift` (e.g., using exact versions or ranges like `1.2.3..<1.3.0`) is crucial. Avoid overly broad ranges unless you have a robust testing suite.

Has anyone used SPM for binary frameworks? We have some internal SDKs distributed as xcframeworks, and getting them integrated smoothly with SPM was a bit tricky.