Touch on Mac for Developers: 36 Points, Recognizers, Sidecar

What does Touch on the Mac change for Mac developers? Existing apps work because “macOS automatically translates touches into clicks,” and three Tech Talks carry the rules: gesture recognizers are “the only way to get direct touches on macOS,” standard controls are touch native, the touch target is 36 points, hover has no equivalent, and an iPad on Sidecar is the test rig.¹²³⁴ The touch APIs are in the macOS 27.0 SDK already; the system-gesture switches and a macOS-available ActivityKit are not, in the two SDKs I checked, and the Xcode 27.3 beta is “Coming soon.”²⁵⁶⁷⁸

TL;DR: Apple announced Touch on the MacBook Pro with PROLED XDR Display (14.2 and 16.3 inches, pre-orders October 28, in stores November 6) and told developers how to adopt it in three talks on October 28.¹²⁹ If your app uses standard AppKit controls, SwiftUI gestures or Mac Catalyst, the talk says they “just work,” and the audit below (hit targets, hover) still applies. Custom mouseDown(with:) code is emulated until it moves to control events or gesture recognizers, and a non-Apple UI framework gets a generic emulation layer that NSIsTouchNative turns off once the app handles touch itself.³⁶ To receive a direct touch in AppKit you need a gesture recognizer, because touches never reach the responder chain or event monitors.³⁶ The design talk fixes the touch target at 36 points, the same physical size as 44 points on iOS, and says macOS looks the same with and without touch.⁴ Test with an iPad over Sidecar; the newest pieces are macOS 27.2 and the Xcode 27.2 RC, a configuration I have not run.³¹¹ The touch APIs are in the macOS 27.0 SDK already. The system-gesture switch and a macOS-available ActivityKit are absent from the two SDKs I checked, and the Xcode 27.3 beta is “Coming soon.”²³⁷⁸

What Apple has published, and what it has not

Apple’s announcement was a press release, not a keynote; the live post has the day’s record. The release’s developer content is three sentences in the section “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,” then “Updated system gesture APIs also enable developers to create intuitive experiences designed specifically for Touch,” and the note that “app developers can test how Touch performs in their iOS and iPadOS apps directly on the MacBook Pro display.”¹ The section on macOS says the laptop “comes to life with macOS 27” and names “Touch built for macOS 27”; it does not name a point release.¹

The developer side was up by 11:47 a.m. PT: a news post, “Say hello to Touch on Mac,” and a landing page, “Get ready for Touch on Mac,” with three Tech Talks, Group Labs on November 18 and 19, and three tiles marked “Coming soon”: “Xcode 27.3 beta,” “Documentation resources,” and “Design resources.”² The page’s HTML carries the links Apple plans to attach to those tiles inside comments marked for re-enabling when the resources go live: an AppKit article, “Adopting gesture recognizers in your app,” which returns 404 today, the existing file-promises drag and drop sample, and, among its links, four Human Interface Guidelines pages and Apple Design Resources; the captured HIG pages contain no guidance for touch on the Mac display, and the Live Activities page’s change log ends at October 13.²⁷¹⁰

So the primary sources for the rules are the talks and a technote Apple published on June 8, “TN3212: Adopting gesture recognizers for Sidecar touch support,” whose Overview says that “In macOS 27, AppKit continues to standardize on gesture recognizers as the primary mechanism for input handling,” and whose sections “Explore updated APIs in macOS 27,” “Detect touch capability,” “Handle control events,” and “Configure scroll behavior” describe the API surface the October 28 talks demonstrate.⁶ Every new symbol the technote names is in Apple’s documentation with introducedAt macOS 27.0 and no beta flag, fetched October 28 at noon PT, and, apart from the two Info.plist keys, declared in the macOS 27.0 SDK inside Xcode 27.1 (27A9275), checked in the headers and Swift interfaces on this Mac (author analysis).⁷ The three system-gesture symbols the talk names are not, and neither is a macOS-available ActivityKit; both are below.

Nothing to do, and what you get for it

The compatibility story is generous. The AppKit talk opens with it: “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), and the same for Mac Catalyst (0:52).³ In AppKit, “Standard buttons, controls, tables, collections, split views, tabs, scrolling, and more are all touch native” (1:10).³

