開発者のためのTouch on Mac：36ポイント、ジェスチャレコグナイザ、Sidecar

MacにやってきたTouchは、Mac開発者にとって何を変えるのでしょうか。 既存のアプリはそのまま動きます。「macOS automatically translates touches into clicks」（macOSがタッチを自動的にクリックへ変換する）からです。ルールを定めているのは3本のTech Talkです。ジェスチャレコグナイザは「the only way to get direct touches on macOS」（macOSで直接タッチを受け取る唯一の方法）であること、標準コントロールはタッチネイティブであること、タッチターゲットは36ポイントであること、ホバーに相当するものはないこと、そしてSidecarでつないだiPadがテスト環境になること。¹²³⁴ タッチのAPIはmacOS 27.0 SDKにすでに入っています。一方で、システムジェスチャのスイッチとmacOSで使えるActivityKitは、私が確認した2つのSDKには見当たりません。Xcode 27.3ベータは「Coming soon」のままです。²⁵⁶⁷⁸

TL;DR: Appleは、MacBook Pro with PROLED XDR Display（14.2インチと16.3インチ、予約受付は10月28日、店頭販売は11月6日から）でのTouchを発表し、同じ10月28日に3本のトークで開発者に対応方法を伝えました。¹²⁹ アプリが標準のAppKitコントロール、SwiftUIのジェスチャ、Mac Catalystを使っているなら、トークによればそれらは「just work」（そのまま動く）です。それでも、後述の監査（ヒットターゲットとホバー）は当てはまります。独自のmouseDown(with:)コードは、コントロールイベントかジェスチャレコグナイザへ移行するまでエミュレーションで動きます。Apple以外のUIフレームワークには汎用のエミュレーション層が用意され、アプリが自分でタッチを扱うようになればNSIsTouchNativeでそれをオフにできます。³⁶ AppKitで直接タッチを受け取るにはジェスチャレコグナイザが必要です。タッチはレスポンダチェーンにもイベントモニタにも届かないからです。³⁶ デザインのトークはタッチターゲットを36ポイントと定めています。これはiOSの44ポイントと同じ物理サイズで、macOSの見た目はタッチがあってもなくても変わらない、とトークは言います。⁴ テストはSidecar経由のiPadで行います。最新の組み合わせはmacOS 27.2とXcode 27.2 RCですが、私はこの構成をまだ動かしていません。³¹¹ タッチのAPIはmacOS 27.0 SDKにすでに入っています。システムジェスチャのスイッチとmacOSで使えるActivityKitは、私が確認した2つのSDKにはなく、Xcode 27.3ベータは「Coming soon」です。²³⁷⁸

Appleが公開したもの、していないもの

Appleの発表は基調講演ではなくプレスリリースでした。当日の記録はライブ記事にあります。リリースのうち開発者向けの内容は、「Touch Arrives on Mac」の節にある3つの文です。まず「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のアプリは新しいMacBook Pro向けに最適化されており、macOSがタッチを自動的にクリックへ変換するため、多くの既存アプリもすぐにTouchで動く）、続いて「Updated system gesture APIs also enable developers to create intuitive experiences designed specifically for Touch」（更新されたシステムジェスチャAPIにより、開発者はTouch専用に設計された直感的な体験も作れる）、そして「app developers can test how Touch performs in their iOS and iPadOS apps directly on the MacBook Pro display」（iOSとiPadOSのアプリでのTouchの動作を、MacBook Proのディスプレイ上で直接テストできる）という一文です。¹ 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」です。ページには3本のTech Talk、11月18日と19日のGroup Labs、そして「Coming soon」と記された3つのタイル「Xcode 27.3 beta」「Documentation resources」「Design resources」が並んでいます。² ページのHTMLには、それらのタイルに付ける予定のリンクが、リソース公開時に再び有効にするための印を付けたコメントの中に入っています。AppKitの記事「Adopting gesture recognizers in your app」（今日の時点では404を返します）、既存のファイルプロミスを使ったドラッグ&ドロップのサンプル、そしてリンクの中にHuman Interface Guidelinesの4ページと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、ベータ表示なしで載っています（10月28日正午（PT）に取得）。2つのInfo.plistキーを除けば、Xcode 27.1（27A9275）内のmacOS 27.0 SDKで宣言されていることも、このMacのヘッダとSwiftインターフェースで確かめました（筆者による分析）。⁷ トークが挙げる3つのシステムジェスチャのシンボルはそうではなく、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)。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」。つまりタップはクリック、タッチしてすぐのパンはトラックパッドのスクロール、動かない長押しは右クリック、2本指のピンチや回転はトラックパッドの拡大と回転になります。⁶ トークでの言い方は「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)（Apple以外のフレームワークの内容では、どの位置でどんな操作が許されるかをAppKitは判断できない）からです。³

