Optimizing Incremental Builds with SwiftLint Caching

The 29CM Mobile Team wanted to solve the problem where, as modularization progressed, SwiftLint ran on every build across all modules, eating into incremental build time. On M1-M3 Pro, SwiftLint alone took 15-30 seconds, which was a significant bottleneck felt in everyday coding workflow.

To address this, they restructured things to take advantage of the Based on dependency analysis option in Xcode Build Phase. The core approach had two parts:

• Creating an initial baseline xcfilelist
• Updating the target module's SwiftLint file list whenever files change

Based on a specific target, they compared the diff between the master branch and the current working directory, recording only the changed Swift files into the xcfilelist, and generated an empty output file so that Xcode wouldn't unnecessarily re-run the script repeatedly. They also added a script that finds every target's Project.swift and runs in parallel across as many processes as CPU cores, reducing the cost of updating.

They also used Build Pre-actions to configure each target's input file list to be updated before the build. As a result, in normal development SwiftLint no longer runs on most targets, and the pure execution time dropped to around 1-2 seconds.

However, the caching approach had a side effect: since linting doesn't run immediately, discovery of warnings or errors was delayed. To compensate, they introduced danger-swift and a GitHub Actions-based SwiftLint CI, building a separate lint pipeline that checks only the changed files.

As a result, they arrived at a structure that secures incremental build speed locally while strongly re-guaranteeing lint quality in CI. Beyond SwiftLint, similar optimizations can be attempted for other Build Phase tasks using xcfilelist, Build Pre-actions, and dependency analysis.