SwiftUI Pro: Paul Hudson's Free Agent Skill That Fixes What AI Gets Wrong in SwiftUI

Paul Hudson, the author behind Hacking with Swift, has a free agent skill that is climbing GitHub's trending list this week: SwiftUI Pro. It is a bundle of Markdown instructions that teaches AI coding agents such as Claude Code and Codex to review and write SwiftUI the way an experienced Apple-platform developer would, and the repository sits at roughly 5,200 stars and 190 forks under an MIT license. If you let an agent write your iOS or macOS interface code, this is a one-command way to catch the mistakes models repeat over and over.

The pitch is narrow and practical. Language models learned SwiftUI from years of tutorials, Stack Overflow answers and older code, so they reach for foregroundColor() instead of foregroundStyle(), forget accessibility labels, and put heavy work in view bodies. Hudson built the skill to target exactly those habits.

TL;DR

Why a SwiftUI-specific skill exists

Hudson explains the motivation in his launch article on Hacking with Swift. He has worked with SwiftUI since June 2019 and watched developers adopt patterns that "sometimes made buttons invisible to VoiceOver," used deprecated API without realizing, and accidentally wrote code that caused performance problems. When LLMs started writing SwiftUI, he says, they picked up the same anti-patterns.

He first wrote a long article on the biggest problems in AI-generated Swift code and converted it into an AGENTS.md file. The skill is the next step: it is "packed with everything from my original AGENTS.md file and a whole lot more." That lineage matters, because it tells you the rules come from a human reviewer's checklist rather than from a model summarizing documentation.

The idea fits a pattern we have covered before. A general agent is capable but forgetful about domain conventions, so you hand it a focused instruction pack. Our complete guide to agent skills explains the format, and Matt Pocock's TypeScript skills are the closest sibling: a respected educator turning years of review habits into a skill that loads only the parts a task needs.

How to install SwiftUI Pro

The repository README gives two routes. The universal one uses the skills installer:

npx skills add https://github.com/twostraws/swiftui-agent-skill --skill swiftui-pro

The installer lets you pick which agents to target and whether the skill is scoped to one project or available everywhere. If npx is missing you need Node, which the README suggests installing through Homebrew. Our walkthrough of installing Claude Code skills with npx covers the same flow in more depth, including what ends up in your skills folder.

Claude Code users can skip npm and use the plugin marketplace:

/plugin marketplace add twostraws/SwiftUI-Agent-Skill
/plugin install swiftui-pro@swiftui-agent-skill

To run it, type /swiftui-pro in Claude Code or $swiftui-pro in Codex. You can narrow the pass, for example /swiftui-pro Check for deprecated API or $swiftui-pro Focus on accessibility. Natural language also works: "Use the SwiftUI Pro skill to look for performance problems in this project."

If you work inside Xcode's agent integration, Hudson published a separate video on installing and using agent skills in Xcode, linked from the README.

What the skill actually checks

A reviewer pair marking a sheet with a green check, illustrating a SwiftUI agent skill review pass

The core of the skill is the SKILL.md file in the swiftui-pro folder. Its instructions open with a restraint rule: "Report only genuine problems – do not nitpick or invent issues." That is a deliberate guard against the failure mode where a review agent invents findings to look useful.

The review runs through a fixed sequence, each step backed by a reference file:

A twelfth file, references/performance-plus.md, is kept out of routine reviews. It is loaded for a requested deep performance review or to investigate an established performance problem. When you ask for a partial review, only the relevant reference files are loaded, which keeps token use down.

Concrete examples from Hudson's article

Hudson lists a few of the rules to show the flavor:

• Avoid foregroundColor(), avoid concatenating Text with +, and stay away from ObservableObject unless it is strictly required.
• Avoid doing view work in initializers or body properties, and break up views to get the most from the @Observable macro.
• Label every control, keep touch targets large enough, and make sure fonts scale.
• Prefer localizedStandardContains(), and prefer count(where:) over filter() followed by count.

The SKILL.md includes a worked output example. A review of ContentView.swift flags an icon-only button that VoiceOver cannot describe and shows the fix, from a bare image button to Button("Add User", systemImage: "plus", action: addUser). It also flags a hand-built Binding(get:set:) in a view body and suggests binding to the property directly with onChange() handling the side effect.

Short text lines flowing into a speaker, representing VoiceOver accessibility checks in SwiftUI Pro

The accessibility angle

Accessibility is the rule family most worth the install for many teams. A model that generates an icon-only button with no label produces code that compiles, passes a screenshot test, and fails a VoiceOver user. Because the skill always walks the accessibility file during a full review, that class of defect gets surfaced every time rather than only when someone remembers to ask. The same reference covers Dynamic Type and Reduce Motion.

What changed in version 2.0.0

The SKILL.md metadata lists version 2.0.0, and its core instructions are interesting because they encode current assumptions about the Apple toolchain. According to the file, iOS 27 exists and is the default deployment target for new apps, Xcode 27.1 and the matching platform releases are available, and the skill should "target Swift 6.4 or later, using modern Swift concurrency." It describes iPhone Duo as a folding iPhone with a small outer display and a large inner display, and it has a resizability reference for layouts on that hardware.

Two guardrails keep the skill from being reckless with those assumptions. It tells the agent to check the project's deployment target before applying version-specific advice and to use newer runtime APIs only when the target supports them or inside an #available check. It also says not to change the existing target, and notes that requirements tied to an Xcode version need that toolchain, because a runtime check cannot make an older SDK recognize a new declaration.

