Touch on Mac para devs: 36 pontos, recognizers e Sidecar

O que o Touch no Mac muda para quem desenvolve para Mac? Os apps existentes funcionam porque “macOS automatically translates touches into clicks” (o macOS traduz toques em cliques automaticamente), e três Tech Talks trazem as regras: gesture recognizers são “the only way to get direct touches on macOS” (a única forma de receber toques diretos no macOS), os controles padrão são nativos para toque, o alvo de toque tem 36 pontos, o hover não tem equivalente, e um iPad no Sidecar é a bancada de testes.¹²³⁴ As APIs de toque já estão no SDK do macOS 27.0; os controles dos gestos do sistema e um ActivityKit disponível no macOS não estão, nos dois SDKs que verifiquei, e o beta do Xcode 27.3 aparece como “Coming soon.”²⁵⁶⁷⁸

TL;DR: A Apple anunciou o Touch no MacBook Pro with PROLED XDR Display (14,2 e 16,3 polegadas, pré-venda em 28 de outubro, nas lojas em 6 de novembro) e explicou aos desenvolvedores como adotá-lo em três talks em 28 de outubro.¹²⁹ Se o seu app usa controles padrão do AppKit, gestos do SwiftUI ou Mac Catalyst, o talk diz que eles “just work” (simplesmente funcionam), e a auditoria abaixo (alvos de toque, hover) continua valendo. Código próprio de mouseDown(with:) é emulado até migrar para control events ou gesture recognizers, e um framework de UI que não é da Apple recebe uma camada genérica de emulação que NSIsTouchNative desliga quando o app passa a tratar o toque por conta própria.³⁶ Para receber um toque direto no AppKit, você precisa de um gesture recognizer, porque os toques nunca chegam à responder chain nem aos event monitors.³⁶ O talk de design fixa o alvo de toque em 36 pontos, o mesmo tamanho físico de 44 pontos no iOS, e diz que o macOS tem a mesma aparência com e sem toque.⁴ Teste com um iPad pelo Sidecar; as peças mais novas são o macOS 27.2 e o Xcode 27.2 RC, uma configuração que eu não rodei.³¹¹ As APIs de toque já estão no SDK do macOS 27.0. O controle dos gestos do sistema e um ActivityKit disponível no macOS estão ausentes dos dois SDKs que verifiquei, e o beta do Xcode 27.3 aparece como “Coming soon.”²³⁷⁸

O que a Apple publicou, e o que não publicou

O anúncio da Apple foi um comunicado de imprensa, não um keynote; o post ao vivo tem o registro do dia. O conteúdo para desenvolvedores do comunicado são três frases na seção “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,” depois “Updated system gesture APIs also enable developers to create intuitive experiences designed specifically for Touch,” e a observação de que “app developers can test how Touch performs in their iOS and iPadOS apps directly on the MacBook Pro display” (os apps da Apple são otimizados para o novo MacBook Pro, e muitos apps existentes funcionam com o Touch de imediato porque o macOS traduz toques em cliques; as APIs de gestos do sistema atualizadas permitem criar experiências intuitivas pensadas especificamente para o Touch; e os desenvolvedores podem testar como o Touch se comporta nos seus apps de iOS e iPadOS direto na tela do MacBook Pro).¹ A seção sobre o macOS diz que o notebook “comes to life with macOS 27” e cita “Touch built for macOS 27”; ela não nomeia uma versão pontual.¹

O lado dos desenvolvedores estava no ar às 11:47 da manhã no horário do Pacífico: um post de notícias, “Say hello to Touch on Mac,” e uma página de entrada, “Get ready for Touch on Mac,” com três Tech Talks, Group Labs em 18 e 19 de novembro e três blocos marcados como “Coming soon”: “Xcode 27.3 beta,” “Documentation resources” e “Design resources.”² O HTML da página traz os links que a Apple pretende associar a esses blocos, dentro de comentários marcados para serem reativados quando os recursos forem ao ar: um artigo do AppKit, “Adopting gesture recognizers in your app,” que hoje retorna 404, o exemplo já existente de arrastar e soltar com file promises e, entre os links, quatro páginas das Human Interface Guidelines e o Apple Design Resources; as páginas das HIG que capturei não trazem orientação sobre toque na tela do Mac, e o change log da página de Live Activities termina em 13 de outubro.²⁷¹⁰

Assim, as fontes primárias das regras são os talks e uma technote que a Apple publicou em 8 de junho, “TN3212: Adopting gesture recognizers for Sidecar touch support,” cuja Overview diz que “In macOS 27, AppKit continues to standardize on gesture recognizers as the primary mechanism for input handling” (no macOS 27, o AppKit continua se padronizando em torno dos gesture recognizers como o principal mecanismo de tratamento de entrada), e cujas seções “Explore updated APIs in macOS 27,” “Detect touch capability,” “Handle control events” e “Configure scroll behavior” descrevem a superfície de API que os talks de 28 de outubro demonstram.⁶ Todo símbolo novo que a technote cita está na documentação da Apple com introducedAt macOS 27.0 e sem marcação de beta, consultada em 28 de outubro ao meio-dia no horário do Pacífico, e, com exceção das duas chaves do Info.plist, declarado no SDK do macOS 27.0 dentro do Xcode 27.1 (27A9275), conferido nos headers e nas interfaces Swift deste Mac (análise do autor).⁷ Os três símbolos de gestos do sistema que o talk cita não estão, e nem um ActivityKit disponível no macOS; os dois casos estão mais abaixo.

