Skip to content
Axint

swift-format integration

Axint can optionally pipe the generated Swift through Apple’s swift-format tool so your committed intents match the rest of your Swift codebase automatically.

Usage

Terminal window
axint compile intents/SendMessage.intent.ts --format

If swift-format is on your $PATH, the generated Swift is formatted in-memory before being written to disk. Cold format adds ~50ms on M-series.

If swift-format is not installed, --format logs a warning and writes the unformatted Swift. To fail loudly instead:

Terminal window
axint compile intents/SendMessage.intent.ts --strict-format

--strict-format implies --format. If swift-format is missing or errors, the build fails non-zero — useful in CI to guarantee formatted output.

The Axint house style

Axint ships a .swift-format config that gets used automatically. The highlights:

{
  "lineLength": 100,
  "indentation": { "spaces": 4 },
  "maximumBlankLines": 1,
  "respectsExistingLineBreaks": true,
  "rules": {
    "OrderedImports": true,
    "NoBlockComments": true,
    "NoLeadingWildcardImports": true,
    "UseLetInEveryBoundCaseVariable": true
  }
}

This matches Apple’s default recommendations with a few Axint-specific tweaks (slightly longer lines for generated code, enforced import ordering).

Why not format by default?

Two reasons:

  1. CI portability. Most CI setups run on Linux, where swift-format isn’t installed out of the box. Making it default would break green builds everywhere.
  2. Predictability. The unformatted output is already idiomatic. --format is a polish layer, not a correctness layer.

Once the WWDC 2026 sprint lands and Swift toolchain availability improves, we may revisit this default for macOS users.