Touch on Mac für Entwickler: 36 Punkte, Recognizer, Sidecar

Was ändert Touch auf dem Mac für Mac-Entwickler? Bestehende Apps funktionieren, weil „macOS automatically translates touches into clicks“ (macOS übersetzt Berührungen automatisch in Klicks), und drei Tech Talks liefern die Regeln: Gesture Recognizer sind „the only way to get direct touches on macOS“ (der einzige Weg zu direkten Berührungen unter macOS), Standard-Bedienelemente sind touch-nativ, das Touch-Ziel misst 36 Punkte, Hover hat keine Entsprechung, und ein iPad über Sidecar dient als Testgerät.¹²³⁴ Die Touch-APIs stecken bereits im macOS-27.0-SDK; die Schalter für Systemgesten und ein unter macOS verfügbares ActivityKit fehlen in den beiden SDKs, die ich geprüft habe, und die Xcode-27.3-Beta ist „Coming soon“.²⁵⁶⁷⁸

Kurzfassung: Apple hat Touch auf dem MacBook Pro with PROLED XDR Display angekündigt (14,2 und 16,3 Zoll, Vorbestellung ab 28. Oktober, im Handel ab 6. November) und Entwicklern am 28. Oktober in drei Talks erklärt, wie sie es übernehmen.¹²⁹ Nutzt Ihre App Standard-Bedienelemente von AppKit, SwiftUI-Gesten oder Mac Catalyst, sagt der Talk, dass sie „just work“ (einfach funktionieren), und das Audit weiter unten (Trefferflächen, Hover) gilt trotzdem. Eigener mouseDown(with:)-Code wird emuliert, bis er auf Control-Events oder Gesture Recognizer umgestellt ist, und ein UI-Framework, das nicht von Apple stammt, erhält eine generische Emulationsschicht, die NSIsTouchNative abschaltet, sobald die App Touch selbst verarbeitet.³⁶ Um in AppKit eine direkte Berührung zu empfangen, brauchen Sie einen Gesture Recognizer, denn Berührungen erreichen weder die Responder Chain noch Event-Monitore.³⁶ Der Design-Talk legt das Touch-Ziel auf 36 Punkte fest, dieselbe physische Größe wie 44 Punkte unter iOS, und sagt, dass macOS mit und ohne Touch gleich aussieht.⁴ Getestet wird mit einem iPad über Sidecar; die neuesten Bausteine sind macOS 27.2 und der Xcode 27.2 RC, eine Konfiguration, die ich nicht ausgeführt habe.³¹¹ Die Touch-APIs stecken bereits im macOS-27.0-SDK. Der Schalter für Systemgesten und ein unter macOS verfügbares ActivityKit fehlen in den beiden SDKs, die ich geprüft habe, und die Xcode-27.3-Beta ist „Coming soon“.²³⁷⁸

Was Apple veröffentlicht hat und was nicht

Apples Ankündigung war eine Pressemitteilung, keine Keynote; der Live-Beitrag dokumentiert den Tag. Der Entwicklerteil der Mitteilung besteht aus drei Sätzen im Abschnitt „Touch Arrives on Mac“: „Apple apps are optimized for the new MacBook Pro, and many existing apps work with Touch right away, because macOS automatically translates touches into clicks“, dann „Updated system gesture APIs also enable developers to create intuitive experiences designed specifically for Touch“ (aktualisierte APIs für Systemgesten ermöglichen Entwicklern außerdem, intuitive, eigens für Touch gestaltete Erlebnisse zu schaffen) und der Hinweis, dass „app developers can test how Touch performs in their iOS and iPadOS apps directly on the MacBook Pro display“ (Entwickler können direkt auf dem Display des MacBook Pro testen, wie sich Touch in ihren iOS- und iPadOS-Apps verhält).¹ Der Abschnitt zu macOS sagt, der Laptop „comes to life with macOS 27“, und nennt „Touch built for macOS 27“; ein Point-Release nennt er nicht.¹

Die Entwicklerseite war spätestens um 11:47 a.m. PT online: ein News-Beitrag, „Say hello to Touch on Mac“, und eine Landingpage, „Get ready for Touch on Mac“, mit drei Tech Talks, Group Labs am 18. und 19. November und drei Kacheln mit dem Vermerk „Coming soon“: „Xcode 27.3 beta“, „Documentation resources“ und „Design resources“.² Das HTML der Seite enthält die Links, die Apple an diese Kacheln hängen will, in Kommentaren, die zur Reaktivierung vorgemerkt sind, sobald die Ressourcen online gehen: einen AppKit-Artikel, „Adopting gesture recognizers in your app“, der heute 404 zurückgibt, das bestehende Beispiel für Drag and Drop mit File Promises und, unter seinen Links, vier Seiten der Human Interface Guidelines sowie Apple Design Resources; die erfassten HIG-Seiten enthalten keine Hinweise zu Touch auf dem Mac-Display, und das Änderungsprotokoll der Live-Activities-Seite endet am 13. Oktober.²⁷¹⁰

Die Primärquellen für die Regeln sind also die Talks und eine Technote, die Apple am 8. Juni veröffentlicht hat, „TN3212: Adopting gesture recognizers for Sidecar touch support“, deren Overview sagt: „In macOS 27, AppKit continues to standardize on gesture recognizers as the primary mechanism for input handling“ (in macOS 27 setzt AppKit bei der Eingabeverarbeitung weiter einheitlich auf Gesture Recognizer als primären Mechanismus), und deren Abschnitte „Explore updated APIs in macOS 27“, „Detect touch capability“, „Handle control events“ und „Configure scroll behavior“ die API-Oberfläche beschreiben, die die Talks vom 28. Oktober vorführen.⁶ Jedes neue Symbol, das die Technote nennt, steht in Apples Dokumentation mit introducedAt macOS 27.0 und ohne Beta-Kennzeichnung, abgerufen am 28. Oktober um 12 Uhr mittags PT, und ist, abgesehen von den beiden Info.plist-Schlüsseln, im macOS-27.0-SDK in Xcode 27.1 (27A9275) deklariert, geprüft in den Headern und Swift-Interfaces auf diesem Mac (Analyse des Autors).⁷ Für die drei Systemgesten-Symbole, die der Talk nennt, gilt das nicht, und ebenso wenig für ein unter macOS verfügbares ActivityKit; zu beidem weiter unten.

Nichts zu tun, und was Sie dafür bekommen

