Modern enterprise iOS development often spans dozens of repositories with multiple app targets, shared frameworks, and utility libraries rather than a single monolithic codebase. This distribution of code can improve modularity and access control, but it introduces new challenges in dependency management and build coordination. Engineers frequently use Xcode workspaces to combine separate projects; for example, a shared framework in one repo can be added to the app’s workspace and referenced via cross-project references. However, as the number of repositories grows, teams must adopt robust strategies for sharing code, managing versions, and automating builds.

In an enterprise setting, an Xcode workspace might include an app target in one project and several library projects (each in its own Git repo). This setup lets the app link against each library’s products directly, but it requires careful configuration. For example, cross-project references must share a build directory and set up header search paths.

Apple’s documentation shows that if an app and framework are in separate projects, one can add the framework’s .xcodeproj file into the app’s workspace so that Xcode builds them together. This effectively treats separate repos as if they were part of a single workspace, but it scales poorly beyond a few projects.

Instead, many teams turn to package managers to tie multi-repo code together. Swift Package Manager (SPM) is now the default dependency mechanism in Xcode, and nearly all new Apple platform code is moving to Swift and SPM. In a Package.swift manifest, a team can declare an internal library by its Git URL and version. For example:

.package(url: "https://github.com/AcmeCorp/SharedComponents.git", from: "2.1.0")

This tells SwiftPM to clone the SharedComponents repo and use any tag ≥ 2.1.0 when building. SPM simply performs a git clone of the repository and checks out the specified tag or version, then builds the code along with the app. Because it fetches from Git, SPM has no single public registry; packages typically live on GitHub, GitLab, or a private server. Importantly, Apple introduced the Swift Package Registry (SE-0292) in Swift 5.7 (Xcode 14) to enable HTTP/HTTPS package hosting.

Enterprise teams can host their own Swift Package Registry (for example using Artifactory) to distribute packages without relying on Git tags. (As of 2025, Apple has not established a central public registry, so most companies either use direct Git references or set up an internal registry.)

At the same time, many existing projects still use CocoaPods for modular code. The CocoaPods central Trunk is being retired (Trunk will become read-only in late 2026), so enterprises must either proxy it or move to private pods. For example, JFrog Artifactory can host private CocoaPods specs and even cache the old public Trunk, ensuring builds still work.

In practice, some organizations maintain a private Specs repo or use a binary artifact repository (CocoaPods still works by downloading a .podspec and integrating the source, so it’s similar to SPM in concept). However, new internal libraries are typically published as Swift Packages. An internal package release might be a Git tag like v1.3.0 on GitHub, or it might be a prebuilt XCFramework distributed via HTTP (more on that below).

Dependency management in a multi-repo iOS ecosystem often involves a mix of strategies. Aside from SwiftPM and CocoaPods, some teams continue to use Carthage or manually embed static libraries. But the trend is clear that SwiftPM is de facto for new code. For example, if AppA in Repo A needs CoreUtility from Repo B, the developers might add Repo B’s Swift package to AppA’s Package.swift. The app target then simply imports CoreUtility in code. This is easier than the old Git submodule or custom script approach.

In fact, one developer recounts migrating internal libraries out of CocoaPods and Git submodules into a single repository using Swift packages, concluding that managing submodules was tedious and error-prone. Whether in a mono repo or multiple repos, the modularization hinges on the package format.

When modularizing, consider build time integration. A clean way is to use an Xcode workspace that contains multiple .xcodeproj or SPM package projects. Each target can declare dependencies either through workspace references or via the SwiftPM manifest.

For instance, an app target could list another project’s framework as a dependency by using a cross-project reference (by dragging the framework’s product into the Link Binary With Libraries phase). Alternatively, if using SwiftPM, the app simply depends on the package by name, and Xcode handles the linking.

In all cases, you must sync build settings to ensure the “Build Products Path” is consistent so that the framework’s binary is where the app expects it.

Beyond integration, a big part of scaling is automation. Continuous Integration pipelines must be able to check out code from multiple repositories. Most CI tools have ways to handle this. For example, GitLab CI/CD provides a CI_JOB_TOKEN which can be used to clone other private repos in a job script. A .gitlab-ci.yml might include:

script:
  - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/Org/SharedCore.git
  - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/Org/UtilityKit.git
  - xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -sdk iphoneos

With proper permissions, both repos are fetched automatically, and then Xcode builds everything together. Similarly, GitHub Actions can use multiple actions/checkout@v2steps with a Personal Access Token to get different repos in one job (one must ensure the token has access to all necessary repos). Bitrise workflows and Jenkins pipelines can also be set up to clone dependent libraries.

In Bitrise, a common pattern is to have separate workflows for each repository so a change in a library repo triggers a build that then uses the Bitrise Build Trigger API to start the main app’s build. That way, when RepoDependency is updated, it can programmatically invoke a build of RepoMain without mismatched commit hashes. The general idea is that CI must pass along version information (for example, passing the library commit SHA as an environment variable) so that the main build knows exactly which revision of the dependency to include.