Nada a fazer, e o que você ganha com isso

A história de compatibilidade é generosa. O talk de AppKit começa por ela: “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) (já fizemos o toque funcionar muito bem de fábrica em todos os apps; nos nossos frameworks nativos, os componentes padrão simplesmente funcionam com o toque nativo, e os gestos existentes criados em SwiftUI simplesmente funcionam), e o mesmo vale para o Mac Catalyst (0:52).³ No AppKit, “Standard buttons, controls, tables, collections, split views, tabs, scrolling, and more are all touch native” (1:10).³

O que não é nativo é emulado: “for existing custom AppKit mouse interactions, or if you use non-Apple UI frameworks, AppKit intelligently emulates the mouse” (1:17) (para interações de mouse próprias já existentes no AppKit, ou se você usa frameworks de UI que não são da Apple, o AppKit emula o mouse de forma inteligente).³ A technote detalha a emulação para frameworks de terceiros: “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,” e “A two-finger pinch or rotation simultaneously emulates both the trackpad magnify and rotate gestures” (um toque rápido emula um mouse-down seguido imediatamente de um mouse-up; um toque seguido de arrasto imediato emula eventos de rolagem do trackpad, mesmo que a UI não responda a eles; um toque longo sem movimento emula um clique com o botão direito, solto quando o dedo sai da tela; e uma pinça ou rotação com dois dedos emula ao mesmo tempo os gestos de ampliar e girar do trackpad).⁶ A versão do talk: “a one-finger scroll with momentum, click, drag with a small hold delay, and even pinch for rotation and magnification” (11:28).³ A emulação é por janela e genérica, porque “AppKit can’t determine what kind of interactions are allowed at any particular location of your non-Apple UI framework content” (11:17) (o AppKit não consegue saber que interações cada ponto do conteúdo de um framework de terceiros aceita).³

Quando você já acrescentou suporte nativo, desliga a emulação: “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).³ A chave está documentada como macOS 27.0, e a página dela diz “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.” (a maioria dos apps AppKit não precisa dela; ela se destina principalmente a apps que embutem um framework de renderização ou de entrada que não é do AppKit e implementam o próprio pipeline de tratamento de toque)⁷

O enquadramento do talk de design importa para o que “nada a fazer” significa visualmente: “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), e “Touch is a secondary input for macOS, and therefore has little impact on how macOS looks” (1:06) (o toque é uma entrada secundária e quase não muda a aparência do macOS).⁴ Não existe modo de toque nem layout compacto. É o oposto da situação do iPhone Duo, em que a tela interna informa classes de tamanho regulares nas duas dimensões.

Gesture recognizers são a única porta de entrada

A frase que organiza todo o resto está em 3:45 do talk de AppKit: “In fact, gesture recognizers are the only way to get direct touches on macOS.”³ Antes dela: “Starting with macOS Golden Gate, gesture recognizers are the preferred approach in AppKit” (3:33), e “gesture recognizers have become the shared input language across SwiftUI, Mac Catalyst, and now AppKit” (3:38).³ A technote diz o mesmo pelo outro lado: “AppKit doesn’t deliver Sidecar touch events through the responder chain or through event monitors,” e, em uma nota, “Local and global event monitors don’t receive touch events. Touch events don’t go through NSApp or sendEvent(:).” (os event monitors locais e globais não recebem eventos de toque, e os eventos de toque não passam por NSApp nem por sendEvent(:))⁶

Isso tem três consequências para uma base de código AppKit.

Primeiro, os tracking loops. O engenheiro do talk reconstrói um quebra-cabeça de fiação que usava “a custom NSView with a mouseDown(with:) override that uses the standard tracking loop technique” (3:13), chamando nextEvent(matching:) até o mouse up, e diz “Migrate your mouse tracking loops to gesture recognizers” (3:51).³ A migração não é tudo ou nada: “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) (os tracking loops continuam suportados e podem conviver com recognizers só de toque; você pode descobrir que acrescentar recognizers só de toque é o caminho mais rápido e menos arriscado para uma versão pontual do app).³ O primeiro passo é a refatoração que o talk faz antes de acrescentar qualquer coisa: “The first step is to refactor my tracking loop into separate start, continue, end, and cancel tracking functions” (4:11), para que o loop do mouse e o recognizer de toque possam compartilhá-las.³ A listagem da Apple, literal:

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

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

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

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

A receita para um recognizer só de toque são, então, duas atribuições de propriedade: “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)

A action direciona os estados .began, .changed, .ended e .cancelled do recognizer para as quatro funções. O motivo do caminho de cancelamento é o que o talk deu para o botão: “If tracking is canceled due to a system gesture like Exposé, scroll, or any other reason, I can revert any unintended changes” (2:41) (se o tracking for cancelado por um gesto do sistema como o Exposé, pela rolagem ou por qualquer outro motivo, posso desfazer mudanças não intencionais), e a regra da technote é “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 existe desde o macOS 10.10 e allowedTouchTypes desde o 10.12.2; nada nessa receita é novo.⁷

