Add swift-format GitHub Action, config, and pre-commit hook

[Copilot]

Adds Apple's built-in swift-format (via xcrun swift-format) for code formatting, complementing the existing SwiftLint workflow.

• .swift-format — Config: 200-char line length, 4-space indentation
• .github/workflows/swift-format.yml — CI lint check on PRs (xcrun swift-format lint --strict -r -p .), runs on macos-latest
• git-hooks/pre-commit.swift-format — Formats only staged .swift files and re-stages them
• README.md — Added "Development" section with hook install instructions

Pre-commit hook install

ln -sf ../../git-hooks/pre-commit.swift-format .git/hooks/pre-commit

Rollout note

Before the CI check will pass, the existing codebase needs a one-time formatting pass committed separately:

xcrun swift-format --in-place -r -p .

This should be a dedicated formatting-only commit to keep git blame clean.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add Github action to run SwiftFormat</issue_title>
<issue_description>Looking to add in SwiftFormat to the project: https://github.com/nicklockwood/SwiftFormat?tab=readme-ov-file#github-actions</issue_description>

Comments on the Issue (you are @copilot in this section)

@jjpritzl ## Proposal: Use Xcode's built-in `swift-format` instead of third-party SwiftFormat

Rather than pulling in a third-party tool, we can use Apple's swift-format that ships with Xcode — no extra dependencies needed. It's available via xcrun swift-format.

Recommended approach

Use both of the following together:

1. A local pre-commit git hook that auto-formats Swift files before each commit (fast developer feedback loop).
2. A GitHub Action that runs swift-format lint on PRs as a CI safety net.

Note: This complements the existing SwiftLint workflow — SwiftLint enforces style/linting rules, while swift-format handles code formatting. They work well side by side.

---

1. .swift-format config

Add a .swift-format file at the repo root. Here's a starting point — the team should discuss and customize values like lineLength:

{
  "version": 1,
  "lineLength": 200,
  "indentation": {
    "spaces": 4
  }
}

2. GitHub Action (CI safety net)

.github/workflows/swift-format.yml:

name: swift-format

on:
  pull_request:
    paths:
      - '.github/workflows/swift-format.yml'
      - '.swift-format'
      - '**/*.swift'

permissions:
  contents: read

jobs:
  swift-format:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lint with swift-format
        run: xcrun swift-format lint --strict -r -p .

3. Local pre-commit hook

git-hooks/pre-commit.swift-format:

#!/bin/bash
RED='\033[0;31m'
GREEN='\033[0;32m'
NC='\033[0m'

echo -e "${GREEN}Running swift-format...${NC}"

REPO_ROOT=$(git rev-parse --show-toplevel)
xcrun swift-format --in-place -r -p "$REPO_ROOT"
FAILED=$?

if [ $FAILED -ne 0 ]; then
    echo -e "${RED}Commit rejected: Swift formatting failed${NC}"
    exit 1
fi

echo -e "${GREEN}✓ Swift files were formatted${NC}"
exit 0

Install with:

ln -sf ../../git-hooks/pre-commit.swift-format .git/hooks/pre-commit

---

Rollout strategy

1. First commit — Run xcrun swift-format --in-place -r -p . across the entire codebase and commit the result as a single, dedicated commit containing only formatting changes. This keeps git blame clean.
2. Separate commit(s) — Add the .swift-format config, GitHub Action workflow, pre-commit hook, and any README updates in their own commit(s), separate from the formatting changes.

• Fixes Add Github action to run SwiftFormat #132

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[Copilot]

Pull request overview

Adds Apple’s built-in swift-format to the repository to enforce consistent Swift formatting locally (pre-commit) and in CI, complementing the existing SwiftLint workflow.

Changes:

• Add .swift-format configuration (line length + indentation rules).
• Add a GitHub Actions workflow to run xcrun swift-format lint on PRs.
• Add a pre-commit hook and document how to install it in the README.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
.swift-format	Defines swift-format formatting configuration used by local/CI runs.
.github/workflows/swift-format.yml	Adds CI linting step using xcrun swift-format lint --strict.
git-hooks/pre-commit.swift-format	Formats only staged .swift files and re-stages them.
README.md	Documents developer workflow for installing the pre-commit hook.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 24 out of 34 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (4)

Source/View Controllers/TCCProfileViewController.swift:1

• This file previously disabled SwiftLint file_length and that suppression was removed in this PR. With .swiftlint.yml now enforcing file_length error at 500 lines, this is likely to fail CI if the file remains over the limit. Either restore the per-file suppression (if acceptable), refactor/split the view controller into smaller components, or raise the file_length.error threshold to avoid breaking the existing SwiftLint workflow.
  git-hooks/pre-commit.swift-format:1
• The hook excludes renamed files (--diff-filter=ACM omits R), so a renamed Swift file (especially one renamed+modified) may skip formatting and then fail the CI swift-format lint --strict check. Consider including R in the diff-filter (e.g., ACMR) and avoiding newline round-tripping by keeping the file list null-delimited end-to-end (stream directly from git diff -z into xargs -0).
  git-hooks/pre-commit.swift-format:1
• The hook excludes renamed files (--diff-filter=ACM omits R), so a renamed Swift file (especially one renamed+modified) may skip formatting and then fail the CI swift-format lint --strict check. Consider including R in the diff-filter (e.g., ACMR) and avoiding newline round-tripping by keeping the file list null-delimited end-to-end (stream directly from git diff -z into xargs -0).
  git-hooks/pre-commit.swift-format:1
• The hook excludes renamed files (--diff-filter=ACM omits R), so a renamed Swift file (especially one renamed+modified) may skip formatting and then fail the CI swift-format lint --strict check. Consider including R in the diff-filter (e.g., ACMR) and avoiding newline round-tripping by keeping the file list null-delimited end-to-end (stream directly from git diff -z into xargs -0).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The file_length rule sets warning and error to the same threshold (500), which effectively removes the warning tier and can make violations immediately error-level. Consider setting warning < error (e.g., 500/700) or omitting warning if you want a single threshold.

Suggested change

	error: 500
	error: 700

[watkyn]

this does make sense. Let's make error 700. We can scale both of these numbers back later on as we get a handle on where the long files are.

[seth-w-gilbert]

Cool!

[watkyn]

this does make sense. Let's make error 700. We can scale both of these numbers back later on as we get a handle on where the long files are.

[jjpritzl]

@watkyn That file doesn't exist anymore, we deleted it because we don't need the SwiftLint stuff and have switched over to swift-format in this PR :D

[watkyn]

@watkyn That file doesn't exist anymore, we deleted it because we don't need the SwiftLint stuff and have switched over to swift-format in this PR :D

right!