開發者眼中的 Touch on Mac：36 點、手勢辨識器與 Sidecar

Mac 上的觸控為 Mac 開發者改變了什麼？ 現有的 app 照樣能用，因為「macOS automatically translates touches into clicks」（macOS 會自動把觸控轉成點按）；三場 Tech Talks 定下了規則：手勢辨識器是「the only way to get direct touches on macOS」（在 macOS 上取得直接觸控的唯一途徑），標準控制項原生支援觸控，觸控目標是 36 點，懸停沒有對應的觸控操作，而透過 Sidecar 連接的 iPad 就是測試設備。¹²³⁴ 觸控 API 已經在 macOS 27.0 SDK 裡；系統手勢的開關與可在 macOS 上使用的 ActivityKit 則不在我檢查過的兩個 SDK 裡，而 Xcode 27.3 beta 仍標示「Coming soon」。²⁵⁶⁷⁸

TL;DR： Apple 發表了支援觸控的 MacBook Pro with PROLED XDR Display（14.2 吋與 16.3 吋，10 月 28 日開放預購，11 月 6 日上架門市），並在 10 月 28 日以三場議程告訴開發者如何採用。¹²⁹ 如果您的 app 使用標準 AppKit 控制項、SwiftUI 手勢或 Mac Catalyst，議程說它們「just work」（直接就能用），但下方的稽核（點按目標、懸停）依然適用。自訂的 mouseDown(with:) 程式碼會以模擬方式運作，直到改用控制項事件或手勢辨識器為止；非 Apple 的 UI 框架則會套上一層通用的模擬，等 app 自行處理觸控後，再以 NSIsTouchNative 關閉。³⁶ 要在 AppKit 中接收直接觸控，必須使用手勢辨識器，因為觸控永遠不會進入回應者鏈（responder chain）或事件監視器。³⁶ 設計議程把觸控目標定為 36 點，實體尺寸與 iOS 的 44 點相同，並說明 macOS 有沒有觸控，外觀都一樣。⁴ 請用透過 Sidecar 連接的 iPad 測試；最新的組合是 macOS 27.2 與 Xcode 27.2 RC，這個設定我還沒有實際跑過。³¹¹ 觸控 API 已經在 macOS 27.0 SDK 裡。系統手勢的開關與可在 macOS 上使用的 ActivityKit，在我檢查過的兩個 SDK 裡都不存在，而 Xcode 27.3 beta 仍標示「Coming soon」。²³⁷⁸

Apple 公布了什麼，又沒有公布什麼

Apple 這次以新聞稿發表，而非主題演講；當天的即時貼文保留了一整天的紀錄。新聞稿中給開發者的內容只有「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」（Apple 的 app 已針對新款 MacBook Pro 最佳化，許多現有 app 也能立即支援觸控，因為 macOS 會自動把觸控轉成點按），接著是「Updated system gesture APIs also enable developers to create intuitive experiences designed specifically for Touch」（更新後的系統手勢 API 讓開發者能打造專為觸控設計的直覺體驗），以及「app developers can test how Touch performs in their iOS and iPadOS apps directly on the MacBook Pro display」這則說明（開發者可以直接在 MacBook Pro 的螢幕上測試 iOS 與 iPadOS app 的觸控表現）。¹ 談 macOS 的那一節說這台筆電「comes to life with macOS 27」，並點名「Touch built for macOS 27」；它沒有指明是哪一個小版本。¹

開發者這邊在上午 11 點 47 分（PT）之前就已上線：一則新聞貼文「Say hello to Touch on Mac」，以及一個登陸頁面「Get ready for Touch on Mac」，上面有三場 Tech Talks、11 月 18 日與 19 日的 Group Labs，以及三個標示「Coming soon」的區塊：「Xcode 27.3 beta」、「Documentation resources」與「Design resources」。² 頁面的 HTML 在註解中保留了 Apple 打算在資源上線時掛到這些區塊上的連結，這些註解標明會在資源上線時重新啟用：一篇 AppKit 文章「Adopting gesture recognizers in your app」，目前回傳 404；既有的 file promises 拖放範例；以及連結中的四個 Human Interface Guidelines 頁面與 Apple Design Resources。我抓取的 HIG 頁面都沒有關於 Mac 螢幕觸控的指引，而 Live Activities 頁面的變更記錄停在 10 月 13 日。²⁷¹⁰

因此，規則的一手來源是這些議程，以及 Apple 在 6 月 8 日發布的一份技術說明「TN3212: Adopting gesture recognizers for Sidecar touch support」。它的 Overview 說「In macOS 27, AppKit continues to standardize on gesture recognizers as the primary mechanism for input handling」（在 macOS 27 中，AppKit 持續以手勢辨識器作為輸入處理的主要機制），而「Explore updated APIs in macOS 27」、「Detect touch capability」、「Handle control events」與「Configure scroll behavior」這幾節，描述的正是 10 月 28 日議程所示範的 API 範圍。⁶ 技術說明點名的每一個新符號，在 Apple 文件中都標為 introducedAt macOS 27.0、沒有 beta 標記（10 月 28 日中午 PT 抓取）；除了兩個 Info.plist 鍵之外，它們也都宣告在 Xcode 27.1（27A9275）內的 macOS 27.0 SDK 中，這是我在這台 Mac 上檢查標頭檔與 Swift 介面的結果（作者分析）。⁷ 議程點名的三個系統手勢符號則不在其中，可在 macOS 上使用的 ActivityKit 也不在；兩者都在下文說明。

