Introducing SwiftFairy: Swift and SwiftUI code reviews for coding agents

Nil Coalescing now has an all-new Tools section on our website, where we'll be sharing tools we build to help with Swift and SwiftUI development. The first of these is SwiftFairy, a Mac app that runs a local MCP server, giving coding agents on-device review of Swift and SwiftUI code, with findings attached directly to the lines that need your agent's attention.

The SwiftFairy app showing the Proper SwiftUI, Performant Swift Charts and Modern Swift Scrolls with lifetime licenses, and a prompt to connect a coding agent to run a first review

Every finding SwiftFairy returns draws on the knowledge and expertise of Natalia and myself, from our books and blog posts to our years of working with Swift and SwiftUI, including Natalia's time on the SwiftUI team at Apple.

Over the last year, we have been trying to distill all of our knowledge into a form that agents can reliably call on. But LLMs are, by design, not very predictable. Knowledge provided up front is often forgotten by the time it's relevant, and agents rarely go back to retrieve more detail on their own.

SwiftFairy takes a different approach: running locally on your Mac, it exposes an MCP server that your agents send code to. SwiftFairy then uses static analysis to match patterns in the code that have known or potential issues, and flags them to your agent along with a description and examples of how to fix each issue.

Diagram of a coding agent sending code to review over MCP to SwiftFairy, which runs locally on the Mac, parses the code into a partial graph, matches it against known issue patterns and returns the code with a flagged line highlighted, along with guidance and code examples

Not only does this avoid relying on the agent to recall knowledge from thousands of tokens back in its context, but it also massively reduces overall token usage, as the agent only needs to review the knowledge where an issue has been flagged.

Codebase audit of the Breve app, where SwiftFairy flagged views built outside body, unstable model IDs and row closures reading values from outside the row, each linked to a file and line

The first finding in the code review of our coffee app Breve above shows something we noticed repeatedly in testing: the agent points out that its own AGENTS.md already tells it not to build views in computed properties or methods that return some View, yet the code still did. Agents regularly miss rules stated in their instructions and skills. Because SwiftFairy's checks are deterministic, matching the structural patterns of your code rather than relying on the agent to remember a rule, each finding gives the agent a much stronger signal than another skill to read.

SwiftFairy organises its knowledge into Scrolls, each covering a set of related APIs or a development domain with guidance, known issue patterns, and code examples. Our initial release includes three: Proper SwiftUI, Performant Swift Charts, and Modern Swift. Going forward, we will add Scrolls for domains such as layout and accessibility, and keep extending the existing ones as new content falls within their scope.

The Choose Your Scrolls onboarding screen in SwiftFairy, listing the Proper SwiftUI, Performant Swift Charts and Modern Swift Scrolls with their descriptions

The structural analysis of your code done by SwiftFairy works by parsing your code into a partial graph and then matching this graph against declarative patterns that indicate potential issues.

For example, agents commonly create List, LazyVStack, and LazyHStack containers that include a variable number of items on each iteration of the ForEach.

List {
    ForEach(walks) { walk in
        Text(walk.name)
        if walk.isShort {
            Text("Short walk")
        }
    }
}

Detecting this requires checking the top-level scope of the ForEach for a conditional branch, but also checking for Group containers and child views that emit a variable number of children as a group, such as:

List {
    ForEach(walks) { walk in
        WalkEntry(walk: walk)
    }
}

struct WalkEntry: View {
    let walk: Walk

    var body: some View {
        Text(walk.name)
        if walk.isShort {
            Text("Short walk")
        }
    }
}

Normally, SwiftUI can tell how many rows a List contains just by counting the items in the collection. When each item can produce a variable number of views, it has to evaluate the ForEach closure for every item before it can display anything, which makes long lists noticeably slower.

Each Scroll contains many patterns like this one, drawn from the issues we see frequently in real projects, and each finding comes with an explanation and example of how to address it.

You can download SwiftFairy today from our tools website. The app provides free access for 24 hours with no card details required, so please check it out and ask your agent to review your codebase with SwiftFairy.

You may be surprised by how many issues SwiftFairy flags to your agent.