ネイティブ対応を加えたら、エミュレーションをオフにします。「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アプリには不要で、AppKit以外の描画・入力フレームワークを組み込み、独自のタッチ処理を実装するアプリ向け）とあります。⁷

「何もしなくていい」が見た目の面で何を意味するかは、デザインのトークの枠組みが決めています。「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にとって副次的な入力なので、見た目にはほとんど影響しない）。⁴ タッチモードもコンパクトなレイアウトもありません。これはiPhone Duoとは正反対の状況です。Duoでは内側ディスプレイが両方向ともregularのサイズクラスを報告します。

入口はジェスチャレコグナイザだけ

ほかのすべてを組み立てている一文は、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)（ジェスチャレコグナイザはSwiftUI、Mac Catalyst、そしてAppKitに共通の入力言語になった）という言葉があります。³ テクニカルノートは同じことを反対側から述べています。「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のコードベースにとって、これには3つの帰結があります。

1つ目は、トラッキングループです。トークのエンジニアは配線パズルを作り直します。このパズルは「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)（トラッキングループは引き続きサポートされ、タッチ専用のジェスチャレコグナイザと共存できる。マイナーリリースでは、タッチ専用のレコグナイザを足すのが最も速く、リスクも小さい道かもしれない）。³ 最初の一歩は、トークが何かを足す前に行うリファクタリングです。「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() { /* ... */ }

タッチ専用のレコグナイザの作り方は、プロパティへの代入2つだけです。「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の各状態を4つの関数に振り分けます。キャンセルの経路が必要な理由は、トークがボタンについて述べたものと同じです。「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からあります。このレシピに新しいものは何もありません。⁷

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.」⁶ さらに、新しい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.」だからです。⁶

3つ目は、失うものです。コントロールのアクションについて、テクニカルノートは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はオーバーライドに渡すためにマウスイベントをエミュレーションしなければならない）となります。³ 置き換え先は、NSControlのイベントを「directly on NSButton without the need to subclass」(2:27)で使う方法です。トークのページにある2:24のコードリストは、ボタンにaddTarget(_:action:for:)を3回登録しています。対象は[.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)。³ トークはこのパターンについて、自ら「Modernizing your AppKit app」と呼ぶWWDC26のセッションを参照しています。テクニカルノートが関連ビデオとして挙げるセッションは「Modernize your AppKit app」（WWDC26 session 289）です。³⁶

macOS 27では、テクニカルノートの「Handle control events」の節によれば、NSControl.Eventsにケースが加わります。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)（デフォルトでは、一度に操作できるビューは1つだけ）。トークはこれをジェスチャの排他性と呼び、テクニカルノートは互換性の問題として説明します。「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)となります。アプリ全体で外すなら、Info.plistのNSViewGestureRecognizerIsExclusiveキーを使います。³⁶⁷ トークはこのプロパティが「is available in the next SDK」(7:54)と言います。しかしAppleのドキュメントはmacOS 27.0、ベータ表示なしとしており、6月のテクニカルノートもこれを説明しています。Xcode 27.1内のmacOS 27.0 SDKはNSView.hでAPI_AVAILABLE(macos(27.0))として宣言し、「Defaults to .inherit」というコメントまで付けています。つまり、トークが「next」と呼ぶSDKは、トークの公開時点ですでに出荷されていたことになります（インストール済みのヘッダからの筆者による分析）。³⁶⁷