什麼都不用做，以及因此得到什麼

相容性方面相當寬厚。AppKit 議程一開場就說：「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）（所有 app 開箱即可良好支援觸控，原生框架的標準元件與 SwiftUI 既有手勢都直接可用），Mac Catalyst 也一樣（0:52）。³ 在 AppKit 中，「Standard buttons, controls, tables, collections, split views, tabs, scrolling, and more are all touch native」（1:10）。³

非原生的部分則以模擬處理：「for existing custom AppKit mouse interactions, or if you use non-Apple UI frameworks, AppKit intelligently emulates the mouse」（1:17）（對於既有的自訂滑鼠互動或非 Apple UI 框架，AppKit 會智慧地模擬滑鼠）。³ 技術說明把第三方框架的模擬方式寫得很清楚：「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」，以及「A two-finger pinch or rotation simultaneously emulates both the trackpad magnify and rotate gestures」（點一下對應滑鼠按下再放開，觸控後立即平移對應觸控式軌跡板捲動，不動的長按對應右鍵，雙指捏合或旋轉則同時對應軌跡板的縮放與旋轉）。⁶ 議程的版本是：「a one-finger scroll with momentum, click, drag with a small hold delay, and even pinch for rotation and magnification」（11:28）。³ 這種模擬以視窗為單位，而且是通用的，因為「AppKit can’t determine what kind of interactions are allowed at any particular location of your non-Apple UI framework content」（11:17）（AppKit 無法判斷非 Apple UI 框架內容的某個位置允許哪種互動）。³

當您加入原生支援後，就可以關掉模擬：「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）。³ 這個鍵在文件中標為 macOS 27.0，頁面上寫著「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.」（大多數 AppKit app 不需要這個鍵，它主要是給內嵌非 AppKit 算繪或輸入框架、自行實作觸控處理流程的 app 使用。）⁷

設計議程的框架，決定了「什麼都不用做」在視覺上的意義：「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），以及「Touch is a secondary input for macOS, and therefore has little impact on how macOS looks」（1:06）（觸控是 macOS 的次要輸入，因此幾乎不影響 macOS 的外觀）。⁴ 沒有觸控模式，也沒有緊湊版面。這與 iPhone Duo 的情況正好相反，在那裡，內螢幕在兩個維度都回報 regular size class。

手勢辨識器是唯一的入口

統攝其餘一切的那句話，出現在 AppKit 議程的 3:45：「In fact, gesture recognizers are the only way to get direct touches on macOS.」（事實上，手勢辨識器是在 macOS 上取得直接觸控的唯一途徑。）³ 在那之前是：「Starting with macOS Golden Gate, gesture recognizers are the preferred approach in AppKit」（3:33），以及「gesture recognizers have become the shared input language across SwiftUI, Mac Catalyst, and now AppKit」（3:38）。³ 技術說明從另一個方向說了同一件事：「AppKit doesn’t deliver Sidecar touch events through the responder chain or through event monitors」，並在一則附註中寫道：「Local and global event monitors don’t receive touch events. Touch events don’t go through NSApp or sendEvent(:).」（本機與全域事件監視器都收不到觸控事件，觸控事件也不經過 NSApp 或 sendEvent(:)。）⁶

這對 AppKit 程式碼庫有三個影響。

第一，追蹤迴圈。議程中的工程師重寫了一個接線拼圖，原本用的是「a custom NSView with a mouseDown(with:) override that uses the standard tracking loop technique」（3:13），呼叫 nextEvent(matching:) 直到滑鼠放開為止；他說：「Migrate your mouse tracking loops to gesture recognizers」（3:51）。³ 遷移不必一次到位：「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）（追蹤迴圈仍受支援，可以與僅限觸控的手勢辨識器並存；對 app 的小版本更新而言，加上僅限觸控的辨識器可能是最快、風險最低的做法）。³ 第一步是議程在加入任何東西之前先做的重構：「The first step is to refactor my tracking loop into separate start, continue, end, and cancel tracking functions」（4:11），讓滑鼠迴圈與觸控辨識器可以共用這些函式。³ Apple 的程式碼清單，原文照錄：

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

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

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

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

接下來，僅限觸控的辨識器只需要兩個屬性設定：「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)

動作方法把辨識器的 .began、.changed、.ended 與 .cancelled 狀態分派給那四個函式。需要取消路徑的理由，與議程談按鈕時給的理由相同：「If tracking is canceled due to a system gesture like Exposé, scroll, or any other reason, I can revert any unintended changes」（2:41）（如果追蹤因 Exposé、捲動等系統手勢或其他原因被取消，我可以還原非預期的變更），而技術說明的規則是「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 早在 macOS 10.10 就已存在，allowedTouchTypes 則始於 10.12.2；這份做法裡沒有任何新東西。⁷