Die Kompatibilitätsgeschichte ist großzügig. Der AppKit-Talk beginnt damit: „The good news is that we’ve already made touch work great out of the box for all apps. Across our native frameworks, standard components just work with native touch. Existing gestures created in SwiftUI just work“ (0:30), und dasselbe gilt für Mac Catalyst (0:52).³ Für AppKit heißt es: „Standard buttons, controls, tables, collections, split views, tabs, scrolling, and more are all touch native“ (1:10).³

Was nicht nativ ist, wird emuliert: „for existing custom AppKit mouse interactions, or if you use non-Apple UI frameworks, AppKit intelligently emulates the mouse“ (1:17).³ Die Technote schlüsselt die Emulation für Frameworks von Drittanbietern auf: „A tap emulates a mouse-down followed immediately by a mouse-up“, „A touch and immediate pan emulates trackpad scroll events, even if the UI doesn’t respond to them“, „A long press without movement emulates a rightMouseDown(with:) (optionally followed by rightMouseDragged(with:)) with a rightMouseUp(with:) on touch lift“ und „A two-finger pinch or rotation simultaneously emulates both the trackpad magnify and rotate gestures“ (ein Tippen emuliert ein Mouse-down, unmittelbar gefolgt von einem Mouse-up; Berühren mit sofortigem Schwenken emuliert Trackpad-Scroll-Events, auch wenn die UI nicht darauf reagiert; langes Drücken ohne Bewegung emuliert ein rightMouseDown(with:), optional gefolgt von rightMouseDragged(with:), mit einem rightMouseUp(with:) beim Abheben des Fingers; ein Pinch oder eine Drehung mit zwei Fingern emuliert zugleich die Trackpad-Gesten zum Vergrößern und zum Drehen).⁶ Die Fassung des Talks: „a one-finger scroll with momentum, click, drag with a small hold delay, and even pinch for rotation and magnification“ (11:28).³ Die Emulation gilt pro Fenster und ist generisch, weil „AppKit can’t determine what kind of interactions are allowed at any particular location of your non-Apple UI framework content“ (11:17) (AppKit kann nicht erkennen, welche Interaktionen an einer bestimmten Stelle solcher Inhalte erlaubt sind).³

Wenn Sie native Unterstützung ergänzt haben, schalten Sie die Emulation ab: „add an NSIsTouchNative entry to your Info.plist to let AppKit know you are touch native and no longer need the non-Apple UI toolkit mouse emulations“ (11:47).³ Der Schlüssel ist als macOS 27.0 dokumentiert, und seine Seite sagt: „Most AppKit apps don’t need this key. It’s primarily intended for apps that embed a non-AppKit rendering or input framework and implement their own touch-handling pipeline.“⁷

Für die Frage, was „nichts zu tun“ optisch bedeutet, zählt die Rahmung des Design-Talks: „macOS on a device that supports touch doesn’t look any different than macOS on a device that doesn’t. The resolution, the size of windows, text and UI controls haven’t changed“ (0:41), und „Touch is a secondary input for macOS, and therefore has little impact on how macOS looks“ (1:06) (Touch ist unter macOS eine sekundäre Eingabe und hat daher wenig Einfluss darauf, wie macOS aussieht).⁴ Es gibt keinen Touch-Modus und kein kompaktes Layout. Das ist das Gegenteil der Lage beim iPhone Duo, wo das innere Display in beiden Dimensionen reguläre Size Classes meldet.

Gesture Recognizer sind der einzige Weg hinein

Der Satz, der alles Weitere ordnet, fällt bei 3:45 im AppKit-Talk: „In fact, gesture recognizers are the only way to get direct touches on macOS.“³ Davor: „Starting with macOS Golden Gate, gesture recognizers are the preferred approach in AppKit“ (3:33), und „gesture recognizers have become the shared input language across SwiftUI, Mac Catalyst, and now AppKit“ (3:38).³ Die Technote sagt dasselbe aus der anderen Richtung: „AppKit doesn’t deliver Sidecar touch events through the responder chain or through event monitors“, und in einem Hinweis: „Local and global event monitors don’t receive touch events. Touch events don’t go through NSApp or sendEvent(_:).“⁶

Für eine AppKit-Codebasis hat das drei Folgen.

Erstens: Tracking-Schleifen. Der Engineer im Talk baut ein Verkabelungspuzzle um, das „a custom NSView with a mouseDown(with:) override that uses the standard tracking loop technique“ (3:13) verwendete und nextEvent(matching:) bis zum Loslassen der Maustaste aufrief, und sagt: „Migrate your mouse tracking loops to gesture recognizers“ (3:51).³ Die Migration ist kein Alles oder Nichts: „tracking loops are still supported and can coexist with touch-only gesture recognizers. You may find that adding touch-only gesture recognizers is the fastest and least risky path for a dot release of your app“ (3:58) (Tracking-Schleifen werden weiterhin unterstützt und können neben reinen Touch-Recognizern bestehen; das Hinzufügen reiner Touch-Recognizer kann sich als schnellster und risikoärmster Weg für ein Punkt-Update Ihrer App erweisen).³ Der erste Schritt ist das Refactoring, das der Talk vornimmt, bevor er irgendetwas hinzufügt: „The first step is to refactor my tracking loop into separate start, continue, end, and cancel tracking functions“ (4:11), damit Mausschleife und Touch-Recognizer sie gemeinsam nutzen können.³ Apples Listing, wörtlich:

// Refactored tracking functions
func startTracking(at viewLocation: NSPoint) { /* ... */ }

func continueTracking(at viewLocation: NSPoint) { /* ... */ }

func endTracking(at viewLocation: NSPoint) { /* ... */ }

func cancelTracking() { /* ... */ }

Das Rezept für einen reinen Touch-Recognizer besteht dann aus zwei Property-Zuweisungen: „set the buttonMask to 0 and allowedTouchTypes to .direct on an initialized NSPanGestureRecognizer“ (4:29).³

// Add touch-only pan gesture recognizer
let touchRecognizer = NSPanGestureRecognizer(
    target: self,
    action: #selector(touchPan)
)

touchRecognizer.buttonMask = 0x0
touchRecognizer.allowedTouchTypes = .direct

wiringPanelView.addGestureRecognizer(touchRecognizer)

Die Action leitet die Zustände .began, .changed, .ended und .cancelled des Recognizers an die vier Funktionen weiter. Den Grund für den Abbruchpfad nannte der Talk schon beim Button: „If tracking is canceled due to a system gesture like Exposé, scroll, or any other reason, I can revert any unintended changes“ (2:41) (wird das Tracking durch eine Systemgeste wie Exposé, durch Scrollen oder aus einem anderen Grund abgebrochen, kann ich ungewollte Änderungen zurücknehmen), und die Regel der Technote lautet „Handle cancellation“.³⁶

