appkit-interop

Use NSViewRepresentable for view-level bridges like NSTextView or NSScrollView, and NSViewControllerRepresentable when you need controller lifecycle or delegation. Keep delegate wiring in a Coordinator and only push state into AppKit when values actually change.

Choose NSViewRepresentable for a single AppKit view with lightweight lifecycle needs. Choose NSViewControllerRepresentable when you need controller lifecycle, delegate coordination, or AppKit presentation logic such as presenting sheets or managing child controllers.

Prefer SwiftUI Window, WindowGroup, and openWindow first. Use AppKit only for window features SwiftUI does not expose, such as titlebar configuration or utility panels, and avoid letting random views own long-lived NSWindow references.

Yes, present NSOpenPanel or NSSavePanel through a small helper or service rather than scattering panel setup across the view tree. A simple runModal call returning the selected URL keeps the boundary clean.

Update loops happen when updateNSView pushes state into AppKit unconditionally, triggering delegate callbacks that write back the same value. Guard updates by comparing the current AppKit value with the SwiftUI state before assigning.

Avoid AppKit when SwiftUI scenes, toolbars, commands, inspectors, or standard controls already provide the behavior. If a pattern fits entirely within SwiftUI focused values and commands, keep it there instead of recreating AppKit-style global handling.