What is not native is emulated: “for existing custom AppKit mouse interactions, or if you use non-Apple UI frameworks, AppKit intelligently emulates the mouse” (1:17).³ The technote spells the emulation out for third-party frameworks: “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,” and “A two-finger pinch or rotation simultaneously emulates both the trackpad magnify and rotate gestures.”⁶ The talk’s version: “a one-finger scroll with momentum, click, drag with a small hold delay, and even pinch for rotation and magnification” (11:28).³ The emulation is per window and generic, because “AppKit can’t determine what kind of interactions are allowed at any particular location of your non-Apple UI framework content” (11:17).³

When you have added native support, you turn the emulation off: “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).³ The key is documented as macOS 27.0, and its page says “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.”⁷

The design talk’s framing matters for what “nothing to do” means visually: “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), and “Touch is a secondary input for macOS, and therefore has little impact on how macOS looks” (1:06).⁴ There is no touch mode and no compact layout. That is the opposite of the iPhone Duo situation, where the inner display reports regular size classes in both dimensions.

Gesture recognizers are the only way in

The sentence that organizes everything else is at 3:45 of the AppKit talk: “In fact, gesture recognizers are the only way to get direct touches on macOS.”³ Before it: “Starting with macOS Golden Gate, gesture recognizers are the preferred approach in AppKit” (3:33), and “gesture recognizers have become the shared input language across SwiftUI, Mac Catalyst, and now AppKit” (3:38).³ The technote says the same thing from the other direction: “AppKit doesn’t deliver Sidecar touch events through the responder chain or through event monitors,” and in a note, “Local and global event monitors don’t receive touch events. Touch events don’t go through NSApp or sendEvent(_:).”⁶

That has three consequences for an AppKit codebase.

First, tracking loops. The talk’s engineer rebuilds a wiring puzzle that used “a custom NSView with a mouseDown(with:) override that uses the standard tracking loop technique” (3:13), calling nextEvent(matching:) until mouse up, and says “Migrate your mouse tracking loops to gesture recognizers” (3:51).³ The migration is not all or nothing: “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).³ The first step is the refactor the talk does before it adds anything: “The first step is to refactor my tracking loop into separate start, continue, end, and cancel tracking functions” (4:11), so that the mouse loop and the touch recognizer can share them.³ Apple’s listing, verbatim:

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

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

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

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

The recipe for a touch-only recognizer is then two property assignments: “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)

The action routes the recognizer’s .began, .changed, .ended and .cancelled states to the four functions. The reason for the cancel path is the one the talk gave for the 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), and the technote’s rule is “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 dates to macOS 10.10 and allowedTouchTypes to 10.12.2; nothing in that recipe is new.⁷

Second, the rules recognizers impose. The technote: “If your view is covered by another, often transparent, view, your gesture recognizer won’t be triggered,” and “You can’t place views on top of standard framework controls, because those controls now use gesture recognizers internally,” with the technote’s own way out: “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.”⁶ A custom recognizer must finish: “End your active gesture recognizer by transitioning to ended, failed, or cancelled. If you don’t, recognizers are blocked from activating.”⁶ And a behavior change scoped to subclasses built with the new SDK: “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,” because “Subclasses of NSGestureRecognizer must implement location(in:) to report a meaningful location.”⁶

Third, what you lose. For control actions, the technote says the move to recognizers on NSControl “changes the timing of when AppKit delivers control action messages with respect to event processing,” so currentEvent “no longer returns the event that triggered an action,” points to NSEvent.pressedMouseButtons and the class-level modifierFlags instead, and adds that “a touch is not part of pressedMouseButtons.”⁶ And a subclass that overrides a left-mouse method pays for it: “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.”⁶

Controls: events instead of mouseDown

The AppKit talk’s first refactor is a button. The original subclassed NSButton and overrode mouseDown(with:) to learn when tracking started and ended; under touch “the buttons work, but AppKit must emulate mouse events to pass to the mouseDown override” (2:17).³ The replacement is NSControl events “directly on NSButton without the need to subclass” (2:27); the talk page’s 2:24 listing registers three addTarget(_:action:for:) calls on the button, for [.trackingBegan, .trackingEntered], [.trackingExited, .trackingEndedInside] and .trackingCancelled, and the events also surface the state a mouse override never saw: “If tracking is canceled due to a system gesture like Exposé, scroll, or any other reason, I can revert any unintended changes” (2:41).³ The events are old: “NSControl events are available for standard AppKit controls, and most control events are available all the way back to macOS 11” (2:51).³ The talk points at the WWDC26 session it calls “Modernizing your AppKit app” for the pattern; the session the technote lists as its related video is “Modernize your AppKit app” (WWDC26 session 289).³⁶