36ポイント

デザインのトークはこの数字を3回挙げ、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)。つまりインスペクタではmediumが引き続きデフォルト、ツールバーはextra-large、largeとextra-largeはツールバーの外では使わず、要所を強調するときやコンテンツ消費が主な用途のアプリでだけ控えめに使う、ということです。⁴ 設定のようなビューには「use FormStyle. Here as well, each row by default measures the 36-point height」(10:28)です。⁴ smallとminiのコントロールも使って構いません。「They fully support touch regardless of their size」(10:46)。独自のものには1つだけルールがあります。「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ポイントにできない3つのコントロールについては、フレームワークが難しい部分を引き受けます。「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はページに触れたときにちょうど2つだけを表示します(12:36)。そして「actions that appear on hover be duplicated elsewhere in your UI」(13:05)。リマインダーの共有ボタンは、タッチでは行のコンテキストメニューに置かれています(13:20)。⁴

スクロール、長押し、ドラッグ、テキスト

スクロールは、ディスプレイでは1本指、トラックパッドでは2本指です(4:39)。⁴ 1本指でスクロールではなく描画させたいとき、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」とされ、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を使えば、長押しがドラッグになるかコンテキストメニューになるかを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)、つまり1回のタップで選択、ダブルタップで開く(3:10)というものです。⁴

システムジェスチャと、ドキュメント化されていないスイッチ

macOSは、ディスプレイ上の一連の複数指ジェスチャを自分のものにしています。これらは「controlled by macOS and are therefore not available to any app running」(8:05)（macOSが制御するため、どのアプリも使えない）です。3本指の上スワイプでMission Control、下スワイプでApp Exposé(8:13)、親指と3本指のピンチでアプリを表示し、広げるとデスクトップを表示(8:22)、3本指の左右でスペース間を移動(8:32)、上端と下端からのスワイプで隠れたメニューバーとDock(8:37)、Dynamic Islandの上をスワイプしてSiriを呼び出す(8:46)、そして端からのスワイプで通知センターとコントロールセンター(8:51)です。⁴

AppKitのトークは3つのスライダーでこの衝突にぶつかります。「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)（ウインドウ単位でシステムジェスチャの可否を制御でき、SwiftUIとMac Catalystにも同様のAPIがある）。警告も添えています。「Only disable system gestures if the interaction capabilities they open up are critical for the window」(8:42)。³ トークのページのコードリストは3つすべての名前を挙げています。NSWindowのdisablesDirectTouchSystemGestures、UIViewControllerのprefersDirectTouchSystemGesturesDisabled、SwiftUIのViewのdirectTouchSystemGesturesDisabled()です。³ 10月28日の時点で、この3つはいずれもAppleのドキュメントにありません。JSONエンドポイントは404を返し、AppKit、UIKit、SwiftUIのインデックスにもシンボルが見当たりません。⁷ Appleの言葉ではなく私の読みですが、これは、トークが前提としているSDKが「Coming soon」と記されたものであることを最もはっきり示すしるしです。

SwiftUIとMac Catalyst

SwiftUIに加わる新しい型は1つです。「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を使える）。³ GestureInputKindsは7つのプラットフォームすべてで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はMac Catalyst 13.1からUIGestureRecognizerにあります。³⁷ トークの言い回しは言い間違いで、新しいAPIではありません。

MacのLive Activities、ドキュメントより先に

3本目のトークは短く、大きな主張をしています。「The Dynamic Island has come to the Mac. To fully take advantage of its capabilities, Mac apps now support native Live Activities」(0:05)、そして「now in macOS Golden Gate, applications running on the Mac can create Live Activities directly」(0:57)（Dynamic IslandがMacに来て、MacのアプリがネイティブにLive Activitiesを作れるようになった）。⁵ 「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)。⁵ 表示場所は「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では上端に溶け込み、それ以外ではメニューバーに表示される）です。⁵ コードはiOSのコードと同じです。データモデルはActivityAttributesに(2:36)、コンパクトとミニマルの表示はDynamic IslandのビュービルダーとともにActivityConfigurationに(3:24)。Mac固有の表示は1つだけで、「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から引き継がれるルールが2つあります。「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ベータ（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)。「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)。タッチのためだけに作り直さず、見た目の違いを作らず、ジェスチャで操作し、36ポイントを使い、キーボードとマウスを主な入力のままにする、ということです。⁴

