audit-swiftui-appkit-overuse

Audits macOS SwiftUI projects for unnecessary AppKit bridges that native SwiftUI APIs replace.

2|1|Updated Jun 7, 2026
One-click install
npx skills add https://github.com/yigitkonur/plugin-swiftui --skill audit-swiftui-appkit-overuse-yigitkonur
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: audit-swiftui-appkit-overuse
Source: https://github.com/yigitkonur/plugin-swiftui/tree/main/plugins/swiftui/skills/audit-swiftui-appkit-overuse
Command: npx skills add https://github.com/yigitkonur/plugin-swiftui --skill audit-swiftui-appkit-overuse-yigitkonur

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires ast-grep, and includes scripts (resource) and references (resource) components.

What problem does it solve? macOS SwiftUI codebases often accumulate unnecessary AppKit bridges (NSViewRepresentable wrappers, NSStatusItem, NSOpenPanel) when a native SwiftUI API already covers the same case, adding maintenance liability, responder-chain edges, and Swift 6 isolation boundaries. This Skill audits a project to decide whether each bridge should exist at all. ## Core Features & Use Cases - Overuse detection: Flags seven defect classes (over-01 to over-07), from representables wrapping 1:1 native controls like NSButton or NSSwitch, to NSStatusItem where MenuBarExtra fits, to NSGlassEffectView where SwiftUI glass applies. - Justified escape-hatch confirmation: Confirms warranted bridges (rich-text NSTextView below macOS 26, NSOutlineView, behind-window NSVisualEffectView) with a status: justified record so they are not churned away by later refactors. - Hybrid lint engine: Runs tier-1 grep tells plus a tier-2 ast-grep structural rule that proves a makeNSView actually constructs a native control, emitting unified JSON and SARIF. - Use Case: Point it at a macOS SwiftUI project and receive per-bridge findings written to swiftui-audits/appkit-overuse/, each with the native SwiftUI replacement, a real GitHub permalink example, and a Sosumi doc citation. ## Quick Start Audit my macOS SwiftUI project for unnecessary AppKit bridges and report which ones native SwiftUI APIs can replace.

Frequently Asked Questions about audit-swiftui-appkit-overuse

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find unnecessary AppKit bridges in a SwiftUI macOS app?

Run the audit on your SwiftUI sources; it locates every NSViewRepresentable, NSStatusItem, NSOpenPanel, and similar bridge via grep tells and an ast-grep structural rule, then applies a WHETHER test to decide if a native SwiftUI API covers the case at your deployment target.

When is an NSViewRepresentable justified instead of overuse?

A bridge is justified when SwiftUI has no native equal at your deployment floor: rich-text NSTextView below macOS 26, hierarchical NSOutlineView, NSTableView-grade data grids, behind-window NSVisualEffectView, or precise first-responder control. These are recorded as status: justified, never flagged.

Does this audit automatically rewrite or delete AppKit bridges?

No. The audit is flag-only by design because removing a representable is never mechanical. Each finding stays open with the native SwiftUI replacement shown as the correct pattern, backed by a real GitHub permalink and Apple documentation citation.

What replaces NSStatusItem and NSOpenPanel in SwiftUI?

MenuBarExtra (macOS 13+) replaces a hand-built NSStatusItem, and fileImporter/fileExporter/fileMover (macOS 11+) replace NSOpenPanel and NSSavePanel. Transferable with .draggable and .dropDestination replaces NSItemProvider-based drag and drop.

Why does the deployment target matter for this audit?

The deployment floor gates several verdicts: a rich-text NSTextView bridge is justified below macOS 26 but flaggable at or above it, and MenuBarExtra or fileImporter replacements require macOS 13 and 11 respectively. The audit reads MACOSX_DEPLOYMENT_TARGET before flagging anything.