// Pan gesture recognizer action function
@objc func touchPan(_ recognizer: NSPanGestureRecognizer) {
    switch recognizer.state {
    case .began:
        startTracking(at: recognizer.location(in: wiringPanelView))
    case .changed:
        continueTracking(at: recognizer.location(in: wiringPanelView))
    case .ended:
        endTracking(at: recognizer.location(in: wiringPanelView))
    case .cancelled:
        cancelTracking()
    default:
        break
    }
}

NSPanGestureRecognizer stammt aus macOS 10.10 und allowedTouchTypes aus 10.12.2; nichts an diesem Rezept ist neu.⁷

Zweitens: die Regeln, die Recognizer mitbringen. Die Technote: „If your view is covered by another, often transparent, view, your gesture recognizer won’t be triggered“ und „You can’t place views on top of standard framework controls, because those controls now use gesture recognizers internally“, dazu ihr eigener Ausweg: „If necessary, rearrange the siblings, or override the occluding view’s hitTest(_:) method and return nil to ensure it doesn’t block events going to underlying controls.“⁶ Ein eigener Recognizer muss zu einem Ende kommen: „End your active gesture recognizer by transitioning to ended, failed, or cancelled. If you don’t, recognizers are blocked from activating.“⁶ Hinzu kommt eine Verhaltensänderung, die nur Unterklassen betrifft, die mit dem neuen SDK gebaut werden: „In apps built with the macOS 27 SDK and Xcode 27, location(in:) on NSGestureRecognizer returns NSZeroPoint and logs an error if the receiver’s class doesn’t override the method“, weil „Subclasses of NSGestureRecognizer must implement location(in:) to report a meaningful location“.⁶

Drittens: was Sie verlieren. Bei Control-Actions sagt die Technote, der Wechsel zu Recognizern in NSControl „changes the timing of when AppKit delivers control action messages with respect to event processing“, sodass currentEvent „no longer returns the event that triggered an action“; sie verweist stattdessen auf NSEvent.pressedMouseButtons und das klassenweite modifierFlags und ergänzt, dass „a touch is not part of pressedMouseButtons“.⁶ Und eine Unterklasse, die eine Methode für die linke Maustaste überschreibt, zahlt dafür: „If you subclass an AppKit control and override any of the left-mouse responder methods, that control falls back to a tracking loop path for compatibility.“⁶

Bedienelemente: Events statt mouseDown

Das erste Refactoring im AppKit-Talk betrifft einen Button. Das Original leitete von NSButton ab und überschrieb mouseDown(with:), um zu erfahren, wann das Tracking begann und endete; unter Touch „the buttons work, but AppKit must emulate mouse events to pass to the mouseDown override“ (2:17).³ Der Ersatz sind NSControl-Events „directly on NSButton without the need to subclass“ (2:27); das Listing der Talk-Seite bei 2:24 registriert am Button drei Aufrufe von addTarget(_:action:for:), für [.trackingBegan, .trackingEntered], [.trackingExited, .trackingEndedInside] und .trackingCancelled, und die Events machen auch den Zustand sichtbar, den ein Maus-Override nie gesehen hat: „If tracking is canceled due to a system gesture like Exposé, scroll, or any other reason, I can revert any unintended changes“ (2:41).³ Die Events sind alt: „NSControl events are available for standard AppKit controls, and most control events are available all the way back to macOS 11“ (2:51).³ Für das Muster verweist der Talk auf die WWDC26-Session, die er „Modernizing your AppKit app“ nennt; die Session, die die Technote als zugehöriges Video führt, heißt „Modernize your AppKit app“ (WWDC26 Session 289).³⁶

macOS 27 ergänzt NSControl.Events laut dem Abschnitt „Handle control events“ der Technote um weitere Fälle: trackingRepeated („An event when multiple mouseDown(with:) events with a click count greater than 1 occur“), valueChanged („An event when the value changes on continuous controls, such as sliders“), primaryActionTriggered, menuActionTriggered („An event that triggers when a menu gesture occurs, but before the menu presents“) und applicationReserved für eigene Zwecke.⁶⁷

Dann die Exklusivität. „By default, only one view can be interacted with at a time“ (7:20) (standardmäßig lässt sich jeweils nur eine View bedienen), was der Talk Gesten-Exklusivität nennt und die Technote mit Kompatibilität begründet: „For maximum compatibility, AppKit restricts gesture activations to a single view hierarchy at a time“ und „Unlike in iOS, the person can’t perform multiple interactions simultaneously, though scrolling is a notable exception.“³⁶ Das Opt-out erfolgt pro View: „The API to control gesture exclusivity is the exclusiveGestureBehavior property on NSView“ (7:48). Der Standardwert der Property „inherits its parent’s exclusive gesture behavior“ (7:57), und „By setting the exclusiveGestureBehavior property on the stove view to .notExclusive, the child slider subviews all become non-exclusive as well“ (8:01); die ganze App steigt über den Info.plist-Schlüssel NSViewGestureRecognizerIsExclusive aus.³⁶⁷ Der Talk sagt, die Property „is available in the next SDK“ (7:54). Apples Dokumentation führt sie als macOS 27.0 ohne Beta-Kennzeichnung, die Technote vom Juni beschreibt sie, und das macOS-27.0-SDK in Xcode 27.1 deklariert sie in NSView.h als API_AVAILABLE(macos(27.0)) mit dem Kommentar „Defaults to .inherit“; das SDK, das der Talk „next“ nennt, war also bereits ausgeliefert, als der Talk online ging (Analyse des Autors anhand der installierten Header).³⁶⁷

36 Punkte

Der Design-Talk nennt die Zahl dreimal, und der AppKit-Talk wiederholt sie. „Touch on macOS uses a touch target of 36 points. This creates the same physical size on display as iOS’s 44 points“ (9:17).⁴ Das Ziel ist mit Absicht unsichtbar: „All macOS’s framework controls have been updated to use this new touch target, but notice it’s invisible. The controls haven’t changed size and therefore don’t require a new layout“ (9:26) (alle Framework-Bedienelemente von macOS nutzen dieses neue Touch-Ziel, doch es ist unsichtbar; die Bedienelemente haben ihre Größe nicht geändert und brauchen daher kein neues Layout).⁴

Bei eigenen Views lautet die Anweisung, die Trefferfläche zu vergrößern, nicht das Bedienelement. Die Verbindungsknoten im AppKit-Talk waren „a little tricky to touch“ (5:14), also ergänzte der Engineer einen Parameter expandHitRect, der „expands the size of the target rect to a minimum of 36 points on each axis. This makes it easier for a touch to hit a node while still requiring the mouse to be precise and without modifying the layout“ (5:50), eine Technik, die er „for small resize or grab handles for selected objects in a canvas view“ (6:07) empfiehlt.³ Die Fassung des Design-Talks für Bedienelemente, die nicht von Apple stammen: „consider increasing the touch target area around your control instead of changing the control size“ (9:51).⁴