Segundo, as regras que os recognizers impõem. A technote: “If your view is covered by another, often transparent, view, your gesture recognizer won’t be triggered,” e “You can’t place views on top of standard framework controls, because those controls now use gesture recognizers internally,” com a saída que a própria technote oferece: “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” (se a view estiver coberta por outra, muitas vezes transparente, o recognizer não dispara; não dá para colocar views sobre os controles padrão do framework, porque eles agora usam gesture recognizers internamente; se necessário, reordene as views irmãs ou sobrescreva o método hitTest(:) da view que cobre para retornar nil).⁶ Um recognizer próprio precisa terminar: “End your active gesture recognizer by transitioning to ended, failed, or cancelled. If you don’t, recognizers are blocked from activating.”⁶ E uma mudança de comportamento restrita a subclasses compiladas com o SDK novo: “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,” porque “Subclasses of NSGestureRecognizer must implement location(in:) to report a meaningful location.”⁶

Terceiro, o que você perde. Para as actions de controles, a technote diz que a migração para recognizers no NSControl “changes the timing of when AppKit delivers control action messages with respect to event processing,” então currentEvent “no longer returns the event that triggered an action,” aponta para NSEvent.pressedMouseButtons e para o modifierFlags de classe como alternativa, e acrescenta que “a touch is not part of pressedMouseButtons.”⁶ E uma subclasse que sobrescreve um método do botão esquerdo do mouse paga por isso: “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.” (o controle volta ao caminho do tracking loop por compatibilidade)⁶

Controles: eventos em vez de mouseDown

A primeira refatoração do talk de AppKit é um botão. O original era uma subclasse de NSButton que sobrescrevia mouseDown(with:) para saber quando o tracking começava e terminava; com toque, “the buttons work, but AppKit must emulate mouse events to pass to the mouseDown override” (2:17) (os botões funcionam, mas o AppKit precisa emular eventos de mouse para o override).³ A substituição são os eventos de NSControl “directly on NSButton without the need to subclass” (2:27); a listagem em 2:24 da página do talk registra três chamadas addTarget(_:action:for:) no botão, para [.trackingBegan, .trackingEntered], [.trackingExited, .trackingEndedInside] e .trackingCancelled, e os eventos também expõem o estado que um override de mouse nunca via: “If tracking is canceled due to a system gesture like Exposé, scroll, or any other reason, I can revert any unintended changes” (2:41).³ Os eventos são antigos: “NSControl events are available for standard AppKit controls, and most control events are available all the way back to macOS 11” (2:51).³ O talk aponta para a sessão da WWDC26 que ele chama de “Modernizing your AppKit app” para o padrão; a sessão que a technote lista como vídeo relacionado é “Modernize your AppKit app” (sessão 289 da WWDC26).³⁶

O macOS 27 acrescenta casos a NSControl.Events, segundo a seção “Handle control events” da technote: 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”) e applicationReserved para os seus próprios eventos.⁶⁷

Depois vem a exclusividade. “By default, only one view can be interacted with at a time” (7:20) (por padrão, só uma view recebe interação por vez), o que o talk chama de exclusividade de gestos e a technote explica como compatibilidade: “For maximum compatibility, AppKit restricts gesture activations to a single view hierarchy at a time,” e “Unlike in iOS, the person can’t perform multiple interactions simultaneously, though scrolling is a notable exception.”³⁶ Você sai disso por view: “The API to control gesture exclusivity is the exclusiveGestureBehavior property on NSView” (7:48). O padrão da propriedade “inherits its parent’s exclusive gesture behavior” (7:57) (herda o comportamento de exclusividade de gestos da view pai), e “By setting the exclusiveGestureBehavior property on the stove view to .notExclusive, the child slider subviews all become non-exclusive as well” (8:01); o app inteiro sai disso com a chave NSViewGestureRecognizerIsExclusive do Info.plist.³⁶⁷ O talk diz que a propriedade “is available in the next SDK” (7:54) (está disponível no próximo SDK). A documentação da Apple a lista como macOS 27.0 sem marcação de beta, a technote de junho a descreve, e o SDK do macOS 27.0 dentro do Xcode 27.1 a declara API_AVAILABLE(macos(27.0)) com o comentário “Defaults to .inherit” no NSView.h, então o SDK que o talk chama de “next” já estava disponível quando o talk foi ao ar (análise do autor a partir dos headers instalados).³⁶⁷

36 pontos

O talk de design dá o número três vezes, e o talk de AppKit o repete. “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) (36 pontos no macOS equivalem, na tela, ao tamanho físico de 44 pontos no iOS).⁴ O alvo é invisível por design: “All macOS’s framework controls have been updated to use this new touch target, but notice it’s invisible. The controls haven’t changed size and therefore don’t require a new layout” (9:26) (todos os controles do framework foram atualizados para usar esse novo alvo de toque, que é invisível; os controles não mudaram de tamanho e não exigem um layout novo).⁴

Para views próprias, a instrução é ampliar a área de toque, não o controle. Os nós de fiação do talk de AppKit eram “a little tricky to touch” (5:14), então o engenheiro acrescentou um parâmetro expandHitRect que “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) (amplia o retângulo do alvo para no mínimo 36 pontos em cada eixo, o que facilita acertar um nó pelo toque sem deixar de exigir precisão do mouse e sem mudar o layout), uma técnica que ele recomenda “for small resize or grab handles for selected objects in a canvas view” (6:07).³ A versão do talk de design para controles que não são da Apple: “consider increasing the touch target area around your control instead of changing the control size” (9:51).⁴