空間についてのルールは1つだけで、それはポーズではなく手の話です。「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に、中央は大まかで大きなジェスチャに）。⁴ 独自のジェスチャには3つの制約があります。「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の2つのスライダーを2本の指で動かす場面です(5:45)。⁴ これは前述の排他性プロパティのユーザー側の姿です。AppKitのデフォルトは一度に1つのビュー階層だけを有効にし、.notExclusiveがアプリに残りを開く方法です。³⁶

いまテストする：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)、そして「The fastest way to get started with touch on Mac is with the Sidecar tools you already own」(12:09)（最新のmacOSベータと開発ツールがあれば、SidecarでつないだiPadでタッチのすべての機能を使える）。³ テクニカルノートはiPadにiPadOS 27を求め、タッチ対応の判定（NSScreen.touchCapabilities、.multiTouchビットを持つオプションセット）について注意を加えています。macOS 27では、この判定は「returns true for all displays when a touch-capable Sidecar display is connected, not just for the Sidecar display」（タッチ対応のSidecarディスプレイが接続されていると、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)。³ スキルもあります。「there’s a gesture modernization skill that has an understanding of the features and changes I’ve talked about」(12:16)。ランディングページのXcodeのタイルにはTK skillというプレースホルダのコメントがあり、その名前を挙げている情報源はありません。²³

出荷済みのSDKに何が入っているか。このMacのヘッダとSwiftインターフェースから見た筆者による分析です。Xcode 27.1（27A9275）内のmacOS 27.0 SDKは、NSScreen.TouchCapabilities、5つの新しいNSControlイベントケース、NSScrollViewのタッチ関連プロパティ、NSRefreshController、beginDraggingSession(items:gesture:source:)、exclusiveGestureBehaviorを、すべてAPI_AVAILABLE(macos(27.0))で宣言しています。SwiftUIが再エクスポートするSwiftUICoreのmacOSインターフェースはGestureInputKindsを宣言しています。3つのシステムジェスチャのスイッチは、そのSDKにも、Xcode 27.2ベータ（27B5019j）内のmacOS 27.2 SDKにもありません。AppKitのヘッダ、SwiftUIのインターフェース、Mac CatalystのUIKitヘッダのいずれにもなく、ActivityKitのmacOSインターフェースはどちらのSDKでもAPIを使用不可としています。⁷⁸

私が確認したのはこの2つのSDKです。Xcode 27.2 RC（27B48）はAppleのリリースフィードで10月19日付けとなっており、あのベータより新しいものですが、確認していません。ですから、ここで述べた欠落は名前を挙げたSDKについてのみ成り立ち、それ以上には及びません。¹¹

いまテストするために入れるもの（私自身は試していません）：macOS 27.2（26B123、フィードによれば10月26日リリース）とXcode 27.2 RC、そしてSidecarでつないだiPadOS 27のiPadです。テクニカルノートはSidecarのタッチがmacOS 27で動くと説明しており、フィードには10月28日の時点でmacOS 27.3ベータは載っていません。⁶¹¹ RC自身のノートから注意点を1つ。「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」とあります。ですから、macOSのデプロイメントターゲットに27.1を選ばないでください（リリースフィードにはmacOS 27.0.1と27.2があり、macOS 27.1はありません）。また、デプロイメントターゲットが27.1か27.2のMac Catalystで新しいAPIが見えない場合は、シンボルの欠落ではなくこの既知の問題として読んでください。¹¹

では、まだないものは何か。ランディングページが約束するXcode 27.3ベータ、そこからリンクされるAppKitの記事、3つのシステムジェスチャのシンボルとmacOSで使えるActivityKit（確認した2つのSDKにはなく、27.2 RCでは未確認）、そしてシミュレータについての言及です。Xcode 27.2 RCのノートがタッチに触れるのは1回だけで、「after a period of inactivity」に止まった入力についてのDevice Hubの修正です。macOS 27.2のノートには、タッチ、ジェスチャ、Live Activitiesの項目はありません。¹¹ タッチのAPIはXcode 27.1とともに出荷され、ルールは公開され、次に来るものをランディングページは「Coming soon」としています。