Die Größen der Bedienelemente bleiben, wie sie sind. „When designing inspectors or other control-heavy areas, medium-sized controls continue to be the default control size. Window toolbars use extra-large-sized controls by default. Large and extra-large controls should not be used outside of the toolbar“ (9:58), und „They should only be used sparingly to emphasize key moments or in apps of which content consumption is the primary use case“ (10:14).⁴ Für einstellungsartige Views gilt: „use FormStyle. Here as well, each row by default measures the 36-point height“ (10:28).⁴ Kleine und Mini-Bedienelemente bleiben zulässig: „They fully support touch regardless of their size“ (10:46), mit einer Regel für eigene: „If your app is using custom small controls, ensure touch works, even though the tap target might be small“ (10:50), denn „touch events should never be ignored“ (11:00).⁴

Den schwierigen Teil übernimmt das Framework für die drei Bedienelemente, die keine 36 Punkte groß sein können: „the stepper, dial, and slider“ (13:54) „now expand in place when interacting via touch“ (14:07), ohne beim vergrößernden Tippen ihren Wert zu ändern (14:26), und „collapse themselves when I’m not interacting with them“ (14:41); bei Slidern ist es eine Option, denn „sliders have the option to expand when presented small“ (15:36).⁴ Auch Menüs passen sich an: „when using touch, the menu shows slightly larger rows to help make selection easier“ (11:23), und ebenso vorübergehend eingeblendete Views: „views in your app that are briefly presented, such as popovers or custom menus, can show slightly altered layouts depending on the input used to invoke them“ (11:29).⁴

Hover fällt weg

„Direct touches don’t have an equivalent to mouseMoved events“ (10:38) (direkte Berührungen haben keine Entsprechung zu mouseMoved-Events), also braucht alles, was sich beim Überfahren mit der Maus zeigt, eine Entscheidung.³ Die Regeln des AppKit-Talks: „don’t change your app experience to permanently show hidden controls“ (10:49), „Static data like tooltips shouldn’t be revealed on touch“ (10:53) und „for hidden essential controls, install a touch-only click gesture recognizer to temporarily show the element on a touch tap“ (10:57).³ Die Technote bestätigt, dass der Zeigerpfad unverändert bleibt: „Hovering via mouseMoved(with:) is still managed with NSTrackingArea.“⁶

Die Regeln des Design-Talks sind dieselben, aus Sicht der Nutzer. „hover actions that are purely showing information, like tooltips, are not required to work with touch“ (11:53); Aktionen, die per Touch ohnehin leicht sind, brauchen keine eigene Affordance, etwa die Scroll-Buttons eines Karussells, die „remain hidden during a touch interaction“ (12:22), weil „horizontal scroll is always possible via touch“ (12:19); „only the most important hover actions relevant to that content should reveal themselves“ (12:30), wobei Safari genau zwei zeigt, wenn eine Seite berührt wird (12:36); und „actions that appear on hover be duplicated elsewhere in your UI“ (13:05), wobei der Teilen-Button von Erinnerungen unter Touch im Kontextmenü der Zeile liegt (13:20).⁴

Scrollen, langes Drücken, Ziehen, Text

Gescrollt wird mit einem Finger auf dem Display und mit zweien auf dem Trackpad (4:39).⁴ Wenn ein Finger zeichnen statt scrollen soll, stellt der AppKit-Talk „the decorating view’s enclosing scroll view to require two touches minimum for touch scrolling“ (6:40) ein; die Property heißt NSScrollView.minimumNumberOfTouchesForScrolling, macOS 27.0, daneben stehen maximumNumberOfTouchesForScrolling, isTouchScrollingEnabled und scrollGestureForRelationships.³⁷ Ein Recognizer, der einem Scrollen den Vortritt lassen soll, setzt isCancellableByScrollGesture; „NSScrollView now supports pull-to-refresh functionality“ über NSRefreshController; und bei NSPanGestureRecognizer gilt für das Paar minimumNumberOfTouches und maximumNumberOfTouches, dass sie „replace numberOfTouchesRequired“, das in 27.0 als veraltet markiert ist.⁶⁷

Langes Drücken ist auf dem Mac die Touch-Geste für Ziehen und Kontextmenü zugleich, und AppKit vermittelt zwischen beiden. „When a draggable item is long pressed, it should hint at its draggability with a lift animation. To get the drag-and-drop lift preview, use the existing drag-and-drop delegate APIs on NSTableView, NSOutlineView, and NSCollectionView“ (9:49).³ Für Menüs: „Use the menu property on NSView or override menu(for:). AppKit will detect this and automatically install the appropriate gesture recognizers, which include a control-tap gesture recognizer as an accelerator“ (10:11), und „When using both this menu API and the container view drag-and-drop delegate APIs, AppKit will coordinate when a long press becomes a drag-and-drop operation or a context menu one, even allowing the user to switch between them“ (10:25) (nutzen Sie diese Menü-API zusammen mit den Drag-and-Drop-Delegate-APIs der Container-View, koordiniert AppKit, wann ein langes Drücken zu einem Drag-and-Drop-Vorgang oder zu einem Kontextmenü wird, und lässt den Nutzer sogar zwischen beiden wechseln).³ Der Design-Talk zeigt die Sicht der Nutzer: Das Foto „scales up under my finger“ (3:50), sein Kontextmenü erscheint daneben (3:58), und Ziehen schließt das Menü (4:05); Umschalt- und Wahltaste funktionieren beim Ziehen per Touch weiterhin (4:13).⁴ Für eigene Views startet beginDraggingSession(items:gesture:source:) „a drag from a gesture recognizer“, neu in 27.0.⁶⁷

Text ist die dünne Stelle. Der eine Satz der Technote lautet „NSTextSelectionManager allows custom text engines to support standard text gestures“, und die Klasse ist als macOS 27.0 dokumentiert, mit dem Abstract „An object that coordinates text selection behavior for custom text views“.⁶⁷ Der Header füllt den Vertrag aus (Analyse des Autors): Die Klasse „provides a centralized way to manage text selection interactions using a set of gesture recognizers“, mit einem Interaktionsmodus, der bearbeitbar, nur auswählbar oder nicht interaktiv ist, einem Delegate, das die Auswahl speichert, und einer Layout-Datenquelle.⁷ Keiner der beiden Talks behandelt Einfügemarken, Auswahlgriffe oder ein Bearbeitungsmenü unter Touch; die Auswahlhinweise des Design-Talks betreffen Elemente, für die gilt: „on macOS we recommend to allow modeless selection through click and tap“ (2:42), einmal tippen zum Auswählen und zweimal tippen zum Öffnen (3:10).⁴

