twimco.Let’s talk ↗︎
Menu
Field notes / Product & engineering

Macs get touchscreens on November 6. Ten things in your web app to tap first

For years you could assume anyone on a Mac had a mouse or a trackpad, so a menu that opens on hover was safe. From November 6 some of those people will reach up and tap the screen. These are the ten places in a web app where that goes wrong first.

Editorial engraving of a bright community radio office where a producer taps a laptop screen while an engineer with a trackpad notes what didn't open.

Apple's MacBook Pro with a touchscreen arrives November 6, 2026, and macOS turns touches into clicks, so most web apps will work without changes. What breaks is anything that needs a pointer to hover: menus, tooltips, row actions and previews, plus targets sized for a cursor. Tap through these ten places before customers do, and fix the ones that only work with a mouse.

What changes on November 6

Apple's new MacBook Pro, on pre-order since October 28 and arriving from Friday, November 6, has a touchscreen. It's the first Mac that does. Apple says you can swipe to scroll, pinch to zoom, drag and drop, double-tap a window to fill the screen and flick it to tile, and draw right on the display.

For anyone who builds web apps, one line in Apple's announcement matters more than the rest: many existing apps "work with Touch right away, because macOS automatically translates touches into clicks." That's good news. Your buttons will press, your links will open and your forms will submit.

It's also the source of the problem. A finger can click, but it can't hover, and a lot of desktop software quietly depends on hover. For years, "desktop Mac" meant "has a pointer," so menus that open on mouseover, tooltips that carry real information and row actions that appear only when the cursor passes by were reasonable shortcuts. From November 6 some Mac users will reach up and tap.

These aren't cheap machines. CNBC reports the 14-inch starts at $2,899 and the 16-inch at $3,399, so early owners skew toward exactly the professional users who live in business software all day.

The ten things to tap

Open your app on any touchscreen laptop you have, or on a tablet with a desktop-size layout, and try each of these with a finger only. No trackpad.

  1. The main navigation. If submenus open on hover, can a tap open them? Does a second tap follow the link or close the menu? Many sites get this wrong in a way that sends people to the parent page they didn't want.
  2. Account and settings menus. The avatar in the corner that reveals "Settings" and "Sign out" on hover is a classic trap.
  3. Table row actions. Edit, duplicate and delete icons that appear only when the cursor is over a row simply don't exist for a finger.
  4. Tooltips that carry meaning. If the only explanation of a field, a status color or an icon is in a tooltip, a touch user never sees it.
  5. Hover previews. Card previews, link previews and thumbnail zooms that appear on mouseover.
  6. Small targets. Close icons, checkbox labels, sort arrows and pagination numbers sized for a cursor. Fingers are much less precise.
  7. Drag handles. Reordering lists, resizing panels and dragging files into a drop zone. Apple says drag and drop works with touch; check that your custom drag code agrees.
  8. Scrolling inside a scroll. A scrollable table inside a scrollable page, or a map inside a form. A swipe has to pick one.
  9. Canvases and editors. Anything you draw, annotate or position with a pointer. Apple specifically pitches drawing on the full display, so designers will try it.
  10. Right-click and keyboard-only features. Context menus and shortcuts that have no visible equivalent. A touch user who has the keyboard right there may still never discover them.

Decision guide

Hover-only versus every input

ConsiderationHover-onlyWorks with a tap
SubmenusOpen when the cursor passes.Open on tap or click too.
Row actionsAppear under the cursor.A visible more button.
TooltipsHold the only explanation.Inline text or a tappable info icon.
TargetsSized for a pointer.Padded and spaced for a finger.
Decision framework for common hover patterns; illustrative, not Apple guidance.
A finger can click, but it can't hover, and a lot of desktop software quietly depends on hover.

Why "it works on the iPad" isn't the answer

If your app already works on an iPad, you're ahead, but don't assume you're done. A lot of web apps serve a different layout to tablets, based on screen width or on what the browser reports about the device. The touchscreen MacBook Pro has a desktop-size screen, desktop Safari or Chrome and a trackpad, plus touch. It will very likely get your desktop layout, with all the hover behavior that layout assumes.

How browsers on the new Mac will report pointer and hover capabilities to your CSS and JavaScript isn't covered in Apple's announcement. Don't build on a guess. Check on a real machine once they ship, and in the meantime write your fixes so they don't depend on detecting touch at all.

Fixes that work for every input

The most durable fixes don't treat touch as a special case. They make sure everything a hover reveals can also be reached with a click, a tap or the keyboard.

  • Make hover a shortcut, not the only path. Menus open on click or tap too. Row actions live behind a visible "more" button as well as appearing on hover.
  • Move important information out of tooltips. If people need it to finish the task, show it inline or behind a visible info control they can tap.
  • Size targets for fingers. Give small controls more padding, and space them apart so a slightly off tap doesn't hit the neighbor. Apple's iOS guidance has long used a minimum target of about 44 points; it's a sensible floor.
  • Test drag code with touch events. Custom drag-and-drop built only on mouse events is a common thing to break.
  • Keep keyboard paths. Pros will still use shortcuts. Touch is an addition, not a replacement.

Most of these fixes also help people using a keyboard, a screen reader or a tablet, which is the best argument for doing them now rather than waiting for complaints.

If the app is large

A big product can have hundreds of screens, and nobody is going to tap every one. Start where people spend their day: the dashboard, the main list or table view, the editor and the settings screens they open weekly. Those few screens usually share components, so fixing the shared menu, the shared table and the shared tooltip fixes most of the app at once.

Then search the code for the patterns themselves. CSS hover rules that change visibility or display, mouseover and mouseenter handlers, and title attributes used as the only label are good places to look. Each one is a question to answer, not automatically a bug: some hovers are decoration and can stay as they are.

When to do it

The machines arrive November 6. Apple is running online group labs for developers about Touch on Mac on November 18, 9 to 10 a.m. PT, and November 19, 6 to 7 p.m. PT, which is a good place to ask about native and web behavior.

Do the ten-item tap-through this week. Fix the ones that block a task first: navigation, sign-out and row actions. Then the ones that hide information: tooltips and previews. Then the comfort fixes: target sizes and spacing. Once real hardware is in hand, check the list again on the device.

If your app has years of hover-first interface decisions in it and you'd rather fix them once, properly, that's work our web applications team does. Talk to us.

Related work: Spin Market.

Sequence of work

From announcement to real hardware

  1. Oct 28

    Announced; pre-orders open.

  2. This week

    Tap through the ten; fix navigation and row actions.

  3. Nov 6

    Machines arrive; recheck on real hardware.

  4. Nov 18–19

    Apple's online group labs on Touch on Mac.

Dates from Apple's Oct 28, 2026 announcement and Developer page; the work order is illustrative.
twimco.

We build alongside the people doing the work.
Bring us the problem you’re thinking about.

Related work

Spin:Market ↗︎