In practice, teams often adopt a versioning policy for internal components. Each library repo might use semantic version tags and be published (or tagged) whenever a breaking or minor update occurs. The app’s CI can then pick up those tags. One advantage of SwiftPM in this context is that it will fetch the exact version tagged in the manifest; if no tag matches, it fails cleanly. This avoids a common pitfall of “latest version drift” that can happen with loose CocoaPods references or manual Git submodules.

Another strategy in large iOS shops is using binary frameworks. Instead of compiling a library’s source each time, the team builds an XCFramework once (for device and simulator slices) and distributes it. Apple officially supports distributing binary frameworks via SwiftPM. A Swift package can declare a binary target pointing to an XCFramework archive. For example, a Package.swift might contain:

targets: [
    .binaryTarget(
      name: "CorporateCore",
      url: "https://artifactory.corp.com/ios/CorporateCore-1.0.0.zip",
      checksum: "af3f2c..."
    )
]

Here CorporateCore is a prebuilt XCFramework packaged as a .zip. SwiftPM will download the ZIP (verified by checksum) instead of cloning a repo. Binary targets are useful for closed-source or heavy libraries, and they also speed up CI by avoiding a full Git fetch of large codebases.

As one blog notes, adding a binary target “can improve CI performance by reducing time spent on fetching SPM repositories.” In other words, the pipeline downloads only the binary artifact, which can be faster than cloning and building source.

However, binary frameworks do come with trade-offs. You lose the ability to step into their source during debugging, and you must rebuild the XCFramework when supporting new CPU architectures (e.g., adding Apple silicon slices). But for stable libraries, the faster turnaround can be worth it. Some teams use private artifact repositories (Artifactory, GitHub Packages, Amazon CodeArtifact, etc.) to host those zipped XCFrameworks or even raw .frameworkbundles.

For instance, JFrog’s Artifactory fully supports the Swift Package Registry protocol, so a team can publish versioned .zip artifacts that SPM fetches via HTTP. This essentially acts like a private CocoaPods Specs repo but for Swift packages and binaries.

In legacy codebases, teams might still deal with CocoaPods. For private pods, the Podspec file simply points to a Git URL and tag, similar to SPM. Example:

pod 'CoreSDK', :git => 'https://git.example.com/Enterprise/CoreSDK.git', :tag => 'v5.2.1'

Under the hood, this is akin to pulling from a private repo and integrating. But as mentioned, since the public CocoaPods repo is static, companies should mirror any critical pods internally or replace them with Swift packages.

Scaling also touches on project structure where many organizations debate mono repo vs multi-repo. In practice, iOS teams often use a hybrid approach where a primary app repository may contain several core modules (in subfolders or SPM packages) plus a suite of separate repos for cross-cutting concerns. For example, AppCore might live in the app repo itself, while AnalyticsSDK, AuthLibrary, and UIComponents each have their own repos and packages. This lets teams work autonomously on libraries without stepping on each other’s code. If ever needed, however, entire library histories can be merged into a monorepo using Git tools (as one engineer did with git filter-repo to preserve history). But merging histories is complex and usually only done when moving toward a full monorepo strategy.

Operating at scale also means coordinating updates. When a library changes, app teams need to bump the dependency. Good practice is to use pull requests; for example, after a library repo is updated and tagged, the app’s Package.resolved or Podfile is updated in a PR that cites the new version. Automated PR bots or continuous delivery tools can help here. For instance, some companies use bots that watch for new Git tags in library repos and then create PRs across all consuming apps to update their package versions.

Throughout this ecosystem, build consistency is key. Every app and library should specify the supported Swift version (often in an .swift-version file or swiftLanguageVersions in Package.swift). Similarly, unit tests and linting pipelines should run the same style rules and Swift compiler flags to avoid “works on my machine” discrepancies. Code signing and provisioning can be handled per app, but even those settings can be templated to reduce drift.

In summary, managing an enterprise-grade iOS codebase spread across multiple repositories demands disciplined use of Apple’s modularization tools and modern CI/CD practices. Swift Package Manager (often backed by private registries) is the linchpin of multi-repo dependency management, replacing older methods like CocoaPods or submodules.

Xcode workspaces and cross-project references still have a role for tightly coupled projects, but most shared code now comes in as Swift packages (either source or binary). Continuous integration orchestrates the fetching of all needed repos and runs unified builds and tests.

As the JFrog insight explains, SwiftPM’s Git based approach is powerful for sharing code, but enterprises greatly benefit from hosting their own package registry or binary artifacts to manage scale. By combining workspaces, Swift packages, and automated pipelines, large teams can keep dozens of iOS repositories synchronized and maintain reliable, repeatable builds.

Conclusion: At scale, a multi-repository iOS ecosystem is maintainable with the right tooling. Embrace Swift Package Manager for shared libraries, use Xcode workspaces for bundling related projects, and leverage private registries or CI tokens to streamline cross-repo builds. With these practices, enterprises can enjoy the flexibility of multiple repos without sacrificing consistency or developer productivity. The result is a modular, scalable architecture where new features and libraries can be developed in isolation but assembled reliably into production apps.