Decide when and how to bridge a macOS app from SwiftUI into AppKit. Use when implementing NSViewRepresentable or NSViewControllerRepresentable, accessing NSWindow or the responder chain, presenting panels, customizing menus, or handling desktop behaviors that SwiftUI does not model cleanly.
80
100%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
The canonical home for this skill is appkit-interop in openai/plugins
Use this skill when SwiftUI is close but not quite enough for native macOS behavior. Keep the bridge as small and explicit as possible. SwiftUI should usually remain the source of truth, while AppKit handles the imperative edge.
NSViewRepresentable when you need a specific AppKit view with lightweight lifecycle needs.NSViewControllerRepresentable when you need controller lifecycle, delegation, or presentation coordination.NSWindow, responder-chain, menu validation, panels, or app-level behavior.Name the capability gap precisely.
Pick the smallest boundary that solves it.
Keep ownership explicit.
Expose a narrow interface back to SwiftUI.
Validate lifecycle assumptions.
references/representables.md: choosing between view and view-controller wrappers, plus coordinator patterns.references/window-panels.md: window access, utility windows, and open/save panels.references/responder-menus.md: first responder, command routing, and menu validation.references/drag-drop-pasteboard.md: pasteboard, file URLs, and desktop drag/drop edges.Coordinator become an unstructured dumping ground.NSView or NSWindow instances globally without a strong ownership reason.swiftui-patterns, keep it there.Provide:
9d2bf09
Canonical home
since Jul 24, 2026
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.