Appkit Interop

AppKit Interop

Quick Start

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.

Choose The Smallest Bridge

• Use pure SwiftUI when the required behavior already exists in scenes, toolbars, commands, inspectors, or standard controls.
• Use NSViewRepresentable when you need a specific AppKit view with lightweight lifecycle needs.
• Use NSViewControllerRepresentable when you need controller lifecycle, delegation, or presentation coordination.
• Use direct AppKit window or app hooks when you need NSWindow, responder-chain, menu validation, panels, or app-level behavior.

Workflow

1. Name the capability gap precisely.

• Window behavior
• Text system behavior
• Menu validation
• Drag and drop
• File open/save panels
• First responder control

2. Pick the smallest boundary that solves it.

• Avoid porting a whole screen to AppKit when one wrapped control or coordinator would do.

3. Keep ownership explicit.

• SwiftUI owns value state, selection, and observable models.
• AppKit objects stay inside the representable, coordinator, or bridge object.

4. Expose a narrow interface back to SwiftUI.

• Bindings for editable state
• Small callbacks for events
• Focused bridge services only when necessary

5. Validate lifecycle assumptions.

• SwiftUI may recreate representables.
• Coordinators exist to hold delegate and target-action glue, not as a second app architecture.

References

• 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.

Guardrails

• Do not duplicate the source of truth between SwiftUI and AppKit.
• Do not let Coordinator become an unstructured dumping ground.
• Do not store long-lived NSView or NSWindow instances globally without a strong ownership reason.
• Prefer a tiny tested bridge over rewriting the feature in raw AppKit.
• If a pattern can remain entirely in swiftui-patterns, keep it there.

Output Expectations

Provide:

• the exact SwiftUI limitation being crossed
• the smallest recommended bridge type
• the data-flow boundary between SwiftUI and AppKit
• the lifecycle or validation risks to watch

Drag, Drop, and Pasteboard

Intent

Use this when desktop drag/drop or pasteboard behavior exceeds what plain SwiftUI modifiers cover comfortably.

Good fits

• File URL dragging
• Pasteboard interoperability with other macOS apps
• Rich drag previews or AppKit-specific drop validation
• Legacy AppKit views with custom drag types

Core patterns

• Start with SwiftUI drag/drop APIs when they already cover the use case.
• Drop to AppKit when you need NSPasteboard, custom pasteboard types, or older AppKit delegate flows.
• Keep data conversion at the boundary instead of leaking AppKit types through the whole feature.

Pitfalls

• Do not move your whole list or canvas into AppKit just for one drop target.
• Keep file and pasteboard types explicit and validated.

Representables

Intent

Use this when wrapping an AppKit control or controller for a SwiftUI macOS app.

Choose the wrapper type

• Use NSViewRepresentable for a view-level bridge such as NSTextView, NSScrollView, or a custom AppKit control.
• Use NSViewControllerRepresentable when you need controller lifecycle, delegate coordination, or AppKit presentation logic.

Skeleton

struct LegacyTextView: NSViewRepresentable {
  @Binding var text: String

  func makeCoordinator() -> Coordinator {
    Coordinator(text: $text)
  }

  func makeNSView(context: Context) -> NSScrollView {
    let scrollView = NSScrollView()
    let textView = NSTextView()
    textView.delegate = context.coordinator
    scrollView.documentView = textView
    return scrollView
  }

  func updateNSView(_ nsView: NSScrollView, context: Context) {
    guard let textView = nsView.documentView as? NSTextView else { return }
    if textView.string != text {
      textView.string = text
    }
  }

  final class Coordinator: NSObject, NSTextViewDelegate {
    @Binding var text: String

    init(text: Binding<String>) {
      _text = text
    }

    func textDidChange(_ notification: Notification) {
      guard let textView = notification.object as? NSTextView else { return }
      text = textView.string
    }
  }
}

Pitfalls

• Avoid infinite update loops by only pushing state into AppKit when values actually changed.
• Keep delegates and target-action wiring in the coordinator.
• If the wrapper grows into a full screen, re-evaluate the boundary.

Responder Chain and Menus

Intent

Use this when command handling depends on the active window, first responder, or AppKit menu validation.

Core patterns

• Start with SwiftUI commands, FocusedValue, and focused scene state.
• Use AppKit responder-chain hooks only when command routing or validation truly depends on the underlying responder system.
• Keep menu enablement rules close to the state they depend on.

Good fits for AppKit

• Validating whether a menu item should be enabled
• Routing actions through the current first responder
• Integrating with existing AppKit document or text behaviors

Pitfalls

• Do not recreate AppKit-style global command handling when SwiftUI focused values would work.
• Avoid scattering command logic between SwiftUI closures and AppKit selectors without a clear boundary.

Windows and Panels

Intent

Use this when SwiftUI scenes are not enough for the required macOS window or panel behavior.

Common cases

• Accessing the backing NSWindow
• Configuring titlebar or toolbar behavior
• Presenting NSOpenPanel or NSSavePanel
• Managing utility panels or floating windows

Core patterns

• Prefer SwiftUI Window, WindowGroup, and openWindow first.
• Use AppKit only for window features SwiftUI does not expose cleanly.
• Keep file open/save panels behind a small service or helper instead of scattering panel setup throughout the view tree.

Example: open panel

@MainActor
func chooseFile() -> URL? {
  let panel = NSOpenPanel()
  panel.canChooseFiles = true
  panel.canChooseDirectories = false
  panel.allowsMultipleSelection = false
  return panel.runModal() == .OK ? panel.url : nil
}

Pitfalls

• Do not let random views own long-lived NSWindow references.
• Keep floating panels and utility windows consistent with the scene model.
• If the behavior is really just settings or a secondary scene, go back to swiftui-patterns.