16.2 · SPM, CocoaPods, Carthage and XCFrameworks, and shipping binaries

Where code comes from and in what form it arrives (source or binary) decides build time, reproducibility and how much you must trust a supplier.

Mental model. Prefer source dependencies resolved by a lockfile; use binaries when you must hide source, speed up builds, or ship to others, and then control exactly what they contain.

Package managers

SPM, CocoaPods, Carthage and how to choose.

1. How do Swift Package Manager, CocoaPods, Carthage and XCFrameworks compare, and how do you choose? 16.2.1 · L3
   Swift Package Manager (SPM) is Apple’s built-in tool and the default today: dependencies are declared in Package.swift (or added in Xcode), resolved from Git…

Binary frameworks

XCFrameworks, module maps and binary targets.

1. What is an XCFramework, what do module maps and library evolution have to do with it, and when do you use a binary target? 16.2.2 · L5
   A framework (or static library) built for one platform and architecture cannot run elsewhere: the device (arm64) and the simulator (arm64 and x86_64, a…

More in Modularization & SPM

• 16.1 · Targets, products, modules, and access across module boundaries
• 16.3 · Static and dynamic linking, duplicate symbols, and the dependency graph
• 16.4 · Build settings, configurations, xcconfig, and compile times
• 16.5 · Resource bundles, localisation in modules, and feature flags
• 16.6 · Multi-hour CI, affected-module builds, caching, and Tuist and Bazel
• 16.7 · Version rules, pins, conflicts, unsafe flags, mirrors and inspecting the graph
• 16.8 · Conditional settings, platform minimums, language modes, traits and plugins
• 16.9 · What really crosses a module boundary: inlinable bodies and imports