macOS 27 adds cases to NSControl.Events, per the technote’s “Handle control events” section: 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”), and applicationReserved for your own.⁶⁷

Then exclusivity. “By default, only one view can be interacted with at a time” (7:20), which the talk calls gesture exclusivity and the technote explains as compatibility: “For maximum compatibility, AppKit restricts gesture activations to a single view hierarchy at a time,” and “Unlike in iOS, the person can’t perform multiple interactions simultaneously, though scrolling is a notable exception.”³⁶ You opt out per view: “The API to control gesture exclusivity is the exclusiveGestureBehavior property on NSView” (7:48). The property’s default “inherits its parent’s exclusive gesture behavior” (7:57), and “By setting the exclusiveGestureBehavior property on the stove view to .notExclusive, the child slider subviews all become non-exclusive as well” (8:01); the whole app opts out with the NSViewGestureRecognizerIsExclusive Info.plist key.³⁶⁷ The talk says the property “is available in the next SDK” (7:54). Apple’s documentation lists it as macOS 27.0 with no beta flag, the June technote describes it, and the macOS 27.0 SDK inside Xcode 27.1 declares it API_AVAILABLE(macos(27.0)) with the comment “Defaults to .inherit” in NSView.h, so the SDK the talk calls “next” was already shipping when the talk went up (author analysis from the installed headers).³⁶⁷

36 points

The design talk gives the number three times and the AppKit talk repeats it. “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).⁴ The target is invisible by design: “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).⁴

For custom views the instruction is to expand the hit area, not the control. The AppKit talk’s wiring nodes were “a little tricky to touch” (5:14), so the engineer added an expandHitRect parameter that “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), a technique he recommends “for small resize or grab handles for selected objects in a canvas view” (6:07).³ The design talk’s version for non-Apple controls: “consider increasing the touch target area around your control instead of changing the control size” (9:51).⁴

Control sizes do not move. “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), and “They should only be used sparingly to emphasize key moments or in apps of which content consumption is the primary use case” (10:14).⁴ For settings-like views, “use FormStyle. Here as well, each row by default measures the 36-point height” (10:28).⁴ Small and mini controls stay legal: “They fully support touch regardless of their size” (10:46), with one rule for custom ones: “If your app is using custom small controls, ensure touch works, even though the tap target might be small” (10:50), because “touch events should never be ignored” (11:00).⁴

The framework does the hard part for the three controls that cannot be 36 points: “the stepper, dial, and slider” (13:54) “now expand in place when interacting via touch” (14:07), without changing their value on the expanding tap (14:26), and “collapse themselves when I’m not interacting with them” (14:41); for sliders it is an option, since “sliders have the option to expand when presented small” (15:36).⁴ Menus adapt too: “when using touch, the menu shows slightly larger rows to help make selection easier” (11:23), and so can transient 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 is gone

“Direct touches don’t have an equivalent to mouseMoved events” (10:38), so everything that reveals on rollover needs a decision.³ The AppKit talk’s rules: “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), and “for hidden essential controls, install a touch-only click gesture recognizer to temporarily show the element on a touch tap” (10:57).³ The technote confirms the pointer path is untouched: “Hovering via mouseMoved(with:) is still managed with NSTrackingArea.”⁶

The design talk’s rules are the same from the user’s side. “hover actions that are purely showing information, like tooltips, are not required to work with touch” (11:53); actions already easy by touch need no affordance, like a carousel’s scroll buttons, which “remain hidden during a touch interaction” (12:22) because “horizontal scroll is always possible via touch” (12:19); “only the most important hover actions relevant to that content should reveal themselves” (12:30), Safari showing exactly two when a page is touched (12:36); and “actions that appear on hover be duplicated elsewhere in your UI” (13:05), with Reminders’ share button living in the row’s context menu under touch (13:20).⁴

Scroll, long press, drag, text

Scrolling is one finger on the display and two on the trackpad (4:39).⁴ When one finger should draw instead of scroll, the AppKit talk sets “the decorating view’s enclosing scroll view to require two touches minimum for touch scrolling” (6:40); the property is NSScrollView.minimumNumberOfTouchesForScrolling, macOS 27.0, with maximumNumberOfTouchesForScrolling, isTouchScrollingEnabled and scrollGestureForRelationships beside it.³⁷ A recognizer that should lose to a scroll sets isCancellableByScrollGesture; “NSScrollView now supports pull-to-refresh functionality” through NSRefreshController; and on NSPanGestureRecognizer the pair minimumNumberOfTouches and maximumNumberOfTouches “replace numberOfTouchesRequired,” which is deprecated in 27.0.⁶⁷