第二，辨識器帶來的規則。技術說明寫道：「If your view is covered by another, often transparent, view, your gesture recognizer won’t be triggered」，以及「You can’t place views on top of standard framework controls, because those controls now use gesture recognizers internally」（被其他視圖覆蓋時辨識器不會觸發，也不能把視圖疊在標準控制項上），並給出它自己的解法：「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.」⁶ 自訂辨識器必須結束：「End your active gesture recognizer by transitioning to ended, failed, or cancelled. If you don’t, recognizers are blocked from activating.」（若不轉換到 ended、failed 或 cancelled，辨識器就會被擋下而無法啟動。）⁶ 還有一項只影響以新 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」，因為「Subclasses of NSGestureRecognizer must implement location(in:) to report a meaningful location.」⁶

第三，您會失去什麼。關於控制項動作，技術說明指出 NSControl 改用辨識器後「changes the timing of when AppKit delivers control action messages with respect to event processing」（改變了動作訊息相對於事件處理的送達時機），因此 currentEvent「no longer returns the event that triggered an action」，並建議改用 NSEvent.pressedMouseButtons 與類別層級的 modifierFlags，同時補充「a touch is not part of pressedMouseButtons」。⁶ 而覆寫左鍵方法的子類別要付出代價：「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.」（為了相容，該控制項會退回追蹤迴圈路徑。）⁶

控制項：以事件取代 mouseDown

AppKit 議程的第一個重構對象是一個按鈕。原本的做法是繼承 NSButton 並覆寫 mouseDown(with:)，以得知追蹤何時開始與結束；在觸控下，「the buttons work, but AppKit must emulate mouse events to pass to the mouseDown override」（2:17）（按鈕能用，但 AppKit 必須模擬滑鼠事件再傳給覆寫的 mouseDown）。³ 替代做法是 NSControl 事件，「directly on NSButton without the need to subclass」（2:27）；議程頁面 2:24 的程式碼清單在按鈕上註冊了三個 addTarget(_:action:for:) 呼叫，分別對應 [.trackingBegan, .trackingEntered]、[.trackingExited, .trackingEndedInside] 與 .trackingCancelled，而這些事件也揭露了滑鼠覆寫從來看不到的狀態：「If tracking is canceled due to a system gesture like Exposé, scroll, or any other reason, I can revert any unintended changes」（2:41）。³ 這些事件並不新：「NSControl events are available for standard AppKit controls, and most control events are available all the way back to macOS 11」（2:51）（大多數控制項事件一路回溯到 macOS 11 都可用）。³ 議程指向一場它稱為「Modernizing your AppKit app」的 WWDC26 議程來說明這個模式；技術說明列為相關影片的議程則是「Modernize your AppKit app」（WWDC26 session 289）。³⁶

依技術說明的「Handle control events」一節，macOS 27 為 NSControl.Events 新增了幾個 case：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」），以及留給您自行使用的 applicationReserved。⁶⁷

接著是排他性。「By default, only one view can be interacted with at a time」（7:20）（預設一次只能與一個視圖互動），議程稱之為手勢排他性，技術說明則以相容性來解釋：「For maximum compatibility, AppKit restricts gesture activations to a single view hierarchy at a time」，以及「Unlike in iOS, the person can’t perform multiple interactions simultaneously, though scrolling is a notable exception.」（與 iOS 不同，使用者無法同時進行多項互動，捲動是明顯的例外。）³⁶ 您可以逐一視圖退出：「The API to control gesture exclusivity is the exclusiveGestureBehavior property on NSView」（7:48）。這個屬性的預設值「inherits its parent’s exclusive gesture behavior」（7:57），而「By setting the exclusiveGestureBehavior property on the stove view to .notExclusive, the child slider subviews all become non-exclusive as well」（8:01）（把爐台視圖設為 .notExclusive 後，其下的滑桿子視圖也全部變成非排他）；整個 app 則可以用 NSViewGestureRecognizerIsExclusive 這個 Info.plist 鍵退出。³⁶⁷ 議程說這個屬性「is available in the next SDK」（7:54）。Apple 文件把它列為 macOS 27.0、沒有 beta 標記，6 月的技術說明已經描述了它，而 Xcode 27.1 內的 macOS 27.0 SDK 在 NSView.h 中把它宣告為 API_AVAILABLE(macos(27.0))，並附上註解「Defaults to .inherit」；所以議程口中的「next」SDK，其實早已出貨（依已安裝的標頭檔所做的作者分析）。³⁶⁷

36 點

設計議程三度提到這個數字，AppKit 議程又重複了一次。「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）（macOS 的觸控目標是 36 點，在螢幕上的實體尺寸與 iOS 的 44 點相同）。⁴ 這個目標刻意設計成看不見：「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）（框架控制項都已改用新觸控目標，但它看不見，控制項尺寸不變，因此不需要新版面）。⁴

對自訂視圖的指示是擴大點按區域，而不是放大控制項。AppKit 議程中的接線節點「a little tricky to touch」（5:14），所以工程師加了一個 expandHitRect 參數，它「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）（把目標矩形在每個軸向擴大到至少 36 點，讓觸控更容易點中節點，滑鼠仍須精準，版面也不必更動）；他推薦把這個技巧用在「for small resize or grab handles for selected objects in a canvas view」（6:07）。³ 設計議程針對非 Apple 控制項的版本是：「consider increasing the touch target area around your control instead of changing the control size」（9:51）。⁴