Os tamanhos de controle não mudam. “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) (em inspetores e outras áreas cheias de controles, os controles médios continuam sendo o padrão; as toolbars de janela usam controles extragrandes por padrão; controles grandes e extragrandes não devem ser usados fora da toolbar), e “They should only be used sparingly to emphasize key moments or in apps of which content consumption is the primary use case” (10:14).⁴ Para views parecidas com ajustes, “use FormStyle. Here as well, each row by default measures the 36-point height” (10:28).⁴ Controles small e mini continuam permitidos: “They fully support touch regardless of their size” (10:46), com uma regra para os próprios: “If your app is using custom small controls, ensure touch works, even though the tap target might be small” (10:50), porque “touch events should never be ignored” (11:00) (eventos de toque nunca devem ser ignorados).⁴

O framework faz a parte difícil nos três controles que não podem ter 36 pontos: “the stepper, dial, and slider” (13:54) “now expand in place when interacting via touch” (14:07) (agora se expandem no lugar quando tocados), sem mudar o valor no toque que os expande (14:26), e “collapse themselves when I’m not interacting with them” (14:41); para sliders é uma opção, já que “sliders have the option to expand when presented small” (15:36).⁴ Os menus também se adaptam: “when using touch, the menu shows slightly larger rows to help make selection easier” (11:23), e as views transitórias podem fazer o mesmo: “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) (popovers e menus próprios podem ter layouts um pouco diferentes conforme a entrada que os abriu).⁴

O hover acabou

“Direct touches don’t have an equivalent to mouseMoved events” (10:38) (toques diretos não têm equivalente aos eventos mouseMoved), então tudo o que aparece no rollover exige uma decisão.³ As regras do talk de 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), e “for hidden essential controls, install a touch-only click gesture recognizer to temporarily show the element on a touch tap” (10:57) (não exiba permanentemente controles ocultos, não revele tooltips no toque, e para controles essenciais ocultos instale um click recognizer só de toque que os mostre temporariamente).³ A technote confirma que o caminho do ponteiro não muda: “Hovering via mouseMoved(with:) is still managed with NSTrackingArea.”⁶

As regras do talk de design são as mesmas, vistas pelo lado do usuário. “hover actions that are purely showing information, like tooltips, are not required to work with touch” (11:53); ações que já são fáceis pelo toque não precisam de affordance, como os botões de rolagem de um carrossel, que “remain hidden during a touch interaction” (12:22) porque “horizontal scroll is always possible via touch” (12:19); “only the most important hover actions relevant to that content should reveal themselves” (12:30), com o Safari mostrando exatamente duas quando uma página é tocada (12:36); e “actions that appear on hover be duplicated elsewhere in your UI” (13:05) (as ações que aparecem no hover devem estar duplicadas em outro lugar da UI), com o botão de compartilhar do Lembretes ficando no menu de contexto da linha quando se usa toque (13:20).⁴

Rolagem, toque longo, arrastar, texto

A rolagem usa um dedo na tela e dois no trackpad (4:39).⁴ Quando um dedo deve desenhar em vez de rolar, o talk de AppKit configura “the decorating view’s enclosing scroll view to require two touches minimum for touch scrolling” (6:40); a propriedade é NSScrollView.minimumNumberOfTouchesForScrolling, macOS 27.0, com maximumNumberOfTouchesForScrolling, isTouchScrollingEnabled e scrollGestureForRelationships ao lado.³⁷ Um recognizer que deve perder para uma rolagem define isCancellableByScrollGesture; “NSScrollView now supports pull-to-refresh functionality” por meio do NSRefreshController; e no NSPanGestureRecognizer o par minimumNumberOfTouches e maximumNumberOfTouches “replace numberOfTouchesRequired,” que está deprecated no 27.0.⁶⁷

O toque longo é o gesto do Mac tanto para arrastar quanto para o menu de contexto, e o AppKit arbitra. “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) (um item arrastável indica isso com uma animação de levantar, obtida pelas APIs de delegate de arrastar e soltar já existentes).³ Para menus, “Use the menu property on NSView or override menu(for:). AppKit will detect this and automatically install the appropriate gesture recognizers, which include a control-tap gesture recognizer as an accelerator” (10:11), e “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) (o AppKit decide se o toque longo vira arrastar ou menu de contexto, e deixa o usuário alternar entre os dois).³ O talk de design mostra o ponto de vista do usuário: a foto “scales up under my finger” (3:50), o menu de contexto aparece ao lado dela (3:58), e arrastar fecha o menu (4:05); Shift e Option continuam funcionando ao arrastar pelo toque (4:13).⁴ Para views próprias, beginDraggingSession(items:gesture:source:) inicia “a drag from a gesture recognizer,” novo no 27.0.⁶⁷

O texto é o ponto fraco. A única frase da technote é “NSTextSelectionManager allows custom text engines to support standard text gestures,” e a classe está documentada como macOS 27.0 com o resumo “An object that coordinates text selection behavior for custom text views.”⁶⁷ O header completa o contrato (análise do autor): a classe “provides a centralized way to manage text selection interactions using a set of gesture recognizers,” com um modo de interação que pode ser editável, só de seleção ou não interativo, um delegate que guarda a seleção e uma fonte de dados de layout.⁷ Nenhum dos talks trata de pontos de inserção, alças de seleção ou um menu de edição sob toque; a orientação de seleção do talk de design é sobre itens, em que “on macOS we recommend to allow modeless selection through click and tap” (2:42), um toque para selecionar e dois para abrir (3:10).⁴

Gestos do sistema, e o controle que não está documentado