A long press is the Mac’s touch for both drag and context menu, and AppKit arbitrates. “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).³ For menus, “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), and “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).³ The design talk shows the user’s view: the photo “scales up under my finger” (3:50), its context menu appears beside it (3:58), and dragging dismisses the menu (4:05); Shift and Option still work while dragging by touch (4:13).⁴ For custom views, beginDraggingSession(items:gesture:source:) starts “a drag from a gesture recognizer,” new in 27.0.⁶⁷

Text is the thin spot. The technote’s one sentence is “NSTextSelectionManager allows custom text engines to support standard text gestures,” and the class is documented as macOS 27.0 with the abstract “An object that coordinates text selection behavior for custom text views.”⁶⁷ The header fills in the contract (author analysis): the class “provides a centralized way to manage text selection interactions using a set of gesture recognizers,” with an interaction mode that is editable, selectable only, or non-interactive, a delegate that stores the selection, and a layout data source.⁷ Neither talk covers insertion points, selection handles or an editing menu under touch; the design talk’s selection guidance is about items, where “on macOS we recommend to allow modeless selection through click and tap” (2:42), single tap to select and double tap to open (3:10).⁴

System gestures, and the switch that is not documented

macOS claims a set of multi-finger gestures on the display, “controlled by macOS and are therefore not available to any app running” (8:05): three fingers up for Mission Control and down for App Exposé (8:13), a thumb-and-three-finger pinch to show apps and spread to reveal the desktop (8:22), three fingers left or right between spaces (8:32), swipes from the top and bottom edges for a hidden menu bar and Dock (8:37), a swipe over the Dynamic Island to invite Siri (8:46), and edge swipes for Notification Center and Control Center (8:51).⁴

The AppKit talk hits the conflict with three sliders: “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), and shows the switch: “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), with the warning “Only disable system gestures if the interaction capabilities they open up are critical for the window” (8:42).³ The talk page’s code listing names all three: disablesDirectTouchSystemGestures on NSWindow, prefersDirectTouchSystemGesturesDisabled on UIViewController, and directTouchSystemGesturesDisabled() on a SwiftUI View.³ None of the three is in Apple’s documentation on October 28; the JSON endpoints return 404 and the symbols are absent from the AppKit, UIKit and SwiftUI indexes.⁷ My reading, not Apple’s statement: they are the clearest sign that the SDK the talks assume is the one marked “Coming soon.”

SwiftUI and Mac Catalyst

SwiftUI gets one new type: “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 is documented on all seven platforms at 27.0, with .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 and .all, and inputKinds: parameters on onTapGesture, onLongPressGesture and the TapGesture, SpatialTapGesture, LongPressGesture, DragGesture, MagnifyGesture and RotateGesture initializers.⁷ The technote’s sentence is “Use GestureInputKinds to limit gestures to specific types of input in SwiftUI.”⁶

Mac Catalyst uses what UIKit has had since iOS 9: the talk says “UITouch.touchType and UIGestureRecognizer’s allowedTouchTypes” (0:59); the documented property is UITouch.type, with the enum UITouch.TouchType, and allowedTouchTypes is on UIGestureRecognizer at Mac Catalyst 13.1.³⁷ The talk’s wording is a slip, not a new API.

Live Activities on the Mac, ahead of the docs

The third talk is short and makes a large claim. “The Dynamic Island has come to the Mac. To fully take advantage of its capabilities, Mac apps now support native Live Activities” (0:05), and “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).⁵ Placement: “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).⁵ The code is the iOS code: the data model in ActivityAttributes (2:36), the compact and minimal presentations in ActivityConfiguration with the Dynamic Island view builder (3:24), the one Mac-specific presentation, “The menu bar expanded Live Activity view is created along with the ActivityConfiguration as a simple view” (3:52), while “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 that are immediate, scheduled or pushed (4:40), integration “with existing backgrounding technologies on the Mac, like background tasks and user agents” (4:54), actions through App Intents (5:56), and “If you have an iOS activity, there’s no code to port” (7:09).⁵ Two rules carry over from iOS: “Only a single Live Activity can be expanded at a time” (3:12), and “An activity is only expanded when interacted with or if explicitly triggered through an alert request” (3:06).⁵