Systemgesten und der Schalter, der nicht dokumentiert ist

macOS beansprucht auf dem Display eine Reihe von Mehrfingergesten, die „controlled by macOS and are therefore not available to any app running“ (8:05) sind (von macOS gesteuert und daher für keine App verfügbar): drei Finger nach oben für Mission Control und nach unten für App Exposé (8:13), ein Zusammenziehen mit Daumen und drei Fingern, um Apps anzuzeigen, und ein Spreizen, um den Schreibtisch freizulegen (8:22), drei Finger nach links oder rechts zwischen Spaces (8:32), Wischen vom oberen und unteren Rand für eine ausgeblendete Menüleiste und das Dock (8:37), ein Wischen über die Dynamic Island, um Siri aufzurufen (8:46), und Wischen vom Rand für Mitteilungszentrale und Kontrollzentrum (8:51).⁴

Der AppKit-Talk gerät mit drei Slidern in den Konflikt: „if I try to control three or more sliders in the same direction at the same time, I get the system gesture instead“ (8:17), und zeigt den Schalter: „I can control system gesture availability at the window level with the disablesDirectTouchSystemGestures property on NSWindow. SwiftUI and Mac Catalyst also have similar API on UIViewController and View“ (8:25), mit der Warnung „Only disable system gestures if the interaction capabilities they open up are critical for the window“ (8:42) (Systemgesten nur abschalten, wenn die dadurch möglichen Interaktionen für das Fenster unverzichtbar sind).³ Das Code-Listing der Talk-Seite nennt alle drei: disablesDirectTouchSystemGestures an NSWindow, prefersDirectTouchSystemGesturesDisabled an UIViewController und directTouchSystemGesturesDisabled() an einer SwiftUI-View.³ Keines der drei steht am 28. Oktober in Apples Dokumentation; die JSON-Endpunkte liefern 404, und die Symbole fehlen in den Indizes von AppKit, UIKit und SwiftUI.⁷ Meine Lesart, keine Aussage von Apple: Sie sind das deutlichste Zeichen dafür, dass das SDK, von dem die Talks ausgehen, dasjenige ist, das als „Coming soon“ markiert ist.

SwiftUI und Mac Catalyst

SwiftUI bekommt einen neuen Typ: „if you have a specialized need to distinguish between mouse and direct touch input, you can use the new GestureInputKinds gesture modifier API“ (0:43).³ GestureInputKinds ist auf allen sieben Plattformen mit 27.0 dokumentiert, mit .directTouch („A person is touching content directly“), .pointer („A person is pressing a mouse or a trackpad button while the pointer is pointing at content“), .indirectTouch, .pencil und .all sowie inputKinds:-Parametern an onTapGesture, onLongPressGesture und den Initialisierern von TapGesture, SpatialTapGesture, LongPressGesture, DragGesture, MagnifyGesture und RotateGesture.⁷ Der Satz der Technote lautet: „Use GestureInputKinds to limit gestures to specific types of input in SwiftUI.“⁶

Mac Catalyst nutzt, was UIKit seit iOS 9 hat: Der Talk sagt „UITouch.touchType and UIGestureRecognizer’s allowedTouchTypes“ (0:59); die dokumentierte Property ist UITouch.type mit dem Enum UITouch.TouchType, und allowedTouchTypes steht an UIGestureRecognizer ab Mac Catalyst 13.1.³⁷ Die Formulierung des Talks ist ein Versprecher, keine neue API.

Live Activities auf dem Mac, der Dokumentation voraus

Der dritte Talk ist kurz und stellt eine große Behauptung auf. „The Dynamic Island has come to the Mac. To fully take advantage of its capabilities, Mac apps now support native Live Activities“ (0:05), und „now in macOS Golden Gate, applications running on the Mac can create Live Activities directly“ (0:57).⁵ „Universal applications with existing Live Activities will work on the Mac with no code change, and native macOS apps can create Live Activities directly through the Live Activities API“ (1:03) (universelle Apps mit bestehenden Live Activities funktionieren ohne Codeänderung auf dem Mac, und native macOS-Apps können Live Activities direkt über die Live Activities API erzeugen).⁵ Zur Platzierung: „On a Mac with Dynamic Island, Live Activities blend in seamlessly into the top edge of the device. On other devices and displays, they are shown in the menu bar“ (1:14).⁵ Der Code ist der iOS-Code: das Datenmodell in ActivityAttributes (2:36), die Compact- und Minimal-Darstellungen in ActivityConfiguration mit dem View Builder für die Dynamic Island (3:24), die einzige Mac-spezifische Darstellung, „The menu bar expanded Live Activity view is created along with the ActivityConfiguration as a simple view“ (3:52), während „Expanded Live Activities in the Dynamic Island are defined with the Dynamic Island view builder“ (4:02), „This same code works on iOS and macOS“ (4:30), Starts, die sofort, geplant oder per Push erfolgen (4:40), die Integration „with existing backgrounding technologies on the Mac, like background tasks and user agents“ (4:54), Aktionen über App Intents (5:56) und „If you have an iOS activity, there’s no code to port“ (7:09).⁵ Zwei Regeln gelten wie unter iOS: „Only a single Live Activity can be expanded at a time“ (3:12) und „An activity is only expanded when interacted with or if explicitly triggered through an alert request“ (3:06).⁵

Apples Dokumentation sagt das noch nicht. Der Abstract der ActivityKit-Framework-Seite nennt „the Mac“, aber ihr Overview sagt „On Mac, it appears in the Menu bar“, ihre Plattformliste lautet iOS, iPadOS und Mac Catalyst 16.1, und Activity, ActivityAttributes, ActivityConfiguration, DynamicIsland sowie der Schlüssel NSSupportsLiveActivities führen keine macOS-Plattform.⁸⁷ Die Live-Activities-Seite der HIG, deren Änderungsprotokoll am 13. Oktober endet, beschreibt weiterhin nur den Weg über ein gekoppeltes iPhone: „Active Live Activities automatically appear in the Menu bar of a paired Mac“, „Clicking the Live Activity launches iPhone Mirroring to display your app“ und, unter „macOS dimensions“, „Use the provided iOS dimensions“.¹⁰ Die SDKs stimmen mit der Dokumentation überein, nicht mit dem Talk: Im macOS-27.0-SDK in Xcode 27.1 und im macOS-27.2-SDK in der Xcode-27.2-Beta (27B5019j) markiert das macOS-Interface von ActivityKit ActivityAttributes, Activity, jedes request und update als @available(macOS, unavailable), geprüft auf diesem Mac (Analyse des Autors). Der richtige Satz für eine Planung ist also der enge: Der Talk sagt, die Fähigkeit existiere in macOS Golden Gate, und weder die Dokumentation noch eines der beiden SDKs, die ich geprüft habe, lässt Sie sie bisher bauen. Der Beitrag zur Zustandsmaschine zeigt eine iOS-Implementierung des gemeinsamen Modells aus Start, Aktualisierung und Ende; die eigenen Grenzen des Mac für Dauer, Ausblenden und Hintergrundbetrieb stehen noch in keiner Quelle.