控制項尺寸不變。「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）（檢閱器等控制項密集的區域仍以中型為預設，視窗工具列預設使用特大型，大型與特大型控制項不應用在工具列以外），以及「They should only be used sparingly to emphasize key moments or in apps of which content consumption is the primary use case」（10:14）。⁴ 對類似設定的視圖，「use FormStyle. Here as well, each row by default measures the 36-point height」（10:28）。⁴ 小型與迷你控制項仍然可以使用：「They fully support touch regardless of their size」（10:46），自訂的則有一條規則：「If your app is using custom small controls, ensure touch works, even though the tap target might be small」（10:50），因為「touch events should never be ignored」（11:00）（觸控事件絕不應被忽略）。⁴

對於無法做到 36 點的三種控制項，框架承擔了困難的部分：「the stepper, dial, and slider」（13:54）「now expand in place when interacting via touch」（14:07）（以觸控操作時會原地放大），放大的那一下點按不會改變它們的值（14:26），而且會「collapse themselves when I’m not interacting with them」（14:41）；滑桿則是選項，因為「sliders have the option to expand when presented small」（15:36）。⁴ 選單也會調整：「when using touch, the menu shows slightly larger rows to help make selection easier」（11:23），短暫出現的視圖也可以：「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）（彈出視窗或自訂選單等短暫呈現的視圖，可以依叫出它們的輸入方式略微調整版面）。⁴

懸停消失了

「Direct touches don’t have an equivalent to mouseMoved events」（10:38）（直接觸控沒有對應 mouseMoved 的事件），所以凡是滑過才會出現的東西，都需要做出決定。³ AppKit 議程的規則是：「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），以及「for hidden essential controls, install a touch-only click gesture recognizer to temporarily show the element on a touch tap」（10:57）（不要因此永久顯示隱藏的控制項，工具提示之類的靜態資料不應因觸控而顯示，對於隱藏的重要控制項，則安裝僅限觸控的點按手勢辨識器，在點一下時暫時顯示）。³ 技術說明確認指標的路徑不受影響：「Hovering via mouseMoved(with:) is still managed with NSTrackingArea.」⁶

設計議程從使用者的角度給出相同的規則。「hover actions that are purely showing information, like tooltips, are not required to work with touch」（11:53）；以觸控本來就容易完成的動作不需要額外的提示，例如輪播的捲動按鈕，它們「remain hidden during a touch interaction」（12:22），因為「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 在頁面被觸碰時剛好顯示兩個（12:36）；以及「actions that appear on hover be duplicated elsewhere in your UI」（13:05）（懸停時出現的動作應在 UI 其他地方重複提供），例如在觸控下，「提醒事項」的分享按鈕放在該列的情境選單裡（13:20）。⁴

捲動、長按、拖曳、文字

捲動在螢幕上是一根手指，在觸控式軌跡板上是兩根（4:39）。⁴ 當一根手指應該用來繪圖而非捲動時，AppKit 議程把「the decorating view’s enclosing scroll view to require two touches minimum for touch scrolling」（6:40）（裝飾視圖外層的捲動視圖設為觸控捲動至少需要兩指）；對應的屬性是 NSScrollView.minimumNumberOfTouchesForScrolling，macOS 27.0，旁邊還有 maximumNumberOfTouchesForScrolling、isTouchScrollingEnabled 與 scrollGestureForRelationships。³⁷ 應該讓位給捲動的辨識器會設定 isCancellableByScrollGesture；「NSScrollView now supports pull-to-refresh functionality」，透過 NSRefreshController 實現；而在 NSPanGestureRecognizer 上，minimumNumberOfTouches 與 maximumNumberOfTouches 這一對「replace numberOfTouchesRequired」，後者在 27.0 已被棄用。⁶⁷

在 Mac 上，長按同時是拖曳與情境選單的觸控操作，由 AppKit 來仲裁。「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）（可拖曳的項目被長按時，應以浮起動畫暗示它可以拖曳；要取得這個預覽，請使用既有的拖放代理 API）。³ 至於選單，「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），以及「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）（同時使用選單 API 與拖放代理 API 時，AppKit 會協調長按何時變成拖放、何時變成情境選單，甚至讓使用者在兩者之間切換）。³ 設計議程呈現了使用者看到的樣子：照片「scales up under my finger」（3:50），情境選單出現在它旁邊（3:58），一拖曳選單就消失（4:05）；以觸控拖曳時，Shift 與 Option 依然有效（4:13）。⁴ 對自訂視圖而言，beginDraggingSession(items:gesture:source:) 會開始「a drag from a gesture recognizer」，這是 27.0 新增的。⁶⁷

文字是薄弱之處。技術說明只有一句：「NSTextSelectionManager allows custom text engines to support standard text gestures」，而這個類別在文件中標為 macOS 27.0，摘要是「An object that coordinates text selection behavior for custom text views.」⁶⁷ 標頭檔補上了契約的內容（作者分析）：這個類別「provides a centralized way to manage text selection interactions using a set of gesture recognizers」，具備可編輯、僅可選取或不可互動三種互動模式，一個儲存選取範圍的代理，以及一個版面資料來源。⁷ 兩場議程都沒有談到觸控下的插入點、選取控點或編輯選單；設計議程的選取指引談的是項目，「on macOS we recommend to allow modeless selection through click and tap」（2:42），點一下選取，點兩下開啟（3:10）。⁴