Other defaults are opinionated: avoid UIKit unless requested, do not add third-party frameworks without asking, split types into separate Swift files, and organize folders by feature. If those do not match your project, edit the skill. It is your copy once installed.

What people are asking

Is this just an AGENTS.md file?

Not quite, though it grew out of one. An AGENTS.md file is always in context, so every line costs tokens on every request. A skill loads on demand and can split guidance into reference files, so the agent reads only what a task needs. For the trade-offs, see our comparison of CLAUDE.md, SKILL.md and MCP and the guide to skills versus hooks versus prompts.

Will it make the agent write better SwiftUI, or only review it?

The description says it is for "reading, writing, or reviewing SwiftUI projects," so the rules apply while generating code too. The instructions add a nuance: during feature work or bug fixes, the agent should finish the requested change and suggest unrelated modernization separately. That prevents a small bug fix from ballooning into a sweeping diff.

How does it compare with building iOS apps with Codex?

They solve different problems. Our guide to building iOS SwiftUI apps with OpenAI Codex is about the agentic workflow end to end: project setup, simulator loops, iteration. SwiftUI Pro is a quality layer you can add to that workflow, or to a Claude Code session, so the code the agent produces is more modern and more accessible. They stack.

What are the downsides?

• Token cost. The README says plainly that there is a token cost, particularly for SKILL.md. A full review loads many files.
• Opinionated defaults. Avoiding UIKit and third-party frameworks will not suit every codebase.
• Moving target. The skill assumes recent OS and Swift versions. If your deployment target is older, rely on the instruction to check the target first, and verify suggestions compile.
• No guarantee of correctness. It improves the odds, not the certainty. Build and test what the agent changes.
• Review, not enforcement. A skill is advice the model may follow imperfectly. For rules that must never be broken, pair it with a linter or a CI check.

Is it safe to install a skill from the internet?

Skills are instructions the agent will follow, which makes them a prompt-injection surface. This one is Markdown from a well-known author in a repository with a code of conduct and an MIT license. Even so, the habit worth keeping is to read the files, pin the source to the official repository, and scan third-party skills. See our look at NVIDIA's SkillSpector scanner for one way to do that.

How the contribution rules shape the skill

A document pinned beside a folder, representing the SwiftUI Pro instruction file and its reference folder

The README's contribution notes explain why the skill reads the way it does. Hudson asks contributors to keep Markdown concise because of the token cost, and to avoid repeating things LLMs already know, since that "burns tokens for no benefit." The focus is "edge cases, surprises, soft deprecations, and similar." All contributions must be MIT licensed.

That philosophy is a useful template if you want to write your own skill. Do not teach the model what it already knows; teach it what it reliably gets wrong. Our step-by-step guide to building your first agent skill walks through that process, and SwiftUI Pro is a good real-world example of the output: a short top-level file, a routing list, and detailed rules in separate references.

A provenance note

Hudson's launch article also touches on provenance. He writes that his earlier work was copied by someone else, and he presents the skill as offering "the guarantee that checks have not been stolen from other people." We only report what he wrote; we have not examined that dispute, and it does not change how the skill behaves. Provenance and licensing do differ between Swift-focused rule sets, so check them if you compare.

Hudson has also published sibling skills for SwiftData, Swift Concurrency and Swift Testing, listed in the README and collected in a Swift Agent Skills repository. If your project leans on those frameworks, they follow the same model.

Try it today: a practical routine

1. Install the skill for your agent of choice with the npx command.
2. Open an existing SwiftUI project and run a scoped review first, such as deprecated API only. It is cheap and the findings are easy to verify.
3. Run a full review on one feature folder and read the prioritized summary at the end.
4. Accept fixes in small commits so you can revert any suggestion that does not fit your deployment target.
5. Add accessibility checks to your definition of done, since that is where agent-written code most often fails silently.
6. Keep the deep performance reference for when Instruments shows a real problem.

If you build apps professionally, treat the skill like a reviewer on your team: useful, opinionated and occasionally wrong. The goal is not to remove your judgment but to stop paying for the same predictable mistakes in every pull request.

What this says about the skills ecosystem

SwiftUI Pro is a small project, but it shows where agent tooling is heading. The valuable assets are no longer prompts shared in chat threads; they are versioned, licensed, installable packages from people with real domain track records, distributed through registries and one-line installers. You can browse what exists in the explainx.ai skills directory, and our roundup of agent skill directories compares the places skills are published.

For Apple developers specifically, the takeaway is simple. The platform changes yearly, model knowledge lags, and a maintained skill is a cheap way to close that gap. Check the repository for updates before major Xcode releases, since the skill's assumptions about OS versions are baked into its instructions.

Related reading

• What are agent skills? The complete guide
• npx skills: installing Claude Code skills from a registry
• How to build your first agent skill, step by step
• Building iOS SwiftUI apps with OpenAI Codex
• Matt Pocock's TypeScript skills and progressive disclosure
• Skills vs hooks vs prompts: when to use each
• NVIDIA SkillSpector: scanning agent skills for risk

Sources: the SwiftUI-Agent-Skill repository, its SKILL.md, and Paul Hudson's launch article.

Star counts, versions and rules are accurate as of October 9, 2026 and may change as the repository is updated.