Design: macOS ändert sich nicht

Die abschließenden Regeln des Design-Talks sind kurz genug, um sie vollständig wiederzugeben. „Avoid redesigning your app just to support touch. Your app on a Mac that supports touch should have no visual distinction from your app on a Mac that doesn’t“ (16:05). „Use gestures to navigate your app and directly manipulate your content“ (16:14). „Use 36 points as a touch target on macOS, and use Apple frameworks to get touch-optimized layouts and expandable controls“ (16:18). „Most apps will work great with touch right away“ (16:28). „Keep keyboard and mouse as a primary input“ (16:31) (kurz: kein Redesign nur für Touch und kein sichtbarer Unterschied, Gesten für Navigation und direkte Manipulation, 36 Punkte als Touch-Ziel und Apple-Frameworks für touch-optimierte Layouts und sich vergrößernde Bedienelemente, die meisten Apps funktionieren mit Touch sofort gut, Tastatur und Maus bleiben die primäre Eingabe).⁴

Die eine räumliche Regel betrifft Hände, nicht Haltungen. „The edges of the display are easy to touch by grabbing the side of the display with my hand“ (6:17), daher gilt: „The left and right side of my app window are therefore best used to show rich controls and dense UI, such as inspectors and navigation sidebars“ (6:29), während „the center of the display is best used for coarse, imprecise and big gestures“ (6:46) (die linke und rechte Seite des App-Fensters eignen sich am besten für umfangreiche Bedienelemente und dichte UI wie Inspektoren und Navigationsseitenleisten, die Mitte des Displays für grobe, ungenaue und große Gesten).⁴ Eigene Gesten unterliegen drei Einschränkungen: „your gestures should work with touch and trackpad and possibly Magic Mouse“ (7:00), „Avoid adding gestures that only work with touch“ (7:05) und „The action your gesture does should be duplicated elsewhere in the UI, for example in a menu“ (7:37).⁴ Der Talk erlaubt auch, was der Mac nie hatte: „macOS now allows multiple touch gestures at the same time“ (5:30), mit zwei Slidern in Logic unter zwei Fingern als Beispiel (5:45).⁴ Das ist die Nutzerseite der Exklusivitäts-Property von oben: Der Standard von AppKit lässt jeweils nur eine View-Hierarchie zu, und .notExclusive ist der Weg, auf dem eine App den Rest öffnet.³⁶

Testen heute: Sidecar und das SDK, das noch nicht da ist

Den Laptop brauchen Sie nicht. „With the latest macOS beta and developer tools, all the touch features of the Mac with Touch Display are available with an iPad connected to your Mac with Sidecar“ (11:59) (mit der neuesten macOS-Beta und den neuesten Entwicklertools stehen alle Touch-Funktionen des Mac mit Touch-Display mit einem per Sidecar verbundenen iPad zur Verfügung), und „The fastest way to get started with touch on Mac is with the Sidecar tools you already own“ (12:09).³ Die Technote setzt voraus, dass auf dem iPad iPadOS 27 läuft, und ergänzt einen Vorbehalt zur Fähigkeitsprüfung (NSScreen.touchCapabilities, ein Option Set mit einem .multiTouch-Bit): In macOS 27 „returns true for all displays when a touch-capable Sidecar display is connected, not just for the Sidecar display“ (meldet die Prüfung für alle Displays true, sobald ein touchfähiges Sidecar-Display verbunden ist, nicht nur für das Sidecar-Display), mit dem Rat: „it’s better to handle events regardless of input source and decide on an alternate presentation based on the interaction type, if needed“.⁶⁷

Das Audit des Talks, in seiner eigenen Reihenfolge: „start testing your application with touch on macOS with Sidecar. Then audit your code for mouseDown(with:) overrides. Determine if you can use control events or delegate methods instead, or if you need to add your own touch-specific gesture recognizers. Look for areas that have small hit targets and expand them for touch. And finally, add an affordance or use a tap to reveal essential hidden UI“ (12:24).³ Es gibt außerdem einen Skill: „there’s a gesture modernization skill that has an understanding of the features and changes I’ve talked about“ (12:16); die Xcode-Kachel der Landingpage trägt einen Platzhalterkommentar, TK skill, und keine Quelle nennt ihn beim Namen.²³

Was die ausgelieferten SDKs enthalten, Analyse des Autors anhand der Header und Swift-Interfaces auf diesem Mac: Das macOS-27.0-SDK in Xcode 27.1 (27A9275) deklariert NSScreen.TouchCapabilities, die fünf neuen NSControl-Event-Fälle, die Touch-Properties von NSScrollView, NSRefreshController, beginDraggingSession(items:gesture:source:) und exclusiveGestureBehavior, alle als API_AVAILABLE(macos(27.0)), und das macOS-Interface von SwiftUICore, das SwiftUI re-exportiert, deklariert GestureInputKinds. Die drei Schalter für Systemgesten stehen weder in diesem SDK noch im macOS-27.2-SDK in der Xcode-27.2-Beta (27B5019j), weder in den Headern von AppKit noch im Interface von SwiftUI noch in den UIKit-Headern für Mac Catalyst, und das macOS-Interface von ActivityKit markiert seine API in beiden SDKs als nicht verfügbar.⁷⁸

Das sind die beiden SDKs, die ich geprüft habe; der Xcode 27.2 RC (27B48), den Apples Releases-Feed auf den 19. Oktober datiert, ist neuer als diese Beta und wurde nicht geprüft, die Befunde zum Fehlen gelten also für die genannten SDKs und nicht darüber hinaus.¹¹

