The Invisible Formatting Problem
When multiple people contribute to a Swift package, indentation inconsistencies creep in. One contributor uses 4 spaces, another uses tabs, a third uses 2 spaces. Pull requests become noisy with whitespace-only changes, and the codebase drifts toward an inconsistent mess. The fix is a single file that takes 30 seconds to add.
The .editorconfig Standard
EditorConfig is a widely supported standard for defining coding style settings per project. Xcode respects .editorconfig files, so contributors automatically get the correct indentation settings when they open the project – no manual configuration, no documentation to read.
Here is the .editorconfig I recommend for every SwiftPM package:
root = true
[*.swift]
indent_style = space
indent_size = 3
[*.{yml,yaml,json}]
indent_style = space
indent_size = 2The 3-space indent for Swift is an intentional choice. It is less common than 2 or 4 spaces, but it hits a sweet spot: more readable than 2 spaces for nested closures, less wasteful of horizontal space than 4 spaces. Once you try it, the standard choices start to feel either too cramped or too spread out.
Why This Beats Global Settings
Every developer has their own Xcode indentation preferences configured globally. Without .editorconfig, those global settings apply to every project they open. This means a contributor with 4-space tabs will silently reformat code when they edit a file, even if the project convention is different.
With .editorconfig in the repository root, Xcode overrides global settings with the project-specific ones. Contributors do not need to change anything – it just works.
Adoption
Drop this file in your package root and commit it. That is all. There is no build step, no dependency, no configuration beyond the file itself. Most modern editors (VS Code, Vim, Sublime Text) also support EditorConfig, so non-Xcode contributors benefit too.
