개발자를 위한 Touch on Mac: 36포인트, 제스처 인식기, Sidecar

Mac의 Touch는 Mac 개발자에게 무엇을 바꿔놓습니까? 기존 앱은 “macOS automatically translates touches into clicks”(macOS가 터치를 자동으로 클릭으로 변환한다)이기 때문에 그대로 동작하고, 규칙은 Tech Talk 3개가 담고 있습니다. 제스처 인식기(gesture recognizer)는 “the only way to get direct touches on macOS”(macOS에서 직접 터치를 받는 유일한 방법)이고, 표준 컨트롤은 터치를 기본 지원하며, 터치 타깃은 36포인트이고, 호버에는 대응하는 것이 없으며, 테스트 장비는 Sidecar로 연결한 iPad입니다.¹²³⁴ 터치 API는 이미 macOS 27.0 SDK에 들어 있습니다. 반면 시스템 제스처 스위치와 macOS에서 쓸 수 있는 ActivityKit은 제가 확인한 두 SDK에 없으며, Xcode 27.3 베타는 “Coming soon”입니다.²⁵⁶⁷⁸

요약: Apple은 MacBook Pro with PROLED XDR Display(14.2인치와 16.3인치, 10월 28일 사전 주문, 11월 6일 매장 출시)의 Touch를 발표하고, 같은 10월 28일 Tech Talk 3개로 개발자에게 도입 방법을 알렸습니다.¹²⁹ 앱이 표준 AppKit 컨트롤, SwiftUI 제스처, Mac Catalyst를 쓴다면 Tech Talk는 이것들이 “just work”(그냥 동작한다)라고 말하며, 아래의 점검(히트 타깃, 호버)은 그래도 적용됩니다. 커스텀 mouseDown(with:) 코드는 컨트롤 이벤트나 제스처 인식기로 옮기기 전까지 에뮬레이션되고, Apple이 아닌 UI 프레임워크에는 범용 에뮬레이션 레이어가 붙는데, 앱이 터치를 직접 처리하게 되면 NSIsTouchNative로 이를 끕니다.³⁶ AppKit에서 직접 터치를 받으려면 제스처 인식기가 필요합니다. 터치는 리스폰더 체인에도, 이벤트 모니터에도 도달하지 않기 때문입니다.³⁶ 디자인 Tech Talk는 터치 타깃을 36포인트로 정하며, 이는 iOS의 44포인트와 같은 물리적 크기이고, macOS는 터치가 있든 없든 똑같아 보인다고 말합니다.⁴ 테스트는 Sidecar로 연결한 iPad로 하십시오. 가장 새로운 구성은 macOS 27.2와 Xcode 27.2 RC이며, 이 구성은 제가 직접 돌려보지 않았습니다.³¹¹ 터치 API는 이미 macOS 27.0 SDK에 있습니다. 시스템 제스처 스위치와 macOS에서 쓸 수 있는 ActivityKit은 제가 확인한 두 SDK에 없고, Xcode 27.3 베타는 “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 앱은 새 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”이며, 여기에는 Tech Talk 3개, 11월 18일과 19일의 Group Lab, 그리고 “Coming soon”으로 표시된 타일 3개(“Xcode 27.3 beta”, “Documentation resources”, “Design resources”)가 있습니다.² 페이지의 HTML에는 Apple이 이 타일에 붙일 예정인 링크가, 자료가 공개되면 다시 활성화하도록 표시된 주석 안에 들어 있습니다. 오늘은 404를 반환하는 AppKit 아티클 “Adopting gesture recognizers in your app”, 기존의 파일 프로미스 드래그 앤 드롭 샘플, 그리고 여러 링크 가운데 Human Interface Guidelines 페이지 4개와 Apple Design Resources입니다. 수집한 HIG 페이지에는 Mac 디스플레이의 터치에 관한 지침이 없고, Live Activities 페이지의 변경 이력은 10월 13일에서 끝납니다.²⁷¹⁰

그래서 규칙의 1차 출처는 Tech Talk들과 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일 Tech Talk들이 시연하는 API 범위를 설명합니다.⁶ 기술 노트가 이름을 든 새 심볼은 모두 Apple 문서에 introducedAt macOS 27.0, 베타 표시 없음으로 올라 있으며(10월 28일 정오(PT) 조회), 두 Info.plist 키를 제외하면 Xcode 27.1(27A9275)에 포함된 macOS 27.0 SDK에 선언되어 있습니다. 이 Mac의 헤더와 Swift 인터페이스에서 확인했습니다(필자 분석).⁷ Tech Talk가 이름을 든 시스템 제스처 심볼 3개는 그렇지 않고, macOS에서 쓸 수 있는 ActivityKit도 그렇지 않습니다. 둘 다 아래에서 다룹니다.

할 일은 없고, 그 대가로 얻는 것