O macOS reserva um conjunto de gestos com vários dedos na tela, “controlled by macOS and are therefore not available to any app running” (8:05) (controlados pelo macOS e, portanto, indisponíveis para qualquer app): três dedos para cima para o Mission Control e para baixo para o App Exposé (8:13), uma pinça com o polegar e três dedos para mostrar os apps e o movimento de abrir para revelar a mesa (8:22), três dedos para a esquerda ou para a direita entre espaços (8:32), deslizes a partir das bordas superior e inferior para uma barra de menus e um Dock ocultos (8:37), um deslize sobre a Dynamic Island para chamar a Siri (8:46) e deslizes nas bordas para a Central de Notificações e a Central de Controle (8:51).⁴

O talk de AppKit esbarra no conflito com três sliders: “if I try to control three or more sliders in the same direction at the same time, I get the system gesture instead” (8:17) (ao mover três ou mais sliders na mesma direção ao mesmo tempo, recebo o gesto do sistema), e mostra o controle: “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), com o aviso “Only disable system gestures if the interaction capabilities they open up are critical for the window” (8:42) (só desative os gestos do sistema se as interações que isso libera forem essenciais para a janela).³ A listagem de código da página do talk nomeia os três: disablesDirectTouchSystemGestures no NSWindow, prefersDirectTouchSystemGesturesDisabled no UIViewController e directTouchSystemGesturesDisabled() em uma View do SwiftUI.³ Nenhum dos três está na documentação da Apple em 28 de outubro; os endpoints JSON retornam 404 e os símbolos não aparecem nos índices do AppKit, do UIKit e do SwiftUI.⁷ Minha leitura, não uma afirmação da Apple: eles são o sinal mais claro de que o SDK que os talks pressupõem é o marcado como “Coming soon.”

SwiftUI e Mac Catalyst

O SwiftUI ganha um tipo novo: “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) (se precisar distinguir mouse de toque direto, use a nova API GestureInputKinds).³ GestureInputKinds está documentado nas sete plataformas na versão 27.0, com .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 e .all, e parâmetros inputKinds: em onTapGesture, onLongPressGesture e nos inicializadores de TapGesture, SpatialTapGesture, LongPressGesture, DragGesture, MagnifyGesture e RotateGesture.⁷ A frase da technote é “Use GestureInputKinds to limit gestures to specific types of input in SwiftUI.”⁶

O Mac Catalyst usa o que o UIKit tem desde o iOS 9: o talk diz “UITouch.touchType and UIGestureRecognizer’s allowedTouchTypes” (0:59); a propriedade documentada é UITouch.type, com o enum UITouch.TouchType, e allowedTouchTypes está no UIGestureRecognizer desde o Mac Catalyst 13.1.³⁷ A formulação do talk é um deslize, não uma API nova.

Live Activities no Mac, à frente da documentação

O terceiro talk é curto e faz uma afirmação grande. “The Dynamic Island has come to the Mac. To fully take advantage of its capabilities, Mac apps now support native Live Activities” (0:05) (a Dynamic Island chegou ao Mac e, para aproveitar plenamente seus recursos, os apps de Mac agora têm suporte a Live Activities nativas), e “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) (apps universais com Live Activities existentes funcionam no Mac sem mudar código, e apps nativos de macOS podem criá-las diretamente pela API de Live Activities).⁵ Posicionamento: “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) (em um Mac com Dynamic Island, elas se integram à borda superior do aparelho; nos outros dispositivos e telas, aparecem na barra de menus).⁵ O código é o do iOS: o modelo de dados em ActivityAttributes (2:36), as apresentações compact e minimal em ActivityConfiguration com o view builder da Dynamic Island (3:24), a única apresentação específica do Mac, “The menu bar expanded Live Activity view is created along with the ActivityConfiguration as a simple view” (3:52), enquanto “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), inícios imediatos, agendados ou por push (4:40), integração “with existing backgrounding technologies on the Mac, like background tasks and user agents” (4:54), ações por meio de App Intents (5:56), e “If you have an iOS activity, there’s no code to port” (7:09) (se você já tem uma activity de iOS, não há código a portar).⁵ Duas regras vêm do iOS: “Only a single Live Activity can be expanded at a time” (3:12), e “An activity is only expanded when interacted with or if explicitly triggered through an alert request” (3:06) (só uma Live Activity fica expandida por vez, e só quando há interação ou um alerta a dispara).⁵

A documentação da Apple ainda não diz isso. O resumo da página do framework ActivityKit cita “the Mac”, mas a Overview diz “On Mac, it appears in the Menu bar,” a lista de plataformas é iOS, iPadOS e Mac Catalyst 16.1, e Activity, ActivityAttributes, ActivityConfiguration, DynamicIsland e a chave NSSupportsLiveActivities não listam a plataforma macOS.⁸⁷ A página de Live Activities das HIG, cujo change log termina em 13 de outubro, ainda descreve só o caminho do iPhone pareado: “Active Live Activities automatically appear in the Menu bar of a paired Mac,” “Clicking the Live Activity launches iPhone Mirroring to display your app,” e, sob “macOS dimensions,” “Use the provided iOS dimensions.” (as Live Activities ativas aparecem automaticamente na barra de menus de um Mac pareado, o clique na Live Activity abre o Espelhamento do iPhone para exibir o app, e as dimensões a usar são as fornecidas para o iOS)¹⁰ Os SDKs concordam com a documentação, não com o talk: no SDK do macOS 27.0 dentro do Xcode 27.1 e no SDK do macOS 27.2 dentro do beta do Xcode 27.2 (27B5019j), a interface macOS do ActivityKit marca ActivityAttributes, Activity, cada request e update como @available(macOS, unavailable), conferido neste Mac (análise do autor). Então a frase certa para um planejamento é a estreita: o talk diz que o recurso existe no macOS Golden Gate, e nem a documentação nem nenhum dos SDKs que verifiquei permite construí-lo ainda. O post sobre a máquina de estados mostra uma implementação de iOS do modelo compartilhado de início, atualização e fim; a duração, o encerramento e os limites de segundo plano próprios do Mac não estão em nenhuma fonte ainda.