Was Sie heute zum Testen installieren sollten, von mir nicht getestet: macOS 27.2 (26B123, laut Feed am 26. Oktober erschienen) und den Xcode 27.2 RC, dazu ein iPad mit iPadOS 27 über Sidecar; die Technote beschreibt Sidecar-Touch als funktionsfähig unter macOS 27, und der Feed führt am 28. Oktober keine Beta von macOS 27.3.⁶¹¹ Ein Vorbehalt aus den eigenen Notes des RC: „macOS, watchOS, tvOS, and visionOS SDKs in Xcode 27.2 incorrectly report 27.1 as a valid deployment target“ und „Mac Catalyst builds with a 27.1 or 27.2 deployment target might be unable to use newly introduced API“ (die SDKs für macOS, watchOS, tvOS und visionOS in Xcode 27.2 melden 27.1 fälschlich als gültiges Deployment-Target, und Mac-Catalyst-Builds mit einem Deployment-Target von 27.1 oder 27.2 können neu eingeführte APIs möglicherweise nicht nutzen); wählen Sie also nicht 27.1 als macOS-Deployment-Target (der Releases-Feed führt macOS 27.0.1 und 27.2, aber kein macOS 27.1), und lesen Sie ein Mac-Catalyst-Target mit 27.1 oder 27.2, das eine neue API nicht sieht, als dieses bekannte Problem und nicht als fehlendes Symbol.¹¹

Was also fehlt: die Xcode-27.3-Beta, die die Landingpage verspricht, der AppKit-Artikel, auf den sie verlinkt, die drei Systemgesten-Symbole und ein unter macOS verfügbares ActivityKit (in den beiden geprüften SDKs nicht vorhanden, im 27.2 RC nicht überprüft) sowie jede Aussage zu einem Simulator. Die Notes zum Xcode 27.2 RC erwähnen Touch ein einziges Mal, als Korrektur in Device Hub für Eingaben, die „after a period of inactivity“ (nach einer Zeit der Inaktivität) ausblieben, und die Notes zu macOS 27.2 haben keinen Eintrag zu Touch, Gesten oder Live Activities.¹¹ Die Touch-APIs kamen mit Xcode 27.1, die Regeln sind veröffentlicht, und die Landingpage markiert das Nächste mit „Coming soon“.

Ein Touch-Audit für jede Mac-App

Analyse des Autors, keine Anleitung von Apple: die vier Schritte des Talks, in ihrer Reihenfolge, als Checkliste. Bisher stehen keine Tests zur Laufzeit dahinter.

1. Sidecar mit einem iPad unter iPadOS 27, auf den neuesten Versionen von macOS und Xcode (macOS 27.2 und der Xcode 27.2 RC), und jeder Bildschirm der App berührt, bevor irgendetwas geändert wird.
2. Eine Suche nach Overrides von mouseDown(with:) und nach nextEvent(matching:)-Schleifen, wobei jeder Fund Control-Events, einer Delegate-Methode oder einem Gesture Recognizer zugeordnet wird.
3. Ein Durchgang durch kleine Bedienelemente und Trefferflächen, mit vergrößerter Touch-Fläche, wo es hilft, und ohne Layoutänderung; der Talk erlaubt ein kleineres Bedienelement, solange Touch darauf noch funktioniert.
4. Eine Liste von allem, was beim Überfahren mit der Maus erscheint, mit einer Entscheidung je Element: Ein Tooltip bleibt der Maus vorbehalten; eine Aktion, die per Touch schon leicht ist, braucht nichts; ein essenzielles Bedienelement bekommt einen reinen Touch-Klick-Recognizer und einen zweiten Platz an anderer Stelle der UI, etwa in einem Kontextmenü.

Das Einzige, was das Audit nicht hervorbringt, ist ein Redesign, denn die erste Regel des Design-Talks lautet, dass es keinen sichtbaren Unterschied geben soll; das einzige Layout, das sich mit der Eingabe ändern darf, ist ein vorübergehendes, ein Popover oder ein eigenes Menü.

Was Apple nicht gesagt hat

Jeder dieser Punkte ist eine Frage, die die Quellen offenlassen, geprüft an der Pressemitteilung, der Landingpage, den drei Talks, der Technote, der Seite mit den technischen Daten, den Notes zum Xcode 27.2 RC und zu macOS 27.2 sowie den vier HIG-Seiten.

• Welches Point-Release von macOS Touch auf dem eingebauten Display mitbringt und welches SDK die drei undokumentierten Symbole enthält. Die Pressemitteilung sagt „macOS 27“ und nennt macOS 27.2 nur in ihrer Fußnote zu Siri AI; die Landingpage sagt „Xcode 27.3 beta“, „Coming soon“.
• Ob eine Binärdatei, die gegen ein älteres SDK gebaut wurde, dasselbe Touch-Verhalten bekommt wie eine, die mit dem macOS-27-SDK neu gebaut wurde. Der Talk sagt „all apps“; die Technote knüpft nur die Änderung an location(in:) an das neue SDK.
• Apple Pencil oder Druck auf dem Display und ob das Glas einen Finger erkennt, bevor er es berührt. Die Talks behandeln das Fehlen eines mausähnlichen Hover-Zustands; keine Quelle erwähnt einen Stift, Druck oder Annäherungserkennung, und GestureInputKinds.pencil ist für macOS 27.0 aufgeführt wie jedes andere Mitglied, während keine Quelle sagt, dass das Display einen Stift erkennt.⁷
• Touch auf externen Displays oder im zugeklappten Betrieb, und ob Nutzer Touch abschalten können.
• Textbearbeitung per Touch: Einfügemarken, Griffe, eine Lupe und das Bearbeitungsmenü.
• Bedienungshilfen mit dem Touch-Display. Die Seite mit den technischen Daten führt AssistiveTouch und Touch-Anpassungen unter den Funktionen des Laptops und sagt nicht, ob sie auf dem Mac neu sind.⁹
• Wie eine App im Modus „Designed for iPad“ auf dem Mac-Display Berührungen empfängt und ob sich das von Mac Catalyst unterscheidet.
• Ein Weg über Simulator oder Device Hub für Mac-Touch ohne iPad.
• Webinhalte: ob WKWebView und Safari Touch- oder Pointer-Events an Seiten liefern.
• Wie sich Fenster und Vollbildinhalte zur Dynamic Island verhalten und welche Safe-Area-API sie meldet.
• Details zu Live Activities unter macOS: das Point-Release und das SDK, ob NSSupportsLiveActivities erforderlich ist, wie Push-to-Start und die APNs-Registrierung auf dem Mac funktionieren, und Maße für eine Mac-native Activity.

Der Kalender

