How fast can an M4 Mac mini
build Swift?

19 seconds for Alamofire. Under a minute for SwiftLint.

The M4 compiled Alamofire's 44 pure-Swift source files in 19 seconds from a completely clean state. swift-algorithms finished in 14.5 seconds. Vapor, with its enormous dependency tree including BoringSSL's C++ sources and the entire SwiftNIO stack, completed 1,940 compilation steps in just over a minute.

Incremental builds are where it gets interesting. With no source changes, swift-algorithms re-checks in 0.38 seconds. Alamofire in 0.9 seconds. Even Vapor, with its massive dependency graph, verifies everything is current in about 3 seconds. Day-to-day development on the M4 is effectively instant.

Clean build from scratch, every file compiled.

Each project was cloned fresh with --depth 1, dependencies resolved, then built from a completely clean state using swift build.

Project	Build time	Files	Result
swift-algorithms	14.48s	40	✓ Pass
Alamofire	19.21s	44	✓ Pass
Vapor	64.40s	1,940	✓ Library compiled*
SwiftLint	67.92s	1,068	✓ Library compiled*

*Vapor and SwiftLint compiled all library code successfully. The overall build reported failure because their test-helper targets import XCTest, which requires full Xcode.app (we used Command Line Tools only). The compilation work and timings reflect real build performance.

The numbers tell a clear story. Small-to-medium Swift libraries compile in under 20 seconds. Large framework-scale projects with deep dependency trees and mixed Swift/C++ codebases finish in about a minute. That's roughly 30 compilation steps per second for Vapor.

Incremental builds are near-instant.

Immediately after the cold build, we ran swift build again with no source changes. This tests the build system's ability to skip unnecessary work.

Project	Cold	Warm	Speedup
swift-algorithms	14.48s	0.38s	38×
Alamofire	19.21s	0.90s	21×
SwiftLint	67.92s	1.29s	53×
Vapor	64.40s	3.07s	21×

SPM correctly determines that nothing needs recompilation and skips the work. The warm build is just the cost of walking the dependency graph and checking timestamps. For iterative development, this means your compile-run cycle on an M4 is effectively zero-wait for most projects.

SPM resolution is network-bound, not CPU-bound.

Before anything compiles, Swift Package Manager needs to fetch and resolve package versions. These times reflect a first-time clone with no local cache.

Project	Resolve time	Packages
swift-algorithms	1.7s	1 (swift-numerics)
Alamofire	13.8s	0 (standalone)
SwiftLint	23.9s	9 + binary artifact
Vapor	45.7s	27 packages

Vapor's 45.7 seconds reflects the reality of resolving a deep dependency tree with 27 packages including SwiftNIO, swift-crypto, and the full BoringSSL stack. SwiftLint's 24 seconds includes downloading a 70MB binary artifact. These are one-time costs; subsequent builds use the cached resolution.

A dedicated Mac is faster than you think.

On a shared CI runner, the SPM resolution and cold build overhead hits you on every run. On a dedicated Mac with a warm cache, your CI builds start from the incremental state. That Alamofire build drops from 19 seconds to under a second. Vapor goes from over a minute to 3 seconds.

For a team running 20+ builds a day, that adds up fast. And at £89/mo, a dedicated M4 Mac mini pays for itself in the first week compared to per-minute CI billing.

How we ran these benchmarks.

All benchmarks were run on a single Halfpenny Mac Pro-tier machine with the following specs:

• Chip: Apple M4 (10-core CPU: 4 performance + 6 efficiency)
• Memory: 16GB unified
• Storage: 512GB SSD (389GB available)
• macOS: 26.4 (Build 25E246)
• Swift: 6.3.2 (swiftlang-6.3.2.1.108)
• Toolchain: Command Line Tools 26.5

Each project was cloned with git clone --depth 1, resolved, then built twice (cold and warm) using swift build. Benchmarks were run on 2 June 2026. All repos were cleaned up after testing.