系統手勢，以及那個沒有文件的開關

macOS 在螢幕上保留了一組多指手勢，它們「controlled by macOS and are therefore not available to any app running」（8:05）（由 macOS 控制，任何 app 都無法使用）：三指上滑開啟 Mission Control、下滑開啟 App Exposé（8:13），拇指加三指捏合顯示 app、張開則顯示桌面（8:22），三指左右滑動切換空間（8:32），從頂端與底端邊緣滑動叫出隱藏的選單列與 Dock（8:37），在 Dynamic Island 上滑動叫出 Siri（8:46），以及從邊緣滑動叫出通知中心與控制中心（8:51）。⁴

AppKit 議程用三個滑桿撞上了這個衝突：「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）（同時往同一方向操作三個以上的滑桿，觸發的反而是系統手勢），並展示了開關：「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），附帶警告「Only disable system gestures if the interaction capabilities they open up are critical for the window」（8:42）（只有在停用後開放的互動能力對該視窗至關重要時，才停用系統手勢）。³ 議程頁面的程式碼清單點名了全部三個：NSWindow 上的 disablesDirectTouchSystemGestures、UIViewController 上的 prefersDirectTouchSystemGesturesDisabled，以及 SwiftUI View 上的 directTouchSystemGesturesDisabled()。³ 在 10 月 28 日，這三個都不在 Apple 文件裡；JSON 端點回傳 404，這些符號也不在 AppKit、UIKit 與 SwiftUI 的索引中。⁷ 這是我的解讀，不是 Apple 的說法：它們是最清楚的跡象，顯示議程所預設的 SDK，就是標示「Coming soon」的那一個。

SwiftUI 與 Mac Catalyst

SwiftUI 只多了一個新型別：「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 手勢修飾器 API）。³ GestureInputKinds 在全部七個平台上都以 27.0 列入文件，成員有 .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 與 .all；onTapGesture、onLongPressGesture，以及 TapGesture、SpatialTapGesture、LongPressGesture、DragGesture、MagnifyGesture 與 RotateGesture 的初始化方法，都多了 inputKinds: 參數。⁷ 技術說明的那句話是「Use GestureInputKinds to limit gestures to specific types of input in SwiftUI.」⁶

Mac Catalyst 使用的是 UIKit 從 iOS 9 就有的東西：議程說的是「UITouch.touchType and UIGestureRecognizer’s allowedTouchTypes」（0:59）；文件中的屬性是 UITouch.type，列舉為 UITouch.TouchType，而 allowedTouchTypes 在 UIGestureRecognizer 上，標為 Mac Catalyst 13.1。³⁷ 議程的措辭是口誤，不是新的 API。

Mac 上的 Live Activities，走在文件前面

第三場議程很短，卻提出了一個很大的主張。「The Dynamic Island has come to the Mac. To fully take advantage of its capabilities, Mac apps now support native Live Activities」（0:05）（Dynamic Island 來到了 Mac，Mac app 現在原生支援 Live Activities），以及「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）（已有 Live Activities 的通用 app 不需改程式碼就能在 Mac 上運作，原生 macOS app 則可直接透過 API 建立）。⁵ 位置方面：「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）（有 Dynamic Island 的 Mac 上，Live Activities 融入裝置頂端邊緣，其他裝置與螢幕上則顯示在選單列）。⁵ 程式碼就是 iOS 的程式碼：資料模型在 ActivityAttributes 中（2:36），緊湊與最小呈現在 ActivityConfiguration 中，搭配 Dynamic Island 的 view builder（3:24）；唯一專屬 Mac 的呈現是「The menu bar expanded Live Activity view is created along with the ActivityConfiguration as a simple view」（3:52），而「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）；啟動可以是立即、排程或推播（4:40）；與「with existing backgrounding technologies on the Mac, like background tasks and user agents」（4:54）整合；動作透過 App Intents 處理（5:56）；以及「If you have an iOS activity, there’s no code to port」（7:09）（已有 iOS 活動，就沒有程式碼需要移植）。⁵ 有兩條規則沿用自 iOS：「Only a single Live Activity can be expanded at a time」（3:12），以及「An activity is only expanded when interacted with or if explicitly triggered through an alert request」（3:06）（活動只有在互動時或由提醒請求明確觸發時才會展開）。⁵

Apple 的文件還沒有這麼說。ActivityKit 框架頁面的摘要點名了「the Mac」，但它的 Overview 寫的是「On Mac, it appears in the Menu bar」，平台清單是 iOS、iPadOS 與 Mac Catalyst 16.1，而 Activity、ActivityAttributes、ActivityConfiguration、DynamicIsland 與 NSSupportsLiveActivities 鍵都沒有列出 macOS 平台。⁸⁷ HIG 的 Live Activities 頁面（變更記錄停在 10 月 13 日）仍然只描述配對 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」，以及在「macOS dimensions」標題下的「Use the provided iOS dimensions」。¹⁰ SDK 與文件一致，而非與議程一致：在 Xcode 27.1 內的 macOS 27.0 SDK，以及 Xcode 27.2 beta（27B5019j）內的 macOS 27.2 SDK 中，ActivityKit 的 macOS 介面把 ActivityAttributes、Activity、每一個 request 與 update 都標為 @available(macOS, unavailable)，這是我在這台 Mac 上檢查的結果（作者分析）。因此，寫進計畫裡的正確說法是較窄的那一句：議程說這項能力存在於 macOS Golden Gate，而文件與我檢查過的兩個 SDK 都還不能讓您把它建置出來。狀態機那篇文章展示了共用的啟動、更新與結束模型在 iOS 上的實作；Mac 自己的持續時間、解除與背景限制，目前沒有任何來源提及。