• 28. Oktober: Vorbestellungen in 30 Ländern und Regionen; die Entwicklerseite und drei Talks; die Technote ist seit dem 8. Juni online.¹²⁶
• 6. November: Der Laptop erreicht Kunden und Geschäfte.¹
• 18. November, 9 bis 10 a.m. PT, und 19. November, 6 bis 7 p.m. PT: Touch on Mac Group Labs, online, mit Ingenieuren und Designern von Apple.²
• „Coming soon“: die Xcode-27.3-Beta, die Dokumentationsressourcen, die Designressourcen.²
• Diesen November: das Update von Apple Creator Studio, dessen Touch-Funktionen in Logic Pro und Final Cut Pro die Pressemitteilung beschreibt; die Drittanbieter-Apps, die sie nennt, „will be available later this year“ (werden später in diesem Jahr verfügbar sein).¹

Die wichtigsten Erkenntnisse

Für AppKit-Entwickler: Standard-Bedienelemente sind jetzt touch-nativ; Ihr eigener mouseDown(with:)-Code wird emuliert, bis Sie auf Control-Events oder Gesture Recognizer umstellen, und ein reiner Touch-NSPanGestureRecognizer mit buttonMask = 0 und allowedTouchTypes = .direct ist der Weg für ein Punkt-Update, den der Talk empfiehlt; die APIs stecken im macOS-27.0-SDK, das Sie bereits haben.³⁷

Für SwiftUI- und Catalyst-Entwickler: Ihre Gesten funktionieren bereits; GestureInputKinds ist der eine neue SwiftUI-Typ, und die Antwort von Catalyst sind UITouch.type und allowedTouchTypes.³⁷

Für Designer: 36 Punkte, unsichtbar; kein Redesign; essenzielle Hover-Aktionen per Touch erreichbar und zusätzlich an anderer Stelle der UI platziert, etwa in einem Kontextmenü, Tooltips ausgenommen; dichte UI an den Rändern, grobe Gesten in der Mitte.⁴

Für die Planung: Testen Sie jetzt mit Sidecar; bevor Sie etwas bauen, das Systemgesten deaktiviert oder eine Mac-native Live Activity erzeugt, prüfen Sie, ob das installierte SDK diese APIs deklariert, denn die beiden hier untersuchten SDKs tun es nicht, und der Xcode 27.2 RC ist ungeprüft; das nächste SDK, das Apple versprochen hat, ist die Xcode-27.3-Beta.²⁷⁸

Häufige Fragen

Funktioniert meine bestehende Mac-App mit Touch?

Apple sagt für die meisten Apps ja: „many existing apps work with Touch right away, because macOS automatically translates touches into clicks“, und der AppKit-Talk sagt, dass Standardkomponenten von AppKit, SwiftUI und Mac Catalyst sowie bestehende Gesten „just work“.¹³ Eigener Code für Maus-Tracking wird emuliert, bis er auf Control-Events oder Gesture Recognizer umgestellt ist; ein UI-Framework, das nicht von Apple stammt, erhält eine generische Emulationsschicht, die NSIsTouchNative abschaltet, sobald die App Touch selbst verarbeitet.³⁶

Wie empfange ich in AppKit eine direkte Berührung?

Mit einem Gesture Recognizer. Der Talk sagt „gesture recognizers are the only way to get direct touches on macOS“, und die Technote sagt, dass Touch-Events weder durch die Responder Chain noch durch Event-Monitore, NSApp oder sendEvent(_:) laufen.³⁶ Ein reiner Touch-Recognizer setzt buttonMask auf 0 und allowedTouchTypes auf .direct.³

Wie groß ist das Touch-Ziel unter macOS?

36 Punkte, „the same physical size on display as iOS’s 44 points“ (dieselbe physische Größe wie 44 Punkte unter iOS). Framework-Bedienelemente erfüllen das bereits, ohne ihre Größe zu ändern; vergrößern Sie bei eigenen Views die Trefferfläche, nicht die View.⁴³

Wie teste ich Touch ohne das neue MacBook Pro?

Verbinden Sie ein iPad mit iPadOS 27 über Sidecar. Die Bedingung des Talks lautet „With the latest macOS beta and developer tools“ (11:59), und eine Beta von macOS 27.3 ist nicht erschienen, also ist die Konfiguration, die ich ausprobieren würde, macOS 27.2 mit dem Xcode 27.2 RC, von mir nicht getestet.³⁶¹¹

Sind die Touch-APIs heute im SDK?

Ja, für alles, was die Talks vorführen, außer den Schaltern für Systemgesten und Mac-nativen Live Activities, die in den beiden hier untersuchten SDKs fehlen (der Xcode 27.2 RC wurde nicht untersucht). Das macOS-27.0-SDK in Xcode 27.1 deklariert NSScreen.TouchCapabilities, die neuen NSControl-Event-Fälle, die Touch-Properties von NSScrollView, NSRefreshController, exclusiveGestureBehavior und die gestenbasierte Dragging-Session, und das Interface von SwiftUICore deklariert GestureInputKinds; Apples Dokumentation führt sie als macOS 27.0 ohne Beta-Kennzeichnung.⁷ Die Schalter für Systemgesten an Fenster, View Controller und View stehen weder in der Dokumentation noch in den SDKs von Xcode 27.1 oder der 27.2-Beta, ActivityKit markiert seine API in beiden unter macOS als nicht verfügbar, und die Landingpage markiert die Xcode-27.3-Beta mit „Coming soon“.²⁷⁸

Kann eine Mac-App Live Activities erstellen?

Der Talk sagt ja, in macOS Golden Gate, mit demselben ActivityKit- und WidgetKit-Code wie unter iOS und einer Darstellung in der Menüleiste auf Macs ohne Dynamic Island.⁵ Die Dokumentation von ActivityKit und die HIG führen macOS noch nicht als Plattform für von Apps erstellte Activities, sie beschreiben den Weg über die Menüleiste mit einem gekoppelten iPhone, und das ActivityKit-Interface in den SDKs von Xcode 27.1 und der 27.2-Beta markiert die API unter macOS als nicht verfügbar.¹⁰⁸

Woher stammen die Fakten in diesem Beitrag?

Aus der Pressemitteilung, dem Entwickler-News-Beitrag und der Landingpage, den englischen Untertitelspuren der drei Tech Talks, wobei der erste Cue jedes Zitats in Klammern steht, der Technote vom Juni, Apples Dokumentations-JSON für jedes genannte Symbol, der Seite mit den technischen Daten, den Release Notes zum Xcode 27.2 RC und zu macOS 27.2 sowie den vier HIG-Seiten, alle abgerufen am 28. Oktober 2026, dazu aus den Headern und Swift-Interfaces der SDKs von macOS 27.0 und der 27.2-Beta auf meinem Mac, was Analyse des Autors ist. Presseberichte sind keine Quelle.

Quellen