Design: o macOS não muda

As regras finais do talk de design são curtas o bastante para manter inteiras. “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) (não redesenhe o app só para o toque; ele deve ter a mesma aparência com e sem toque). “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) (mantenha teclado e mouse como entrada principal).⁴

A única regra espacial é sobre mãos, não sobre posições. “The edges of the display are easy to touch by grabbing the side of the display with my hand” (6:17), então “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), enquanto “the center of the display is best used for coarse, imprecise and big gestures” (6:46) (as bordas, fáceis de alcançar segurando a tela, servem para controles ricos e UI densa, como inspetores e barras laterais de navegação; o centro, para gestos amplos e imprecisos).⁴ Gestos próprios têm três restrições: “your gestures should work with touch and trackpad and possibly Magic Mouse” (7:00), “Avoid adding gestures that only work with touch” (7:05), e “The action your gesture does should be duplicated elsewhere in the UI, for example in a menu” (7:37) (o gesto deve funcionar com o toque, com o trackpad e possivelmente com o Magic Mouse, nunca só com o toque, e sua ação deve estar duplicada em outro lugar da UI, como um menu).⁴ O talk também permite o que o Mac nunca teve: “macOS now allows multiple touch gestures at the same time” (5:30), com os dois sliders do Logic sob dois dedos como exemplo (5:45).⁴ Esse é o lado do usuário da propriedade de exclusividade descrita acima: o padrão do AppKit mantém uma hierarquia de views por vez, e .notExclusive é como um app libera o resto.³⁶

Testando hoje: Sidecar, e o SDK que não chegou

Você não precisa do notebook. “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) (com o beta mais recente do macOS e as ferramentas de desenvolvedor mais recentes, todos os recursos de toque do Mac com tela Touch estão disponíveis com um iPad conectado ao Mac pelo Sidecar), e “The fastest way to get started with touch on Mac is with the Sidecar tools you already own” (12:09).³ A technote exige que o iPad rode o iPadOS 27 e acrescenta uma ressalva sobre a verificação de capacidade (NSScreen.touchCapabilities, um option set com o bit .multiTouch): no macOS 27, a verificação “returns true for all displays when a touch-capable Sidecar display is connected, not just for the Sidecar display,” (retorna true para todas as telas quando uma tela Sidecar com toque está conectada, não só para ela) com o conselho de que “it’s better to handle events regardless of input source and decide on an alternate presentation based on the interaction type, if needed.”⁶⁷

A auditoria do talk, na ordem dele: “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).³ Há também uma skill: “there’s a gesture modernization skill that has an understanding of the features and changes I’ve talked about” (12:16) (existe uma skill de modernização de gestos que conhece esses recursos e mudanças); o bloco do Xcode na página de entrada traz um comentário provisório, TK skill, e nenhuma fonte dá nome a ela.²³

O que os SDKs já lançados contêm, análise do autor a partir dos headers e das interfaces Swift deste Mac: o SDK do macOS 27.0 dentro do Xcode 27.1 (27A9275) declara NSScreen.TouchCapabilities, os cinco novos casos de evento de NSControl, as propriedades de toque do NSScrollView, NSRefreshController, beginDraggingSession(items:gesture:source:) e exclusiveGestureBehavior, todos API_AVAILABLE(macos(27.0)), e a interface macOS do SwiftUICore, que o SwiftUI reexporta, declara GestureInputKinds. Os três controles de gestos do sistema não estão nem nesse SDK nem no SDK do macOS 27.2 dentro do beta do Xcode 27.2 (27B5019j), seja nos headers do AppKit, na interface do SwiftUI ou nos headers do UIKit do Mac Catalyst, e a interface macOS do ActivityKit nos dois marca sua API como indisponível.⁷⁸

Esses são os dois SDKs que verifiquei; o Xcode 27.2 RC (27B48), que o feed de releases da Apple data de 19 de outubro, é mais novo que esse beta e não foi verificado, então as ausências valem para os SDKs citados e não além deles.¹¹

O que instalar para testar hoje, sem que eu tenha testado: o macOS 27.2 (26B123, lançado em 26 de outubro segundo o feed) e o Xcode 27.2 RC, com um iPad no iPadOS 27 pelo Sidecar; a technote descreve o toque pelo Sidecar como funcionando no macOS 27, e o feed não lista nenhum beta do macOS 27.3 em 28 de outubro.⁶¹¹ Uma ressalva das próprias notas do RC: “macOS, watchOS, tvOS, and visionOS SDKs in Xcode 27.2 incorrectly report 27.1 as a valid deployment target,” e “Mac Catalyst builds with a 27.1 or 27.2 deployment target might be unable to use newly introduced API,” (os SDKs de macOS, watchOS, tvOS e visionOS do Xcode 27.2 informam por engano o 27.1 como deployment target válido, e builds de Mac Catalyst com deployment target 27.1 ou 27.2 podem não conseguir usar APIs recém-introduzidas) então não escolha o 27.1 como deployment target do macOS (o feed de releases lista o macOS 27.0.1 e o 27.2 e nenhum macOS 27.1), e interprete um alvo de Mac Catalyst em 27.1 ou 27.2 que não enxerga uma API nova como esse problema conhecido, e não como um símbolo ausente.¹¹