호환성 이야기는 후합니다. AppKit Tech Talk는 이것으로 시작합니다. “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”(좋은 소식은 모든 앱에서 터치가 처음부터 잘 동작하도록 이미 만들어두었다는 것이다. 네이티브 프레임워크 전반에서 표준 컴포넌트는 네이티브 터치로 그냥 동작한다. SwiftUI로 만든 기존 제스처도 그냥 동작한다)(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”(기존의 커스텀 AppKit 마우스 상호작용이나 Apple이 아닌 UI 프레임워크에 대해서는 AppKit이 마우스를 지능적으로 에뮬레이션한다)(1:17).³ 기술 노트는 서드파티 프레임워크를 위한 에뮬레이션을 구체적으로 적어둡니다. “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”입니다(탭은 마우스 다운과 곧바로 이어지는 마우스 업을, 터치 후 바로 하는 팬은 UI가 반응하지 않더라도 트랙패드 스크롤 이벤트를, 움직이지 않는 길게 누르기는 rightMouseDown(with:)(선택적으로 rightMouseDragged(with:)가 뒤따름)과 손가락을 뗄 때의 rightMouseUp(with:)을, 두 손가락 핀치나 회전은 트랙패드 확대와 회전 제스처 둘 다를 동시에 흉내 냅니다).⁶ Tech Talk의 표현은 “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”(AppKit은 Apple이 아닌 UI 프레임워크 콘텐츠의 특정 위치에서 어떤 상호작용이 허용되는지 판단할 수 없다)(11:17)이기 때문입니다.³

네이티브 지원을 추가했다면 에뮬레이션을 끕니다. “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”(Info.plist에 NSIsTouchNative 항목을 추가해 터치 네이티브이며 Apple이 아닌 UI 툴킷용 마우스 에뮬레이션이 더 이상 필요 없다고 AppKit에 알린다)(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이 아닌 렌더링 또는 입력 프레임워크를 내장하고 자체 터치 처리 파이프라인을 구현한 앱을 위한 것이다)이라고 말합니다.⁷

디자인 Tech Talk의 관점은 “할 일이 없다”는 말이 시각적으로 무엇을 뜻하는지에 중요합니다. “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”(터치를 지원하는 기기의 macOS는 지원하지 않는 기기의 macOS와 다르게 보이지 않는다. 해상도, 윈도우 크기, 텍스트와 UI 컨트롤은 바뀌지 않았다)(0:41), 그리고 “Touch is a secondary input for macOS, and therefore has little impact on how macOS looks”(터치는 macOS의 보조 입력이므로 macOS의 모습에 거의 영향을 주지 않는다)(1:06)입니다.⁴ 터치 모드도 없고 compact 레이아웃도 없습니다. 이는 내부 디스플레이가 가로세로 모두 regular size class를 보고하는 iPhone Duo와 정반대입니다.

제스처 인식기만이 유일한 입구

나머지 모든 것을 정리하는 문장은 AppKit Tech Talk의 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”(macOS Golden Gate부터 제스처 인식기가 AppKit의 권장 방식이다)(3:33)과 “gesture recognizers have become the shared input language across SwiftUI, Mac Catalyst, and now AppKit”(제스처 인식기는 SwiftUI, Mac Catalyst, 그리고 이제 AppKit의 공통 입력 언어가 되었다)(3:38)이 있습니다.³ 기술 노트는 같은 이야기를 반대쪽에서 합니다. “AppKit doesn’t deliver Sidecar touch events through the responder chain or through event monitors”(AppKit은 Sidecar 터치 이벤트를 리스폰더 체인이나 이벤트 모니터로 전달하지 않는다), 그리고 노트 상자에서 “Local and global event monitors don’t receive touch events. Touch events don’t go through NSApp or sendEvent(:).”(로컬 및 글로벌 이벤트 모니터는 터치 이벤트를 받지 않는다. 터치 이벤트는 NSApp이나 sendEvent(:)를 거치지 않는다)⁶

이것이 AppKit 코드베이스에 주는 결과는 세 가지입니다.

첫째, 트래킹 루프입니다. Tech Talk의 엔지니어는 “a custom NSView with a mouseDown(with:) override that uses the standard tracking loop technique”(표준 트래킹 루프 기법을 쓰는 mouseDown(with:) 오버라이드가 있는 커스텀 NSView)(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).³ 첫 단계는 Tech Talk가 무엇이든 추가하기 전에 하는 리팩터링입니다. “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”(초기화한 NSPanGestureRecognizer에서 buttonMask를 0으로, allowedTouchTypes를 .direct로 설정한다)(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 상태를 네 함수로 보냅니다. 취소 경로가 필요한 이유는 Tech Talk가 버튼에 대해 든 것과 같습니다. “If tracking is canceled due to a system gesture like Exposé, scroll, or any other reason, I can revert any unintended changes”(Exposé, 스크롤 같은 시스템 제스처나 다른 이유로 트래킹이 취소되면 의도하지 않은 변경을 되돌릴 수 있다)(2:41). 기술 노트의 규칙은 “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.”(필요하면 형제 뷰 순서를 바꾸거나, 가리는 뷰의 hitTest(:) 메서드를 오버라이드해 nil을 반환함으로써 그 뷰가 아래 컨트롤로 가는 이벤트를 막지 않게 하라)입니다.⁶ 커스텀 인식기는 반드시 끝나야 합니다. “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”(macOS 27 SDK와 Xcode 27로 빌드한 앱에서 NSGestureRecognizer의 location(in:)은 수신자의 클래스가 이 메서드를 오버라이드하지 않으면 NSZeroPoint를 반환하고 오류를 기록한다), 이유는 “Subclasses of NSGestureRecognizer must implement location(in:) to report a meaningful location.”(NSGestureRecognizer 서브클래스는 의미 있는 위치를 보고하도록 location(in:)을 구현해야 한다)입니다.⁶

셋째, 잃는 것입니다. 컨트롤 액션에 대해 기술 노트는 NSControl이 인식기로 옮겨가면서 “changes the timing of when AppKit delivers control action messages with respect to event processing”(이벤트 처리 대비 AppKit이 컨트롤 액션 메시지를 전달하는 시점이 바뀐다)라고 말합니다. 그래서 currentEvent는 “no longer returns the event that triggered an action”(액션을 일으킨 이벤트를 더 이상 반환하지 않는다)이며, 대신 NSEvent.pressedMouseButtons와 클래스 수준의 modifierFlags를 가리키고, “a touch is not part of pressedMouseButtons”(터치는 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.”(AppKit 컨트롤을 서브클래싱하고 왼쪽 마우스 리스폰더 메서드 중 하나라도 오버라이드하면, 그 컨트롤은 호환성을 위해 트래킹 루프 경로로 되돌아간다)⁶

컨트롤: mouseDown 대신 이벤트

AppKit Tech Talk의 첫 리팩터링 대상은 버튼입니다. 원래 코드는 NSButton을 서브클래싱하고 mouseDown(with:)을 오버라이드해 트래킹이 언제 시작되고 끝나는지 알아냈습니다. 터치에서는 “the buttons work, but AppKit must emulate mouse events to pass to the mouseDown override”(버튼은 동작하지만 AppKit이 mouseDown 오버라이드에 넘길 마우스 이벤트를 에뮬레이션해야 한다)(2:17)입니다.³ 대안은 NSControl 이벤트를 “directly on NSButton without the need to subclass”(서브클래싱 없이 NSButton에 직접)(2:27) 쓰는 것입니다. Tech Talk 페이지의 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”(NSControl 이벤트는 표준 AppKit 컨트롤에서 쓸 수 있고, 대부분은 macOS 11까지 거슬러 올라가 쓸 수 있다)(2:51).³ Tech Talk는 이 패턴에 대해 “Modernizing your AppKit app”이라고 부르는 WWDC26 세션을 가리키는데, 기술 노트가 관련 영상으로 올려둔 세션은 “Modernize your AppKit app”(WWDC26 세션 289)입니다.³⁶

macOS 27은 기술 노트의 “Handle control events” 섹션에 따라 NSControl.Events에 케이스를 추가합니다. trackingRepeated(“An event when multiple mouseDown(with:) events with a click count greater than 1 occur”, 클릭 수가 1보다 큰 mouseDown(with:) 이벤트가 여러 번 발생할 때), 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). Tech Talk는 이를 제스처 배타성이라고 부르고, 기술 노트는 호환성으로 설명합니다. “For maximum compatibility, AppKit restricts gesture activations to a single view hierarchy at a time”(최대한의 호환성을 위해 AppKit은 제스처 활성화를 한 번에 하나의 뷰 계층으로 제한한다), 그리고 “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”(스토브 뷰의 exclusiveGestureBehavior를 .notExclusive로 설정하면 자식 슬라이더 서브뷰도 모두 비배타적이 된다)(8:01)입니다. 앱 전체는 Info.plist 키 NSViewGestureRecognizerIsExclusive로 해제합니다.³⁶⁷ Tech Talk는 이 속성이 “is available in the next SDK”(다음 SDK에서 사용할 수 있다)(7:54)라고 말합니다. 그러나 Apple 문서는 이를 macOS 27.0, 베타 표시 없음으로 올려두었고, 6월의 기술 노트가 이를 설명하며, Xcode 27.1에 포함된 macOS 27.0 SDK는 NSView.h에서 이를 “Defaults to .inherit“라는 주석과 함께 API_AVAILABLE(macos(27.0))로 선언합니다. 그러니 Tech Talk가 “next”라고 부른 SDK는 Tech Talk가 올라왔을 때 이미 배포되고 있었습니다(설치된 헤더에 근거한 필자 분석).³⁶⁷

36포인트

디자인 Tech Talk는 이 숫자를 세 번 말하고, AppKit Tech Talk도 이를 되풀이합니다. “Touch on macOS uses a touch target of 36 points. This creates the same physical size on display as iOS’s 44 points”(macOS의 터치는 36포인트 터치 타깃을 쓴다. 이는 화면에서 iOS의 44포인트와 같은 물리적 크기다)(9:17).⁴ 이 타깃은 의도적으로 보이지 않습니다. “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”(macOS의 모든 프레임워크 컨트롤이 이 새 터치 타깃을 쓰도록 업데이트되었지만, 보이지 않는다는 점에 주목하라. 컨트롤 크기는 바뀌지 않았으므로 새 레이아웃이 필요 없다)(9:26).⁴

커스텀 뷰에 대한 지침은 컨트롤이 아니라 히트 영역을 넓히라는 것입니다. AppKit Tech Talk의 배선 노드는 “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”(타깃 사각형을 각 축에서 최소 36포인트로 넓힌다. 레이아웃을 바꾸지 않고, 마우스에는 여전히 정밀함을 요구하면서 터치로 노드를 맞히기 쉽게 한다)(5:50)이며, 그는 이 기법을 “for small resize or grab handles for selected objects in a canvas view”(캔버스 뷰에서 선택한 객체의 작은 크기 조절 핸들이나 잡기 핸들에)(6:07) 권합니다.³ Apple이 아닌 컨트롤에 대한 디자인 Tech Talk의 표현은 “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”(FormStyle을 쓰라. 여기서도 각 행은 기본적으로 36포인트 높이다)(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”(직접 터치에는 mouseMoved 이벤트에 해당하는 것이 없다)(10:38). 따라서 롤오버로 드러나는 모든 것에 결정이 필요합니다.³ AppKit Tech Talk의 규칙은 이렇습니다. “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.”(mouseMoved(with:)를 통한 호버는 여전히 NSTrackingArea로 관리된다)⁶

디자인 Tech Talk의 규칙은 사용자 쪽에서 본 같은 내용입니다. “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”(호버에서 나타나는 동작은 UI의 다른 곳에도 중복해 두라)(13:05)이며, 미리 알림의 공유 버튼은 터치 환경에서 행의 컨텍스트 메뉴에 들어갑니다(13:20).⁴

스크롤, 길게 누르기, 드래그, 텍스트

스크롤은 디스플레이에서는 한 손가락, 트랙패드에서는 두 손가락입니다(4:39).⁴ 한 손가락이 스크롤 대신 그리기를 해야 할 때, AppKit Tech Talk는 “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”(NSScrollView는 이제 당겨서 새로고침을 지원한다)는 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”(드래그할 수 있는 항목을 길게 누르면 들어 올리는 애니메이션으로 드래그 가능함을 암시해야 한다. 드래그 앤 드롭 들어 올리기 미리보기를 얻으려면 NSTableView, NSOutlineView, NSCollectionView의 기존 드래그 앤 드롭 델리게이트 API를 쓰라)(9:49).³ 메뉴에 대해서는 “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”(NSView의 menu 속성을 쓰거나 menu(for:)를 오버라이드하라. AppKit이 이를 감지해 적절한 제스처 인식기를 자동으로 설치하며, 여기에는 단축 수단으로 Control-탭 인식기도 포함된다)(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”(이 메뉴 API와 컨테이너 뷰의 드래그 앤 드롭 델리게이트 API를 함께 쓰면, AppKit이 길게 누르기가 드래그 앤 드롭이 될지 컨텍스트 메뉴가 될지를 조정하고, 사용자가 둘 사이를 오갈 수도 있게 한다)(10:25)입니다.³ 디자인 Tech Talk는 사용자가 보는 모습을 보여줍니다. 사진이 “scales up under my finger”(손가락 아래에서 커진다)(3:50), 그 옆에 컨텍스트 메뉴가 나타나고(3:58), 드래그하면 메뉴가 닫히며(4:05), 터치로 드래그하는 동안에도 Shift와 Option이 동작합니다(4:13).⁴ 커스텀 뷰에서는 27.0에 새로 생긴 beginDraggingSession(items:gesture:source:)가 “a drag from a gesture recognizer”(제스처 인식기에서 시작하는 드래그)를 시작합니다.⁶⁷

텍스트는 얇은 부분입니다. 기술 노트의 문장은 하나, “NSTextSelectionManager allows custom text engines to support standard text gestures”(NSTextSelectionManager로 커스텀 텍스트 엔진이 표준 텍스트 제스처를 지원할 수 있다)뿐이고, 이 클래스는 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”(일련의 제스처 인식기로 텍스트 선택 상호작용을 한곳에서 관리하는 방법을 제공한다)이고, 편집 가능, 선택만 가능, 상호작용 불가 중 하나인 상호작용 모드, 선택 영역을 저장하는 델리게이트, 그리고 레이아웃 데이터 소스를 갖습니다.⁷ 어느 Tech Talk도 터치에서의 삽입 지점, 선택 핸들, 편집 메뉴를 다루지 않습니다. 디자인 Tech Talk의 선택 지침은 항목에 관한 것으로, “on macOS we recommend to allow modeless selection through click and tap”(macOS에서는 클릭과 탭을 통한 모드 없는 선택을 허용하길 권한다)(2:42), 그리고 한 번 탭하면 선택, 두 번 탭하면 열기입니다(3:10).⁴

시스템 제스처, 그리고 문서화되지 않은 스위치

macOS는 디스플레이 위의 여러 손가락 제스처 한 묶음을 가져갑니다. 이 제스처들은 “controlled by macOS and are therefore not available to any app running”(macOS가 제어하므로 실행 중인 어떤 앱도 쓸 수 없다)(8:05)입니다. 세 손가락을 위로 올리면 Mission Control, 아래로 내리면 App Exposé(8:13), 엄지와 세 손가락으로 오므리면 앱 표시, 벌리면 데스크탑 보기(8:22), 세 손가락을 좌우로 움직이면 스페이스 간 이동(8:32), 위아래 가장자리에서 쓸어 숨겨진 메뉴 막대와 Dock 표시(8:37), Dynamic Island 위로 쓸어 Siri 호출(8:46), 그리고 가장자리에서 쓸어 알림 센터와 제어 센터 열기(8:51)입니다.⁴

AppKit Tech Talk는 슬라이더 세 개로 이 충돌에 부딪힙니다. “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”(NSWindow의 disablesDirectTouchSystemGestures 속성으로 윈도우 단위에서 시스템 제스처 사용 여부를 제어할 수 있다. SwiftUI와 Mac Catalyst에도 UIViewController와 View에 비슷한 API가 있다)(8:25). 경고도 함께입니다. “Only disable system gestures if the interaction capabilities they open up are critical for the window”(그로써 가능해지는 상호작용이 그 윈도우에 결정적일 때만 시스템 제스처를 끄라)(8:42).³ Tech Talk 페이지의 코드 목록은 세 가지를 모두 명시합니다. NSWindow의 disablesDirectTouchSystemGestures, UIViewController의 prefersDirectTouchSystemGesturesDisabled, 그리고 SwiftUI View의 directTouchSystemGesturesDisabled()입니다.³ 10월 28일 현재 세 가지 모두 Apple 문서에 없습니다. JSON 엔드포인트는 404를 반환하고, 이 심볼들은 AppKit, UIKit, SwiftUI 인덱스에 없습니다.⁷ Apple의 발언이 아니라 제 해석입니다만, 이 심볼들은 Tech Talk가 전제하는 SDK가 “Coming soon”으로 표시된 바로 그 SDK라는 가장 분명한 신호입니다.

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”(마우스와 직접 터치 입력을 구분해야 하는 특수한 필요가 있다면 새 GestureInputKinds 제스처 수정자 API를 쓸 수 있다)(0:43).³ 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.”(SwiftUI에서 GestureInputKinds로 제스처를 특정 입력 유형으로 제한하라)입니다.⁶

Mac Catalyst는 UIKit에 iOS 9부터 있던 것을 씁니다. Tech Talk는 “UITouch.touchType and UIGestureRecognizer’s allowedTouchTypes”(0:59)라고 말하지만, 문서화된 속성은 UITouch.type이고 열거형은 UITouch.TouchType이며, allowedTouchTypes는 Mac Catalyst 13.1의 UIGestureRecognizer에 있습니다.³⁷ Tech Talk의 표현은 말실수이지 새 API가 아닙니다.

Mac의 Live Activities, 문서보다 앞서서

세 번째 Tech Talk는 짧지만 큰 주장을 합니다. “The Dynamic Island has come to the Mac. To fully take advantage of its capabilities, Mac apps now support native Live Activities”(Dynamic Island가 Mac에 왔다. 그 기능을 온전히 활용하도록 Mac 앱은 이제 네이티브 Live Activities를 지원한다)(0:05), 그리고 “now in macOS Golden Gate, applications running on the Mac can create Live Activities directly”(이제 macOS Golden Gate에서 Mac에서 실행되는 앱이 Live Activities를 직접 만들 수 있다)(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”(기존 Live Activities가 있는 유니버설 앱은 코드 변경 없이 Mac에서 동작하고, 네이티브 macOS 앱은 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”(Dynamic Island가 있는 Mac에서는 기기 위쪽 가장자리에 자연스럽게 녹아들고, 다른 기기와 디스플레이에서는 메뉴 막대에 표시된다)(1:14)입니다.⁵ 코드는 iOS 코드 그대로입니다. ActivityAttributes의 데이터 모델(2:36), Dynamic Island 뷰 빌더와 함께 ActivityConfiguration에 두는 compact와 minimal 표현(3:24), 유일한 Mac 전용 표현인 “The menu bar expanded Live Activity view is created along with the ActivityConfiguration as a simple view”(메뉴 막대의 확장 Live Activity 뷰는 ActivityConfiguration과 함께 단순한 뷰로 만든다)(3:52), 반면 “Expanded Live Activities in the Dynamic Island are defined with the Dynamic Island view builder”(Dynamic Island의 확장 Live Activities는 Dynamic Island 뷰 빌더로 정의한다)(4:02), “This same code works on iOS and macOS”(같은 코드가 iOS와 macOS에서 동작한다)(4:30), 즉시, 예약, 푸시로 이루어지는 시작(4:40), “with existing backgrounding technologies on the Mac, like background tasks and user agents”(백그라운드 작업과 사용자 에이전트 같은 Mac의 기존 백그라운드 기술과의) 통합(4:54), App Intents를 통한 액션(5:56), 그리고 “If you have an iOS activity, there’s no code to port”(iOS 액티비티가 있다면 옮길 코드가 없다)(7:09)입니다.⁵ iOS에서 넘어오는 규칙이 두 가지 있습니다. “Only a single Live Activity can be expanded at a time”(한 번에 하나의 Live Activity만 확장될 수 있다)(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”(Mac에서는 메뉴 막대에 나타난다)라고 말하고, 플랫폼 목록은 iOS, iPadOS, Mac Catalyst 16.1이며, Activity, ActivityAttributes, ActivityConfiguration, DynamicIsland, 그리고 NSSupportsLiveActivities 키 어디에도 macOS 플랫폼이 없습니다.⁸⁷ 변경 이력이 10월 13일에서 끝나는 HIG의 Live Activities 페이지는 여전히 페어링된 iPhone 경로만 설명합니다. “Active Live Activities automatically appear in the Menu bar of a paired Mac”(활성 Live Activities는 페어링된 Mac의 메뉴 막대에 자동으로 나타난다), “Clicking the Live Activity launches iPhone Mirroring to display your app”(Live Activity를 클릭하면 iPhone 미러링이 실행되어 앱을 표시한다), 그리고 “macOS dimensions” 아래의 “Use the provided iOS dimensions.”(제공된 iOS 치수를 쓰라)입니다.¹⁰ SDK는 Tech Talk가 아니라 문서와 일치합니다. 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에서 확인했습니다(필자 분석). 그러니 계획에 적을 올바른 문장은 좁은 쪽입니다. Tech Talk는 macOS Golden Gate에 이 기능이 있다고 말하지만, 문서도, 제가 확인한 두 SDK 어느 쪽도 아직 이를 빌드하게 해주지 않습니다. 상태 머신 글은 공유되는 시작, 업데이트, 종료 모델의 iOS 구현을 보여줍니다. Mac 고유의 지속 시간, 해제, 백그라운드 제한은 아직 어느 출처에도 없습니다.

디자인: macOS는 바뀌지 않습니다

디자인 Tech Talk의 마무리 규칙은 통째로 옮겨도 될 만큼 짧습니다. “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”(터치 지원만을 위해 앱을 다시 디자인하지 마라. 터치를 지원하는 Mac의 앱은 지원하지 않는 Mac의 앱과 시각적으로 달라서는 안 된다)(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”(macOS에서는 36포인트를 터치 타깃으로 쓰고, Apple 프레임워크로 터치에 최적화된 레이아웃과 확장 가능한 컨트롤을 얻으라)(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”(앱 윈도우의 왼쪽과 오른쪽은 인스펙터나 내비게이션 사이드바처럼 풍부한 컨트롤과 밀도 높은 UI를 두기에 가장 좋다)(6:29)이고, “the center of the display is best used for coarse, imprecise and big gestures”(디스플레이 중앙은 거칠고 부정확한 큰 제스처에 가장 좋다)(6:46)입니다.⁴ 커스텀 제스처에는 세 가지 제약이 있습니다. “your gestures should work with touch and trackpad and possibly Magic Mouse”(제스처는 터치와 트랙패드, 가능하면 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”(제스처가 하는 동작은 메뉴 같은 UI의 다른 곳에도 있어야 한다)(7:37)입니다.⁴ Tech Talk는 Mac에 없던 것도 허용합니다. “macOS now allows multiple touch gestures at the same time”(macOS는 이제 여러 터치 제스처를 동시에 허용한다)(5:30)이며, 두 손가락으로 Logic의 슬라이더 두 개를 조작하는 것이 예시입니다(5:45).⁴ 이것이 앞에서 본 배타성 속성의 사용자 쪽 모습입니다. AppKit의 기본값은 한 번에 하나의 뷰 계층만 허용하고, 앱이 나머지를 여는 방법이 .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”(최신 macOS 베타와 개발자 도구가 있으면 터치 디스플레이 Mac의 모든 터치 기능을 Sidecar로 연결한 iPad에서 쓸 수 있다)(11:59), 그리고 “The fastest way to get started with touch on Mac is with the Sidecar tools you already own”(Mac 터치를 시작하는 가장 빠른 길은 이미 가진 Sidecar 도구다)(12:09).³ 기술 노트는 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”(입력 소스와 상관없이 이벤트를 처리하고, 필요하면 상호작용 유형에 따라 다른 표현을 정하는 편이 낫다)입니다.⁶⁷

Tech Talk의 점검 순서를 그대로 옮깁니다. “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”(Sidecar로 macOS에서 앱의 터치 테스트를 시작하라. 다음으로 mouseDown(with:) 오버라이드를 점검하고, 컨트롤 이벤트나 델리게이트 메서드로 대체할지, 터치 전용 제스처 인식기를 추가할지 정하라. 히트 타깃이 작은 영역을 찾아 터치에 맞게 넓히라. 마지막으로 숨겨진 필수 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, 새 NSControl 이벤트 케이스 5개, 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 헤더에도 없으며, 두 SDK 모두에서 ActivityKit의 macOS 인터페이스는 API를 사용할 수 없다고 표시합니다.⁷⁸

이것이 제가 확인한 두 SDK입니다. Apple의 릴리스 피드가 10월 19일로 날짜를 매긴 Xcode 27.2 RC(27B48)는 그 베타보다 새롭고 확인하지 않았으므로, 위의 부재는 명시한 SDK에 대해서만 성립하고 그 너머로는 성립하지 않습니다.¹¹

오늘 테스트하려면 설치할 것은 다음과 같습니다(제가 테스트하지는 않았습니다). macOS 27.2(26B123, 피드 기준 10월 26일 출시)와 Xcode 27.2 RC, 그리고 Sidecar로 연결한 iPadOS 27의 iPad입니다. 기술 노트는 Sidecar 터치가 macOS 27에서 동작한다고 설명하며, 피드에는 10월 28일 현재 macOS 27.3 베타가 없습니다.⁶¹¹ RC 자체의 노트에서 나온 단서가 하나 있습니다. “macOS, watchOS, tvOS, and visionOS SDKs in Xcode 27.2 incorrectly report 27.1 as a valid deployment target”(Xcode 27.2의 macOS, watchOS, tvOS, visionOS SDK가 27.1을 유효한 최소 배포 버전으로 잘못 보고한다), 그리고 “Mac Catalyst builds with a 27.1 or 27.2 deployment target might be unable to use newly introduced API”(최소 배포 버전이 27.1 또는 27.2인 Mac Catalyst 빌드는 새로 도입된 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(확인한 두 SDK에 없고, 27.2 RC에서는 확인하지 않음), 그리고 시뮬레이터에 관한 어떤 언급입니다. Xcode 27.2 RC 노트는 터치를 한 번 언급하는데, “after a period of inactivity”(일정 시간 사용하지 않은 뒤) 멈춘 입력에 대한 Device Hub 수정 사항이고, macOS 27.2 노트에는 터치, 제스처, Live Activities 항목이 없습니다.¹¹ 터치 API는 Xcode 27.1과 함께 배포되었고, 규칙은 공개되었으며, 랜딩 페이지는 그다음 것을 “Coming soon”으로 표시해두었습니다.

어떤 Mac 앱에든 쓸 수 있는 터치 점검

Apple의 지침이 아니라 필자 분석입니다. Tech Talk의 네 단계를 순서대로 체크리스트로 만들었습니다. 아직 실제 실행 테스트로 뒷받침된 것은 아닙니다.

1. 최신 macOS와 Xcode(macOS 27.2와 Xcode 27.2 RC)에서 iPadOS 27의 iPad를 Sidecar로 연결하고, 아무것도 바꾸기 전에 앱의 모든 화면을 터치해봅니다.
2. mouseDown(with:) 오버라이드와 nextEvent(matching:) 루프를 검색해, 각각을 컨트롤 이벤트, 델리게이트 메서드, 제스처 인식기 중 하나에 배정합니다.
3. 작은 컨트롤과 히트 영역을 훑어보고, 도움이 되는 곳에서는 레이아웃을 바꾸지 않고 터치 영역을 넓힙니다. Tech Talk는 터치가 동작하기만 하면 더 작은 컨트롤도 허용합니다.
4. 롤오버로 나타나는 모든 것의 목록을 만들고 항목마다 결정합니다. 툴팁은 마우스 전용으로 남기고, 이미 터치로 쉬운 동작에는 아무것도 하지 않으며, 필수 컨트롤에는 터치 전용 클릭 인식기와 컨텍스트 메뉴 같은 UI의 다른 자리를 줍니다.

이 점검이 만들어내지 않는 단 하나는 리디자인입니다. 디자인 Tech Talk의 첫 규칙이 시각적 차이가 없어야 한다는 것이기 때문입니다. 입력에 따라 바뀌어도 되는 레이아웃은 일시적인 것, 즉 팝오버나 커스텀 메뉴뿐입니다.

Apple이 말하지 않은 것

아래는 모두 출처들이 열어둔 질문이며, 보도자료, 랜딩 페이지, Tech Talk 3개, 기술 노트, 사양 페이지, Xcode 27.2 RC와 macOS 27.2 노트, HIG 페이지 4개와 대조해 확인했습니다.

• 어떤 macOS 포인트 릴리스가 내장 디스플레이의 Touch를 싣는지, 그리고 어떤 SDK가 문서화되지 않은 심볼 3개를 싣는지. 보도자료는 “macOS 27”이라고 말하고 macOS 27.2는 Siri AI 각주에서만 언급합니다. 랜딩 페이지는 “Xcode 27.3 beta”, “Coming soon”이라고 말합니다.
• 이전 SDK로 빌드한 바이너리가 macOS 27 SDK로 다시 빌드한 바이너리와 같은 터치 동작을 얻는지. Tech Talk는 “all apps”(모든 앱)라고 말하고, 기술 노트는 location(in:) 변경만 새 SDK에 연결합니다.
• 디스플레이에서의 Apple Pencil이나 압력, 그리고 유리가 닿기 전의 손가락을 감지하는지. Tech Talk들은 마우스 같은 호버 상태가 없다는 점을 다루지만, 펜슬, 압력, 근접 감지를 언급하는 출처는 없습니다. GestureInputKinds.pencil은 다른 모든 멤버처럼 macOS 27.0으로 올라 있지만, 디스플레이가 펜슬을 감지한다고 말하는 출처는 없습니다.⁷
• 외부 디스플레이나 클램셸 모드에서의 Touch, 그리고 사용자가 Touch를 끌 수 있는지.
• 터치로 하는 텍스트 편집: 삽입 지점, 핸들, 돋보기, 편집 메뉴.
• 터치 디스플레이에서의 손쉬운 사용. 사양 페이지는 이 노트북의 기능 가운데 AssistiveTouch와 Touch Accommodations를 나열하지만, 이것이 Mac에 새로 들어온 것인지는 말하지 않습니다.⁹
• “Designed for iPad” 앱이 Mac 디스플레이에서 터치를 어떻게 받는지, 그리고 그것이 Mac Catalyst와 다른지.
• iPad 없이 Mac 터치를 테스트할 시뮬레이터나 Device Hub 경로.
• 웹 콘텐츠: WKWebView와 Safari가 페이지에 터치 이벤트를 전달하는지, 포인터 이벤트를 전달하는지.
• 윈도우와 전체 화면 콘텐츠가 Dynamic Island와 어떤 관계인지, 그리고 어떤 안전 영역 API가 이를 보고하는지.
• macOS의 Live Activities 세부 사항: 포인트 릴리스와 SDK, NSSupportsLiveActivities가 필요한지, Mac에서 푸시로 시작하기와 APNs 등록이 어떻게 동작하는지, 그리고 Mac 네이티브 액티비티의 치수.

일정

• 10월 28일: 30개 국가 및 지역에서 사전 주문, 개발자 페이지와 Tech Talk 3개. 기술 노트는 6월 8일부터 올라와 있습니다.¹²⁶
• 11월 6일: 노트북이 고객과 매장에 도착합니다.¹
• 11월 18일 오전 9시~10시(PT), 11월 19일 오후 6시~7시(PT): Apple 엔지니어와 디자이너가 함께하는 온라인 Touch on Mac Group Lab.²
• “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가 Tech Talk가 권하는 마이너 릴리스용 경로입니다. 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 베타입니다.²⁷⁸

자주 묻는 질문

기존 Mac 앱이 Touch에서 동작합니까?

Apple은 대부분의 앱에 대해 그렇다고 말합니다. “many existing apps work with Touch right away, because macOS automatically translates touches into clicks”(macOS가 터치를 자동으로 클릭으로 바꾸므로 많은 기존 앱이 바로 Touch로 동작한다)이고, AppKit Tech Talk는 표준 AppKit, SwiftUI, Mac Catalyst 컴포넌트와 기존 제스처가 “just work”(그냥 동작한다)라고 말합니다.¹³ 커스텀 마우스 트래킹 코드는 컨트롤 이벤트나 제스처 인식기로 옮기기 전까지 에뮬레이션됩니다. Apple이 아닌 UI 프레임워크에는 범용 에뮬레이션 레이어가 붙고, 앱이 터치를 직접 처리하게 되면 NSIsTouchNative로 이를 끕니다.³⁶

AppKit에서 직접 터치는 어떻게 받습니까?

제스처 인식기로 받습니다. Tech Talk는 “gesture recognizers are the only way to get direct touches on macOS”(제스처 인식기는 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로 연결하십시오. Tech Talk의 조건은 “With the latest macOS beta and developer tools”(최신 macOS 베타와 개발자 도구로)(11:59)인데, macOS 27.3 베타는 아직 나오지 않았으므로 제가 시도해볼 구성은 macOS 27.2와 Xcode 27.2 RC입니다. 직접 테스트하지는 않았습니다.³⁶¹¹

터치 API는 지금 SDK에 있습니까?

있습니다. 다만 Tech Talk들이 시연하는 것 가운데 시스템 제스처 스위치와 Mac 네이티브 Live Activities는 예외로, 여기서 살펴본 두 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에도 없고, 두 SDK 모두에서 ActivityKit은 macOS에서 API를 사용할 수 없다고 표시하며, 랜딩 페이지는 Xcode 27.3 베타를 “Coming soon”으로 표시합니다.²⁷⁸

Mac 앱이 Live Activities를 만들 수 있습니까?

Tech Talk는 macOS Golden Gate에서 그렇다고 말합니다. iOS와 같은 ActivityKit 및 WidgetKit 코드를 쓰고, Dynamic Island가 없는 Mac에서는 메뉴 막대에 표시됩니다.⁵ ActivityKit 문서와 HIG는 아직 앱이 만드는 액티비티의 플랫폼으로 macOS를 올리지 않았고, 페어링된 iPhone의 메뉴 막대 경로를 설명하며, Xcode 27.1과 27.2 베타 SDK의 ActivityKit 인터페이스는 macOS에서 API를 사용할 수 없다고 표시합니다.¹⁰⁸

이 글의 사실은 어디에서 왔습니까?

보도자료, 개발자 뉴스 게시물과 랜딩 페이지, Tech Talk 3개의 영어 자막 트랙(각 인용의 첫 큐를 괄호 안에 표기), 6월의 기술 노트, 이름을 든 모든 심볼의 Apple 문서 JSON, 사양 페이지, Xcode 27.2 RC와 macOS 27.2 릴리스 노트, HIG 페이지 4개이며, 모두 2026년 10월 28일에 조회했습니다. 여기에 제 Mac에 있는 macOS 27.0 SDK와 27.2 베타 SDK의 헤더와 Swift 인터페이스를 더했고, 이는 필자 분석입니다. 언론 보도는 출처가 아닙니다.

출처