Apple’s documentation does not say this yet. The ActivityKit framework page’s abstract names “the Mac,” but its Overview says “On Mac, it appears in the Menu bar,” its platform list is iOS, iPadOS and Mac Catalyst 16.1, and Activity, ActivityAttributes, ActivityConfiguration, DynamicIsland and the NSSupportsLiveActivities key list no macOS platform.⁸⁷ The HIG’s Live Activities page, whose change log ends at October 13, still describes the paired-iPhone path only: “Active Live Activities automatically appear in the Menu bar of a paired Mac,” “Clicking the Live Activity launches iPhone Mirroring to display your app,” and, under “macOS dimensions,” “Use the provided iOS dimensions.”¹⁰ The SDKs agree with the documentation, not the talk: in the macOS 27.0 SDK inside Xcode 27.1 and in the macOS 27.2 SDK inside the Xcode 27.2 beta (27B5019j), ActivityKit’s macOS interface marks ActivityAttributes, Activity, every request and update as @available(macOS, unavailable), checked on this Mac (author analysis). So the right sentence for a plan is the narrow one: the talk says the capability exists in macOS Golden Gate, and neither the documentation nor either SDK I checked lets you build it yet. The state-machine post shows an iOS implementation of the shared start, update and end model; the Mac’s own duration, dismissal and background limits are in no source yet.

Design: macOS does not change

The design talk’s closing rules are short enough to keep whole. “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).⁴

The one spatial rule is about hands, not poses. “The edges of the display are easy to touch by grabbing the side of the display with my hand” (6:17), so “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), while “the center of the display is best used for coarse, imprecise and big gestures” (6:46).⁴ Custom gestures have three constraints: “your gestures should work with touch and trackpad and possibly Magic Mouse” (7:00), “Avoid adding gestures that only work with touch” (7:05), and “The action your gesture does should be duplicated elsewhere in the UI, for example in a menu” (7:37).⁴ The talk also allows what the Mac never had: “macOS now allows multiple touch gestures at the same time” (5:30), Logic’s two sliders under two fingers being the example (5:45).⁴ That is the user’s side of the exclusivity property above: AppKit’s default keeps one view hierarchy at a time, and .notExclusive is how an app opens the rest.³⁶

Testing today: Sidecar, and the SDK that is not here

You do not need the laptop. “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), and “The fastest way to get started with touch on Mac is with the Sidecar tools you already own” (12:09).³ The technote requires the iPad to run iPadOS 27 and adds a caveat for the capability check (NSScreen.touchCapabilities, an option set with a .multiTouch bit): in macOS 27 the check “returns true for all displays when a touch-capable Sidecar display is connected, not just for the Sidecar display,” with the advice that “it’s better to handle events regardless of input source and decide on an alternate presentation based on the interaction type, if needed.”⁶⁷

The talk’s audit, in its own order: “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).³ There is also a skill: “there’s a gesture modernization skill that has an understanding of the features and changes I’ve talked about” (12:16); the landing page’s Xcode tile carries a placeholder comment, TK skill, and no source names it.²³

What the shipping SDKs contain, author analysis from the headers and Swift interfaces on this Mac: the macOS 27.0 SDK inside Xcode 27.1 (27A9275) declares NSScreen.TouchCapabilities, the five new NSControl event cases, the NSScrollView touch properties, NSRefreshController, beginDraggingSession(items:gesture:source:) and exclusiveGestureBehavior, all API_AVAILABLE(macos(27.0)), and the SwiftUICore macOS interface, which SwiftUI re-exports, declares GestureInputKinds. The three system-gesture switches are in neither that SDK nor the macOS 27.2 SDK inside the Xcode 27.2 beta (27B5019j), in AppKit’s headers, SwiftUI’s interface or the Mac Catalyst UIKit headers, and ActivityKit’s macOS interface in both marks its API unavailable.⁷⁸

Those are the two SDKs I checked; the Xcode 27.2 RC (27B48), which Apple’s releases feed dates October 19, is newer than that beta and was not checked, so the absences hold for the SDKs named and not beyond them.¹¹