O que não chegou, então: o beta do Xcode 27.3 que a página de entrada promete, o artigo do AppKit para o qual ela aponta, os três símbolos de gestos do sistema e um ActivityKit disponível no macOS (ausentes dos dois SDKs verificados, não verificados no 27.2 RC), e qualquer declaração sobre um simulador. As notas do Xcode 27.2 RC mencionam toque uma vez, como uma correção do Device Hub para a entrada que parava “after a period of inactivity” (após um período de inatividade), e as notas do macOS 27.2 não têm nenhuma entrada sobre toque, gestos ou Live Activities.¹¹ As APIs de toque chegaram com o Xcode 27.1, as regras estão publicadas, e a página de entrada marca o que vem a seguir como “Coming soon.”

Uma auditoria de toque para qualquer app de Mac

Análise do autor, não orientação da Apple: os quatro passos do talk, em ordem, como checklist. Ainda não há nenhum teste em tempo de execução por trás dela.

1. Sidecar com um iPad no iPadOS 27, no macOS e no Xcode mais recentes (macOS 27.2 e Xcode 27.2 RC), e todas as telas do app tocadas antes de qualquer mudança.
2. Uma busca por overrides de mouseDown(with:) e loops de nextEvent(matching:), cada um destinado a control events, a um método de delegate ou a um gesture recognizer.
3. Uma passada pelos controles pequenos e pelas áreas de toque, com a área de toque ampliada onde ajudar e sem mudança de layout; o talk aceita um controle menor desde que o toque continue funcionando nele.
4. Uma lista de tudo o que aparece no rollover, com uma decisão por item: um tooltip continua só para o mouse; uma ação já fácil pelo toque não precisa de nada; um controle essencial ganha um click recognizer só de toque e um lugar em outra parte da UI, como um menu de contexto.

A única coisa que a auditoria não vai produzir é um redesign, porque a primeira regra do talk de design é que não deve haver distinção visual; o único layout que pode mudar com a entrada é um transitório, um popover ou um menu próprio.

O que a Apple não disse

Cada item abaixo é uma pergunta que as fontes deixam em aberto, conferida no comunicado, na página de entrada, nos três talks, na technote, na página de especificações, nas notas do Xcode 27.2 RC e do macOS 27.2 e nas quatro páginas das HIG.

• Qual versão pontual do macOS traz o Touch para a tela integrada, e qual SDK traz os três símbolos não documentados. O comunicado diz “macOS 27” e só cita o macOS 27.2 na nota de rodapé sobre a Siri AI; a página de entrada diz “Xcode 27.3 beta,” “Coming soon.”
• Se um binário compilado com um SDK mais antigo tem o mesmo comportamento de toque que um recompilado com o SDK do macOS 27. O talk diz “all apps”; a technote associa ao SDK novo apenas a mudança em location(in:).
• Apple Pencil ou pressão na tela, e se o vidro detecta um dedo antes do toque. Os talks tratam da ausência de um estado de hover como o do mouse; nenhuma fonte menciona pencil, pressão ou detecção de proximidade, e GestureInputKinds.pencil aparece para o macOS 27.0 como todos os outros membros, enquanto nenhuma fonte diz que a tela detecta um pencil.⁷
• Toque em telas externas ou no modo com a tampa fechada, e se o usuário pode desligar o Touch.
• Edição de texto pelo toque: pontos de inserção, alças, lupa e o menu de edição.
• Acessibilidade com a tela de toque. A página de especificações lista o AssistiveTouch e as Adaptações de Toque entre os recursos do notebook e não diz se são novidade no Mac.⁹
• Como um app “Designed for iPad” recebe toques na tela do Mac, e se isso difere do Mac Catalyst.
• Um caminho pelo simulador ou pelo Device Hub para testar o toque no Mac sem um iPad.
• Conteúdo web: se o WKWebView e o Safari entregam eventos de toque ou de ponteiro às páginas.
• Como as janelas e o conteúdo em tela cheia se relacionam com a Dynamic Island, e qual API de área segura a informa.
• Detalhes das Live Activities no macOS: a versão pontual e o SDK, se NSSupportsLiveActivities é obrigatória, como o push-to-start e o registro no APNs funcionam no Mac, e as dimensões de uma activity nativa do Mac.

O calendário

• 28 de outubro: pré-venda em 30 países e regiões; a página para desenvolvedores e os três talks; a technote está no ar desde 8 de junho.¹²⁶
• 6 de novembro: o notebook chega aos clientes e às lojas.¹
• 18 de novembro, das 9 às 10 da manhã no horário do Pacífico, e 19 de novembro, das 6 às 7 da noite no horário do Pacífico: Group Labs de Touch on Mac, online, com engenheiros e designers da Apple.²
• “Coming soon”: o beta do Xcode 27.3, os recursos de documentação, os recursos de design.²
• Em novembro: a atualização do Apple Creator Studio cujos recursos de toque no Logic Pro e no Final Cut Pro o comunicado descreve; os apps de terceiros que ele cita “will be available later this year” (estarão disponíveis ainda este ano).¹