あらゆるMacアプリのためのタッチ監査

Appleのガイダンスではなく筆者による分析です。トークの4つのステップを、順番どおりチェックリストにしました。実行時のテストによる裏付けはまだありません。

1. iPadOS 27のiPadをSidecarでつなぎ、最新のmacOSとXcode（macOS 27.2とXcode 27.2 RC）で、何かを変える前にアプリのすべての画面に触れてみる。
2. mouseDown(with:)のオーバーライドとnextEvent(matching:)のループを検索し、それぞれをコントロールイベント、デリゲートメソッド、ジェスチャレコグナイザのいずれかに割り当てる。
3. 小さなコントロールとヒット領域を見直し、役立つところではレイアウトを変えずにタッチ領域を広げる。トークは、タッチで動きさえすれば小さめのコントロールも認めている。
4. ロールオーバーで現れるものをすべて書き出し、項目ごとに判断する。ツールチップはマウス専用のまま。タッチですでに簡単な操作には何も要らない。欠かせないコントロールには、タッチ専用のクリックレコグナイザと、コンテキストメニューなどUIの別の場所での置き場を用意する。

この監査から生まれないものが1つあります。作り直しです。デザインのトークの第一のルールは、見た目の違いがあってはならないというものだからです。入力によって変わってよいレイアウトは、ポップオーバーや独自メニューのような一時的なものだけです。

Appleがまだ言っていないこと

以下は、いずれも情報源が答えを出していない問いです。リリース、ランディングページ、3本のトーク、テクニカルノート、仕様ページ、Xcode 27.2 RCとmacOS 27.2のノート、そしてHIGの4ページと照らし合わせて確認しました。

• 内蔵ディスプレイのTouchを担うのはどのmacOSポイントリリースか、そしてドキュメント化されていない3つのシンボルを担うのはどのSDKか。リリースは「macOS 27」と言い、macOS 27.2の名前はSiri AIの脚注でしか出てきません。ランディングページは「Xcode 27.3 beta」「Coming soon」です。
• 古いSDKでビルドしたバイナリが、macOS 27 SDKで再ビルドしたものと同じタッチの挙動を得るのか。トークは「all apps」と言い、テクニカルノートが新しいSDKに結びつけているのはlocation(in:)の変更だけです。
• ディスプレイ上でのApple Pencilや筆圧、そしてガラスが触れる前の指を感知するのか。トークはマウスのようなホバー状態がないことを扱っていますが、ペンシル、筆圧、近接検知に触れた情報源はありません。GestureInputKinds.pencilはほかのメンバーと同じくmacOS 27.0として載っていますが、ディスプレイがペンシルを感知すると述べた情報源はありません。⁷
• 外部ディスプレイやクラムシェルモードでのタッチ、そしてユーザーがTouchをオフにできるのか。
• タッチによるテキスト編集：挿入ポイント、ハンドル、ルーペ、編集メニュー。
• タッチディスプレイでのアクセシビリティ。仕様ページはこのラップトップの機能としてAssistiveTouchとTouch Accommodationsを挙げていますが、それがMacにとって新しいものかどうかは述べていません。⁹
• 「Designed for iPad」アプリがMacのディスプレイでタッチをどう受け取るのか、そしてそれはMac Catalystと違うのか。
• iPadなしでMacのタッチを試せるシミュレータやDevice Hubの経路。
• Webコンテンツ：WKWebViewとSafariは、ページにタッチイベントとポインタイベントのどちらを渡すのか。
• ウインドウやフルスクリーンのコンテンツがDynamic Islandとどう関係するのか、そしてどのセーフエリアAPIがそれを報告するのか。
• macOSでのLive Activitiesの詳細：ポイントリリースとSDK、NSSupportsLiveActivitiesが必要かどうか、Macでのpush-to-startとAPNsの登録の仕組み、そしてMacネイティブのアクティビティの寸法。