What to install to test today, untested by me: macOS 27.2 (26B123, released October 26 per the feed) and the Xcode 27.2 RC, with an iPad on iPadOS 27 over Sidecar; the technote describes Sidecar touch as working in macOS 27, and the feed lists no macOS 27.3 beta on October 28.⁶¹¹ One caveat from the RC’s own notes: “macOS, watchOS, tvOS, and visionOS SDKs in Xcode 27.2 incorrectly report 27.1 as a valid deployment target,” and “Mac Catalyst builds with a 27.1 or 27.2 deployment target might be unable to use newly introduced API,” so do not pick 27.1 as a macOS deployment target (the releases feed lists macOS 27.0.1 and 27.2 and no macOS 27.1), and read a Mac Catalyst target at 27.1 or 27.2 that cannot see a new API as this known issue rather than a missing symbol.¹¹

What is not here, then: the Xcode 27.3 beta the landing page promises, the AppKit article it links, the three system-gesture symbols and a macOS-available ActivityKit (absent from the two SDKs checked, unverified in the 27.2 RC), and any statement about a simulator. The Xcode 27.2 RC notes mention touch once, as a Device Hub fix for input that stopped “after a period of inactivity,” and the macOS 27.2 notes have no touch, gesture or Live Activities entry.¹¹ The touch APIs shipped with Xcode 27.1, the rules are published, and the landing page marks what comes next “Coming soon.”

A touch audit for any Mac app

Author analysis, not Apple’s guidance: the talk’s four steps, in order, as a checklist. No runtime testing stands behind it yet.

1. Sidecar with an iPad on iPadOS 27, on the newest macOS and Xcode (macOS 27.2 and the Xcode 27.2 RC), and every screen of the app touched before anything is changed.
2. A search for mouseDown(with:) overrides and nextEvent(matching:) loops, each one assigned to control events, a delegate method, or a gesture recognizer.
3. A pass over small controls and hit areas, with the touch area enlarged where it helps and no layout change; the talk allows a smaller control as long as touch still works on it.
4. A list of everything that appears on rollover, with a decision per item: a tooltip stays mouse-only; an action already easy by touch needs nothing; an essential control gets a touch-only click recognizer and a home elsewhere in the UI, such as a context menu.

The one thing the audit will not produce is a redesign, because the design talk’s first rule is that there should be no visual distinction; the only layout that may change with the input is a transient one, a popover or a custom menu.

What Apple has not said

Each of these is a question the sources leave open, checked against the release, the landing page, the three talks, the technote, the specifications page, the Xcode 27.2 RC and macOS 27.2 notes, and the four HIG pages.

• Which macOS point release carries Touch on the built-in display, and which SDK carries the three undocumented symbols. The release says “macOS 27” and names macOS 27.2 only in its Siri AI footnote; the landing page says “Xcode 27.3 beta,” “Coming soon.”
• Whether a binary built against an older SDK gets the same touch behavior as one rebuilt with the macOS 27 SDK. The talk says “all apps”; the technote keys only the location(in:) change to the new SDK.
• Apple Pencil or pressure on the display, and whether the glass senses a finger before it touches. The talks address the absence of a mouse-like hover state; no source mentions a pencil, pressure, or proximity sensing, and GestureInputKinds.pencil is listed for macOS 27.0 like every other member, while no source says the display senses a pencil.⁷
• Touch on external displays or in clamshell mode, and whether users can turn Touch off.
• Text editing by touch: insertion points, handles, a loupe, and the editing menu.
• Accessibility with the touch display. The specifications page lists AssistiveTouch and Touch Accommodations among the laptop’s features and does not say whether they are new to the Mac.⁹
• How a “Designed for iPad” app receives touches on the Mac display, and whether that differs from Mac Catalyst.
• A simulator or Device Hub path for Mac touch without an iPad.
• Web content: whether WKWebView and Safari deliver touch or pointer events to pages.
• How windows and full-screen content relate to the Dynamic Island, and which safe-area API reports it.
• Live Activities specifics on macOS: the point release and SDK, whether NSSupportsLiveActivities is required, how push-to-start and APNs registration work on the Mac, and dimensions for a Mac-native activity.

The calendar

• October 28: pre-orders in 30 countries and regions; the developer page and three talks; the technote has been up since June 8.¹²⁶
• November 6: the laptop reaches customers and stores.¹
• November 18, 9 to 10 a.m. PT, and November 19, 6 to 7 p.m. PT: Touch on Mac Group Labs, online, with Apple engineers and designers.²
• “Coming soon”: the Xcode 27.3 beta, the documentation resources, the design resources.²
• This November: the Apple Creator Studio update whose Logic Pro and Final Cut Pro touch features the release describes; the third-party apps it names “will be available later this year.”¹

