A tap is not a click.

On 28 October Apple announced the first MacBook Pro with a touch display, a 14 or 16-inch OLED model starting at $2,899. Preorders are open and it ships on 6 November. Apple says macOS automatically translates touch into clicks, so many existing apps should work with touch from day one.

That sentence is doing a lot of work. It is the right call for Apple, because nobody wants a new laptop that breaks their software. It is also the sentence most likely to stop people looking at their own products. Work and good to use are different things, and we have spent years in the gap between them.

What gets lost in translation

A click carries a promise that a tap does not. A pointer is small, it sits where you left it, and it tells the software where you are before you commit. A finger covers the thing it is pressing, arrives from nowhere and has no resting state. So a translation layer can turn the tap into a click event, but it cannot give you back what the pointer was telling you.

We learned this from the other direction. Every kiosk and touch installation we build starts from the finger, and the first thing that goes is hover. Then the small targets go, then anything that relies on a right click, then the table that only makes sense with a cursor crawling along its rows. Last month we wrote that Android apps were about to meet a cursor. This is the same problem turned over.

"

A translation layer keeps your software running. It does not make it yours to be proud of.

The tools nobody designed

Consumer apps will be fine. They already live on phones. The exposed software is the dense kind: admin panels, CRMs, booking back ends and the operational dashboards that a business runs on. Tooltips that only appear on hover, row actions that stay hidden until the pointer arrives, icon buttons packed tight enough to hit the wrong one. These all work today because nobody touches them.

Web apps have a particular trap here. CSS can ask whether the device can hover, but the plain query only describes the primary input. On a laptop with a trackpad and a touchscreen, we expect that to keep reporting a pointer, which means a layout gated on it would carry on assuming nobody is using a finger. The any-pointer and any-hover queries ask about every input on the machine, and that is the question you actually want answered.

/* Primary input only: a touch laptop can still match this */
@media (hover: hover) {
  .row-actions { opacity: 0; }
  .row:hover .row-actions { opacity: 1; }
}

/* Any input on the machine can be a finger: keep actions visible */
@media (any-pointer: coarse) {
  .row-actions { opacity: 1; }
}

What we would check this week

• 01Find everything that only exists on hover. If an action or a piece of information is hidden until a pointer arrives, it needs another way in.
• 02Measure your small controls. WCAG 2.2 sets 24 by 24 CSS pixels as the AA minimum, and that is a floor, so we design well above it for anything a finger will reach.
• 03Check right-click and drag. If a job can only be done with either, give it a visible alternative.
• 04Test on the real hardware when it lands. We have not had a finger on one yet, and nobody should trust a claim about how a browser reports it until they have.

Should clients care

Not enough to rebuild anything. This is a premium laptop at launch, the mini-LED models stay on sale without touch, and most people will carry on using the trackpad. We would not redesign an internal tool around a machine a handful of your staff might own next year.

We would fold this into normal maintenance, because none of these fixes are really about Apple. Visible actions, bigger targets and fewer hidden gestures help the person on a tablet, the person using a keyboard and the person with a tremor just as much. The touchscreen Mac is simply a good excuse to do work that was already overdue.