日程

• 10月28日：30の国と地域で予約受付開始。開発者向けページと3本のトーク。テクニカルノートは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ベータ、ドキュメントのリソース、デザインのリソース。²
• この11月：リリースが説明するLogic ProとFinal Cut Proのタッチ機能を含むApple Creator Studioのアップデート。リリースが名前を挙げるサードパーティアプリは「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を宣言しているか確かめてください。ここで調べた2つのSDKは宣言しておらず、Xcode 27.2 RCは未確認です。Appleが約束している次のSDKはXcode 27.3ベータです。²⁷⁸

よくある質問

既存のMacアプリはTouchで動きますか。

Appleはほとんどのアプリについて、動くと言っています。「many existing apps work with Touch right away, because macOS automatically translates touches into clicks」（多くの既存アプリは、macOSがタッチをクリックに自動変換するため、すぐにTouchで動く）。AppKitのトークも、標準のAppKit、SwiftUI、Mac Catalystのコンポーネントと既存のジェスチャは「just work」と述べています。¹³ 独自のマウストラッキングのコードは、コントロールイベントかジェスチャレコグナイザへ移るまでエミュレーションで動きます。Apple以外のUIフレームワークには汎用のエミュレーション層があり、アプリが自分でタッチを扱うようになれば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なしでTouchをテストするには。

iPadOS 27のiPadをSidecarでつなぎます。トークの条件は「With the latest macOS beta and developer tools」(11:59)ですが、macOS 27.3ベータはまだ出ていません。そこで私が試すとすればmacOS 27.2とXcode 27.2 RCの組み合わせですが、自分ではまだ試していません。³⁶¹¹

タッチのAPIは、いまのSDKに入っていますか。

入っています。トークが実演するもののうち、システムジェスチャのスイッチとMacネイティブのLive Activitiesを除くすべてです。この2つは、ここで調べた2つのSDKにはありません（Xcode 27.2 RCは調べていません）。Xcode 27.1内のmacOS 27.0 SDKは、NSScreen.TouchCapabilities、新しいNSControlイベントケース、NSScrollViewのタッチ関連プロパティ、NSRefreshController、exclusiveGestureBehavior、そしてジェスチャベースのドラッグセッションを宣言しており、SwiftUICoreのインターフェースはGestureInputKindsを宣言しています。Appleのドキュメントはこれらをベータ表示なしのmacOS 27.0としています。⁷ ウインドウ、ビューコントローラ、ビューのシステムジェスチャのスイッチは、ドキュメントにもXcode 27.1や27.2ベータのSDKにもありません。ActivityKitはどちらのSDKでもmacOSでAPIを使用不可としており、ランディングページはXcode 27.3ベータを「Coming soon」としています。²⁷⁸

MacアプリでLive Activitiesを作れますか。

トークは、macOS Golden Gateでは作れると言っています。iOSと同じActivityKitとWidgetKitのコードで、Dynamic IslandのないMacではメニューバーに表示されます。⁵ ActivityKitのドキュメントとHIGは、アプリが作るアクティビティのプラットフォームとしてまだmacOSを挙げておらず、ペアリングしたiPhone経由のメニューバーの経路を説明しています。Xcode 27.1と27.2ベータのSDKにあるActivityKitのインターフェースは、macOSでAPIを使用不可としています。¹⁰⁸

この記事の事実はどこから来ていますか。

リリース、開発者向けのニュース投稿とランディングページ、3本のTech Talkの英語字幕トラック（引用ごとに最初のキューを括弧で示しています）、6月のテクニカルノート、名前を挙げたすべてのシンボルについてのAppleのドキュメントJSON、仕様ページ、Xcode 27.2 RCとmacOS 27.2のリリースノート、そしてHIGの4ページです。いずれも2026年10月28日に取得しました。これに加えて、私のMacにあるmacOS 27.0とmacOS 27.2ベータのSDKのヘッダとSwiftインターフェースを調べており、これは筆者による分析です。報道は情報源にしていません。

出典