Key Takeaways

For AppKit developers: standard controls are touch native now; your custom mouseDown(with:) code is emulated until you move to control events or gesture recognizers, and a touch-only NSPanGestureRecognizer with buttonMask = 0 and allowedTouchTypes = .direct is the dot-release path the talk recommends; the APIs are in the macOS 27.0 SDK you already have.³⁷

For SwiftUI and Catalyst developers: your gestures already work; GestureInputKinds is the one new SwiftUI type, and Catalyst’s answer is UITouch.type and allowedTouchTypes.³⁷

For designers: 36 points, invisible; no redesign; essential hover actions reachable by touch and placed elsewhere in the UI too, such as a context menu, with tooltips exempt; dense UI at the edges, coarse gestures in the center.⁴

For planning: test on Sidecar now; before building anything that disables system gestures or creates a Mac-native Live Activity, confirm that the installed SDK declares those APIs, since the two SDKs inspected here do not and the Xcode 27.2 RC is unverified; the next SDK Apple has promised is the Xcode 27.3 beta.²⁷⁸

FAQ

Does my existing Mac app work with Touch?

Apple says yes for most apps: “many existing apps work with Touch right away, because macOS automatically translates touches into clicks,” and the AppKit talk says standard AppKit, SwiftUI and Mac Catalyst components and existing gestures “just work.”¹³ Custom mouse-tracking code is emulated until it moves to control events or gesture recognizers; a non-Apple UI framework gets a generic emulation layer that NSIsTouchNative turns off once the app handles touch itself.³⁶

How do I receive a direct touch in AppKit?

With a gesture recognizer. The talk says “gesture recognizers are the only way to get direct touches on macOS,” and the technote says touch events do not go through the responder chain, event monitors, NSApp or sendEvent(_:).³⁶ A touch-only recognizer sets buttonMask to 0 and allowedTouchTypes to .direct.³

What is the touch target on macOS?

36 points, “the same physical size on display as iOS’s 44 points.” Framework controls already meet it without changing size; expand the hit area of custom views rather than the view.⁴³

How do I test Touch without the new MacBook Pro?

Connect an iPad running iPadOS 27 over Sidecar. The talk’s condition is “With the latest macOS beta and developer tools” (11:59), and no macOS 27.3 beta is out, so the configuration I would try is macOS 27.2 with the Xcode 27.2 RC, untested by me.³⁶¹¹

Are the touch APIs in the SDK today?

Yes, for everything the talks demonstrate except the system-gesture switches and Mac-native Live Activities, which are absent from the two SDKs inspected here (the Xcode 27.2 RC was not inspected). The macOS 27.0 SDK inside Xcode 27.1 declares NSScreen.TouchCapabilities, the new NSControl event cases, the NSScrollView touch properties, NSRefreshController, exclusiveGestureBehavior and the gesture-based dragging session, and SwiftUICore’s interface declares GestureInputKinds; Apple’s documentation lists them as macOS 27.0 with no beta flag.⁷ The window, view-controller and view switches for system gestures are in neither the documentation nor the Xcode 27.1 or 27.2 beta SDKs, ActivityKit marks its API unavailable on macOS in both, and the landing page marks the Xcode 27.3 beta “Coming soon.”²⁷⁸

Can a Mac app create Live Activities?

The talk says yes in macOS Golden Gate, with the same ActivityKit and WidgetKit code as iOS and a menu bar presentation on Macs without a Dynamic Island.⁵ ActivityKit’s documentation and the HIG do not list macOS as a platform for app-created activities yet, they describe the paired-iPhone menu bar path, and the ActivityKit interface in the Xcode 27.1 and 27.2 beta SDKs marks the API unavailable on macOS.¹⁰⁸

Where do the facts in this post come from?

The release, the developer news post and landing page, the three Tech Talks’ English subtitle tracks with the first cue of each quotation in parentheses, the June technote, Apple’s documentation JSON for every symbol named, the specifications page, the Xcode 27.2 RC and macOS 27.2 release notes, and the four HIG pages, all fetched October 28, 2026, plus the headers and Swift interfaces of the macOS 27.0 and 27.2 beta SDKs on my Mac, which is author analysis. Press coverage is not a source.

Sources