How to handle all the core AppleEvents

You're right that SwiftUI covers oapp/rapp/odoc/quit natively, plus GURL via the .onOpenURL modifier. For the events you're asking about:

Open content — could you clarify which event you mean? If you're thinking of GURL (Open URL / "open this URL or content"), that's the onOpenURL path. If you mean something else (a custom ocon or app-specific event), let me know and I can answer specifically.

Print document (pdoc) — SwiftUI does not route this to NSApplicationDelegate.application(_:printFiles:withSettings:showPrintPanels:). I verified by sending osascript -e 'tell application "Test" to print POSIX file "..."' to test apps using both WindowGroup and DocumentGroup in macOS 26.4 — the delegate method never fired. So the standard delegate path is silent under SwiftUI.

The path that does work is registering directly with NSAppleEventManager. Install your handler in applicationWillFinishLaunching: (before any events arrive) and SwiftUI doesn't fight you for ownership:

@main
struct MyApp: App {
    @NSApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
    var body: some Scene {
        WindowGroup {  // or DocumentGroup
            ContentView()
        }
    }
}

class AppDelegate: NSObject, NSApplicationDelegate {
    func applicationWillFinishLaunching(_ notification: Notification) {
        NSAppleEventManager.shared().setEventHandler(
            self,
            andSelector: #selector(handlePrintEvent(_:replyEvent:)),
            forEventClass: AEEventClass(kCoreEventClass),
            andEventID: AEEventID(kAEPrintDocuments)
        )
    }

    @objc func handlePrintEvent(_ event: NSAppleEventDescriptor,
                                 replyEvent: NSAppleEventDescriptor) {
        // The direct object parameter holds the file(s) or document specifier:
        // event.paramDescriptor(forKeyword: AEKeyword(keyDirectObject))
        // …
    }
}

In the test, this handler received the event with the file URL properly extracted in the '----' (direct object) parameter — exactly what a traditional AppleEvent handler expects.

On the "without clashing with SwiftUI" concern: AppleEvent handlers register for specific (event class, event ID) pairs. Registering for aevt/pdoc doesn't conflict with the handlers SwiftUI installs for aevt/oapp, aevt/rapp, aevt/odoc, or aevt/quit — they're keyed on the 4-char codes and live separately. The same pattern works for any other event you want to handle traditionally: open content, application-specific events, custom suites, or anything not in the small set SwiftUI claims for itself.

If your "open content" event turns out to be one of those non-SwiftUI events, the same setEventHandler(..., forEventClass:andEventID:) approach will work — just substitute the right class and ID codes.