設計：macOS 不會改變

設計議程的收尾規則短到可以全文保留。「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）（不要只為了支援觸控而重新設計 app，在支援與不支援觸控的 Mac 上，app 外觀應無區別）。「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 edges of the display are easy to touch by grabbing the side of the display with my hand」（6:17），所以「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），而「the center of the display is best used for coarse, imprecise and big gestures」（6:46）（螢幕邊緣適合放檢閱器、側邊欄等密集 UI，中央則適合粗略的大手勢）。⁴ 自訂手勢有三項限制：「your gestures should work with touch and trackpad and possibly Magic Mouse」（7:00）、「Avoid adding gestures that only work with touch」（7:05），以及「The action your gesture does should be duplicated elsewhere in the UI, for example in a menu」（7:37）。⁴ 議程也允許了 Mac 從未有過的東西：「macOS now allows multiple touch gestures at the same time」（5:30），例子是 Logic 中兩根手指各控制一個滑桿（5:45）。⁴ 這就是上文排他性屬性在使用者這一端的樣子：AppKit 預設一次只讓一個視圖階層互動，而 .notExclusive 是 app 打開其餘部分的方式。³⁶

現在就能測試：Sidecar，以及尚未到來的 SDK

您不需要那台筆電。「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）（只要有最新的 macOS beta 與開發者工具，透過 Sidecar 連接的 iPad 就能提供觸控螢幕 Mac 的所有觸控功能），以及「The fastest way to get started with touch on Mac is with the Sidecar tools you already own」（12:09）。³ 技術說明要求 iPad 執行 iPadOS 27，並為能力檢查（NSScreen.touchCapabilities，一個帶有 .multiTouch 位元的 option set）加上一項但書：在 macOS 27 中，這項檢查「returns true for all displays when a touch-capable Sidecar display is connected, not just for the Sidecar display」（連接支援觸控的 Sidecar 螢幕時，所有螢幕都會回傳 true），並建議「it’s better to handle events regardless of input source and decide on an alternate presentation based on the interaction type, if needed」。⁶⁷

議程的稽核步驟，依它自己的順序：「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）。³ 另外還有一個 skill：「there’s a gesture modernization skill that has an understanding of the features and changes I’ve talked about」（12:16）（有一個了解這些功能與變更的手勢現代化 skill）；登陸頁面的 Xcode 區塊帶著一則占位註解 TK skill，沒有任何來源點名它。²³

已出貨的 SDK 裡有什麼，以下是依這台 Mac 上的標頭檔與 Swift 介面所做的作者分析：Xcode 27.1（27A9275）內的 macOS 27.0 SDK 宣告了 NSScreen.TouchCapabilities、五個新的 NSControl 事件 case、NSScrollView 的觸控屬性、NSRefreshController、beginDraggingSession(items:gesture:source:) 與 exclusiveGestureBehavior，全部標為 API_AVAILABLE(macos(27.0))；而由 SwiftUI 重新匯出的 SwiftUICore macOS 介面宣告了 GestureInputKinds。三個系統手勢開關則既不在那個 SDK 裡，也不在 Xcode 27.2 beta（27B5019j）內的 macOS 27.2 SDK 裡，無論是 AppKit 的標頭檔、SwiftUI 的介面或 Mac Catalyst 的 UIKit 標頭檔；而兩者的 ActivityKit macOS 介面都把它的 API 標為不可用。⁷⁸

這就是我檢查過的兩個 SDK；Xcode 27.2 RC（27B48）在 Apple 的 releases feed 中日期為 10 月 19 日，比那個 beta 新，但我沒有檢查，所以上述的缺席只對所列的 SDK 成立，不能推及其他。¹¹

今天要測試該安裝什麼（我本人尚未測試）：macOS 27.2（26B123，依 feed 於 10 月 26 日發布）與 Xcode 27.2 RC，再加上一台透過 Sidecar 連接、執行 iPadOS 27 的 iPad；技術說明描述 Sidecar 觸控可在 macOS 27 中運作，而 feed 在 10 月 28 日沒有列出任何 macOS 27.3 beta。⁶¹¹ RC 自己的說明裡有一項但書：「macOS, watchOS, tvOS, and visionOS SDKs in Xcode 27.2 incorrectly report 27.1 as a valid deployment target」，以及「Mac Catalyst builds with a 27.1 or 27.2 deployment target might be unable to use newly introduced API」（這些 SDK 會錯誤地把 27.1 回報為有效的部署目標，而部署目標為 27.1 或 27.2 的 Mac Catalyst 建置可能無法使用新 API），所以不要把 27.1 選為 macOS 的部署目標（releases feed 列出了 macOS 27.0.1 與 27.2，沒有 macOS 27.1）；若部署目標為 27.1 或 27.2 的 Mac Catalyst 看不到某個新 API，請把它視為這個已知問題，而不是符號不存在。¹¹