Principais conclusões

Para quem desenvolve em AppKit: os controles padrão já são nativos para toque; seu código próprio de mouseDown(with:) é emulado até você migrar para control events ou gesture recognizers, e um NSPanGestureRecognizer só de toque com buttonMask = 0 e allowedTouchTypes = .direct é o caminho para uma versão pontual que o talk recomenda; as APIs estão no SDK do macOS 27.0 que você já tem.³⁷

Para quem desenvolve em SwiftUI e Catalyst: seus gestos já funcionam; GestureInputKinds é o único tipo novo do SwiftUI, e a resposta do Catalyst é UITouch.type e allowedTouchTypes.³⁷

Para designers: 36 pontos, invisíveis; nenhum redesign; ações de hover essenciais alcançáveis pelo toque e colocadas também em outro lugar da UI, como um menu de contexto, com os tooltips dispensados; UI densa nas bordas, gestos amplos no centro.⁴

Para o planejamento: teste no Sidecar agora; antes de construir qualquer coisa que desative gestos do sistema ou crie uma Live Activity nativa do Mac, confirme que o SDK instalado declara essas APIs, já que os dois SDKs inspecionados aqui não declaram e o Xcode 27.2 RC não foi verificado; o próximo SDK que a Apple prometeu é o beta do Xcode 27.3.²⁷⁸

Perguntas frequentes

Meu app de Mac atual funciona com o Touch?

A Apple diz que sim para a maioria dos apps: “many existing apps work with Touch right away, because macOS automatically translates touches into clicks,” (muitos apps funcionam de imediato, porque o macOS traduz toques em cliques) e o talk de AppKit diz que os componentes padrão de AppKit, SwiftUI e Mac Catalyst e os gestos existentes “just work.”¹³ Código próprio de tracking do mouse é emulado até migrar para control events ou gesture recognizers; um framework de UI que não é da Apple recebe uma camada genérica de emulação que NSIsTouchNative desliga quando o app passa a tratar o toque por conta própria.³⁶

Como recebo um toque direto no AppKit?

Com um gesture recognizer. O talk diz que “gesture recognizers are the only way to get direct touches on macOS,” e a technote diz que os eventos de toque não passam pela responder chain, pelos event monitors, pelo NSApp nem por sendEvent(_:).³⁶ Um recognizer só de toque define buttonMask como 0 e allowedTouchTypes como .direct.³

Qual é o alvo de toque no macOS?

36 pontos, “the same physical size on display as iOS’s 44 points” (o mesmo tamanho físico de 44 pontos no iOS). Os controles do framework já o atendem sem mudar de tamanho; amplie a área de toque das views próprias, não a view.⁴³

Como testo o Touch sem o novo MacBook Pro?

Conecte um iPad com o iPadOS 27 pelo Sidecar. A condição do talk é “With the latest macOS beta and developer tools” (11:59), e nenhum beta do macOS 27.3 saiu, então a configuração que eu tentaria é o macOS 27.2 com o Xcode 27.2 RC, sem que eu a tenha testado.³⁶¹¹

As APIs de toque já estão no SDK?

Sim, para tudo o que os talks demonstram, exceto os controles dos gestos do sistema e as Live Activities nativas do Mac, que estão ausentes dos dois SDKs inspecionados aqui (o Xcode 27.2 RC não foi inspecionado). O SDK do macOS 27.0 dentro do Xcode 27.1 declara NSScreen.TouchCapabilities, os novos casos de evento de NSControl, as propriedades de toque do NSScrollView, NSRefreshController, exclusiveGestureBehavior e a sessão de arrastar baseada em gestos, e a interface do SwiftUICore declara GestureInputKinds; a documentação da Apple os lista como macOS 27.0 sem marcação de beta.⁷ Os controles de gestos do sistema para janela, view controller e view não estão nem na documentação nem nos SDKs do Xcode 27.1 e do beta do 27.2, o ActivityKit marca sua API como indisponível no macOS nos dois, e a página de entrada marca o beta do Xcode 27.3 como “Coming soon.”²⁷⁸

Um app de Mac pode criar Live Activities?

O talk diz que sim no macOS Golden Gate, com o mesmo código de ActivityKit e WidgetKit do iOS e uma apresentação na barra de menus nos Macs sem Dynamic Island.⁵ A documentação do ActivityKit e as HIG ainda não listam o macOS como plataforma para activities criadas por apps, descrevem o caminho da barra de menus com o iPhone pareado, e a interface do ActivityKit nos SDKs do Xcode 27.1 e do beta do 27.2 marca a API como indisponível no macOS.¹⁰⁸

De onde vêm os fatos deste post?

Do comunicado, do post de notícias e da página de entrada para desenvolvedores, das trilhas de legenda em inglês dos três Tech Talks, com a primeira marcação de tempo de cada citação entre parênteses, da technote de junho, do JSON da documentação da Apple para cada símbolo citado, da página de especificações, das release notes do Xcode 27.2 RC e do macOS 27.2 e das quatro páginas das HIG, tudo consultado em 28 de outubro de 2026, além dos headers e das interfaces Swift dos SDKs do macOS 27.0 e do beta do 27.2 no meu Mac, o que é análise do autor. A cobertura da imprensa não é fonte.

Fontes