那麼，還沒到的有：登陸頁面承諾的 Xcode 27.3 beta、它連結的 AppKit 文章、三個系統手勢符號，以及可在 macOS 上使用的 ActivityKit（在檢查過的兩個 SDK 中都不存在，在 27.2 RC 中未經查證），還有任何關於模擬器的說明。Xcode 27.2 RC 的說明只提到觸控一次，是一項 Device Hub 修正，針對「after a period of inactivity」後停止運作的輸入；macOS 27.2 的說明則沒有任何關於觸控、手勢或 Live Activities 的條目。¹¹ 觸控 API 隨 Xcode 27.1 出貨，規則已經公布，而登陸頁面把接下來的東西標為「Coming soon」。

適用於任何 Mac app 的觸控稽核

這是作者分析，不是 Apple 的指引：把議程的四個步驟依序整理成檢查清單。目前還沒有任何實際執行測試作為後盾。

1. 用一台執行 iPadOS 27 的 iPad 透過 Sidecar 連接，搭配最新的 macOS 與 Xcode（macOS 27.2 與 Xcode 27.2 RC），在改動任何東西之前，先用觸控走過 app 的每一個畫面。
2. 搜尋 mouseDown(with:) 覆寫與 nextEvent(matching:) 迴圈，為每一處指定去向：控制項事件、代理方法，或手勢辨識器。
3. 檢查一遍小型控制項與點按區域，在有幫助的地方擴大觸控區域，但不改動版面；議程允許較小的控制項，只要觸控在它上面仍然有效。
4. 列出所有滑過時才出現的東西，逐項做出決定：工具提示維持只限滑鼠；以觸控本來就容易完成的動作不需要處理；重要的控制項則加上僅限觸控的點按辨識器，並在 UI 其他地方（例如情境選單）也提供一個入口。

這份稽核唯一不會產生的，是重新設計，因為設計議程的第一條規則就是不應有視覺上的差異；唯一可以隨輸入方式改變的版面是短暫出現的那種，也就是彈出視窗或自訂選單。

Apple 還沒有說明的事

以下每一項都是來源未回答的問題，比對範圍包括新聞稿、登陸頁面、三場議程、技術說明、規格頁面、Xcode 27.2 RC 與 macOS 27.2 的說明，以及四個 HIG 頁面。

• 哪一個 macOS 小版本會為內建螢幕帶來觸控，以及哪一個 SDK 會帶來那三個沒有文件的符號。新聞稿說的是「macOS 27」，只在 Siri AI 的註腳中提到 macOS 27.2；登陸頁面說的是「Xcode 27.3 beta」、「Coming soon」。
• 以舊 SDK 建置的二進位檔，是否會得到與以 macOS 27 SDK 重新建置者相同的觸控行為。議程說的是「all apps」；技術說明只把 location(in:) 的變更與新 SDK 綁在一起。
• 螢幕上的 Apple Pencil 或壓力感應，以及玻璃是否能在手指碰觸之前就感應到它。議程談到了缺少類似滑鼠的懸停狀態；沒有任何來源提到筆、壓力或接近感應，而 GestureInputKinds.pencil 與其他成員一樣列為 macOS 27.0，但沒有任何來源說這塊螢幕能感應筆。⁷
• 外接螢幕或闔蓋模式下的觸控，以及使用者能否關閉觸控。
• 以觸控編輯文字：插入點、控點、放大鏡與編輯選單。
• 觸控螢幕上的輔助使用。規格頁面把 AssistiveTouch 與 Touch Accommodations 列為這台筆電的功能，但沒有說明它們在 Mac 上是否為新功能。⁹
• 「Designed for iPad」的 app 如何在 Mac 螢幕上接收觸控，以及這與 Mac Catalyst 是否不同。
• 不需要 iPad 就能測試 Mac 觸控的模擬器或 Device Hub 途徑。
• 網頁內容：WKWebView 與 Safari 是否會把觸控事件或指標事件傳給網頁。
• 視窗與全螢幕內容和 Dynamic Island 之間的關係，以及由哪一個安全區域 API 回報它。
• macOS 上 Live Activities 的細節：小版本與 SDK、是否需要 NSSupportsLiveActivities、推播啟動與 APNs 註冊在 Mac 上如何運作，以及 Mac 原生活動的尺寸。

時程表

• 10 月 28 日： 在 30 個國家和地區開放預購；開發者頁面與三場議程上線；技術說明則從 6 月 8 日起就已公開。¹²⁶
• 11 月 6 日： 筆電送達顧客手中並上架門市。¹
• 11 月 18 日上午 9 點至 10 點（PT），以及 11 月 19 日晚上 6 點至 7 點（PT）： Touch on Mac Group Labs，線上舉行，有 Apple 工程師與設計師參與。²
• 「Coming soon」： Xcode 27.3 beta、文件資源與設計資源。²
• 今年 11 月： 新聞稿描述的 Apple Creator Studio 更新，其中包含 Logic Pro 與 Final Cut Pro 的觸控功能；它點名的第三方 app「will be available later this year」（將於今年稍晚推出）。¹

重點整理

給 AppKit 開發者： 標準控制項現在原生支援觸控；您自訂的 mouseDown(with:) 程式碼會以模擬方式運作，直到改用控制項事件或手勢辨識器為止，而設定 buttonMask = 0 與 allowedTouchTypes = .direct 的僅限觸控 NSPanGestureRecognizer，就是議程推薦用於小版本更新的途徑；這些 API 就在您手上已有的 macOS 27.0 SDK 裡。³⁷

給 SwiftUI 與 Catalyst 開發者： 您的手勢已經能用；GestureInputKinds 是 SwiftUI 唯一的新型別，Catalyst 的答案則是 UITouch.type 與 allowedTouchTypes。³⁷

給設計師： 36 點，而且看不見；不需要重新設計；重要的懸停動作要能以觸控觸及，也要放在 UI 的其他地方，例如情境選單，工具提示則不在此限；密集的 UI 放在邊緣，粗略的手勢留給中央。⁴

給規劃： 現在就用 Sidecar 測試；在動手做任何停用系統手勢或建立 Mac 原生 Live Activity 的功能之前，先確認已安裝的 SDK 宣告了這些 API，因為本文檢查的兩個 SDK 都沒有，而 Xcode 27.2 RC 未經查證；Apple 承諾的下一個 SDK 是 Xcode 27.3 beta。²⁷⁸

常見問題

我現有的 Mac app 能支援觸控嗎？

Apple 說大多數 app 可以：「many existing apps work with Touch right away, because macOS automatically translates touches into clicks」（許多現有 app 能立即支援觸控，因為 macOS 會自動把觸控轉成點按），而 AppKit 議程說標準的 AppKit、SwiftUI 與 Mac Catalyst 元件以及既有手勢都「just work」。¹³ 自訂的滑鼠追蹤程式碼會以模擬方式運作，直到改用控制項事件或手勢辨識器為止；非 Apple 的 UI 框架則會套上一層通用的模擬，等 app 自行處理觸控後，再以 NSIsTouchNative 關閉。³⁶

如何在 AppKit 中接收直接觸控？

用手勢辨識器。議程說「gesture recognizers are the only way to get direct touches on macOS」，技術說明則指出觸控事件不會經過回應者鏈、事件監視器、NSApp 或 sendEvent(_:)。³⁶ 僅限觸控的辨識器會把 buttonMask 設為 0，把 allowedTouchTypes 設為 .direct。³

macOS 的觸控目標是多少？

36 點，「the same physical size on display as iOS’s 44 points」（在螢幕上的實體尺寸與 iOS 的 44 點相同）。框架控制項不必改變尺寸就已符合；對自訂視圖，請擴大它的點按區域，而不是放大視圖本身。⁴³

沒有新款 MacBook Pro，要如何測試觸控？

透過 Sidecar 連接一台執行 iPadOS 27 的 iPad。議程的前提是「With the latest macOS beta and developer tools」（11:59），而 macOS 27.3 beta 尚未推出，所以我會嘗試的設定是 macOS 27.2 搭配 Xcode 27.2 RC，我本人尚未測試。³⁶¹¹

觸控 API 現在已經在 SDK 裡了嗎？

是的，議程示範的一切都在，只有系統手勢開關與 Mac 原生 Live Activities 例外，它們在本文檢查的兩個 SDK 中都不存在（Xcode 27.2 RC 未經檢查）。Xcode 27.1 內的 macOS 27.0 SDK 宣告了 NSScreen.TouchCapabilities、新的 NSControl 事件 case、NSScrollView 的觸控屬性、NSRefreshController、exclusiveGestureBehavior 與以手勢啟動的拖曳工作階段，SwiftUICore 的介面則宣告了 GestureInputKinds；Apple 文件把它們列為 macOS 27.0，沒有 beta 標記。⁷ 視窗、view controller 與視圖層級的系統手勢開關，既不在文件裡，也不在 Xcode 27.1 或 27.2 beta 的 SDK 裡；ActivityKit 在這兩者中都把它的 API 標為在 macOS 上不可用，而登陸頁面把 Xcode 27.3 beta 標為「Coming soon」。²⁷⁸

Mac app 能建立 Live Activities 嗎？

議程說在 macOS Golden Gate 中可以，使用與 iOS 相同的 ActivityKit 與 WidgetKit 程式碼，並在沒有 Dynamic Island 的 Mac 上以選單列呈現。⁵ ActivityKit 的文件與 HIG 都還沒有把 macOS 列為 app 自行建立活動的平台，它們描述的是配對 iPhone 的選單列路徑，而 Xcode 27.1 與 27.2 beta SDK 中的 ActivityKit 介面把這些 API 標為在 macOS 上不可用。¹⁰⁸

本文的事實出自哪裡？

新聞稿、開發者新聞貼文與登陸頁面、三場 Tech Talks 的英文字幕軌（每段引文的第一個字幕時間碼標在括號中）、6 月的技術說明、文中點名之每個符號的 Apple 文件 JSON、規格頁面、Xcode 27.2 RC 與 macOS 27.2 發行說明，以及四個 HIG 頁面，全部於 2026 年 10 月 28 日抓取；另外還有我這台 Mac 上 macOS 27.0 與 27.2 beta SDK 的標頭檔與 Swift 介面，這部分屬於作者分析。媒體報導不列為來源。

資料來源