Back to the blog
BunAppleFrontendPerformance

Touchscreen MacBook Pro: what changes if you use Bun

October 29, 2026·6 min read·Diego Horvatti

Apple spent years saying touchscreens on laptops made no sense. Now it sells a MacBook Pro with a PROLED XDR touchscreen. The touchscreen MacBook Pro is the news of the month for anyone who lives inside a Mac. I use Bun every day, so my question is simple: does this change anything in my code, or is it just a prettier screen?

Spoiler: it changes less than the marketing suggests and more than the skeptics admit.

What Apple announced

Here's the short version. The MacBook Pro got a new generation of display, called PROLED XDR, and the screen now supports touch. The XDR line was already Apple's bet on high brightness and contrast for people who work with images. What's new is the new panel combined with touch, something the Mac never had out of the box.

I won't repeat the spec sheet here. It's on Apple's page, and brightness in nits doesn't compile your project. What I care about are two practical consequences:

  • Some of your users will open your web app on a Mac with their finger.
  • A lot of people will upgrade their machine and expect everything to get faster on its own.

Both hit anyone who writes TypeScript and runs Bun.

Does a new laptop make Bun faster?

It does, but for the wrong reason. Every Mac upgrade comes with the same ritual. You open the terminal, run bun install and feel happy because it finished sooner. But Bun was already fast on the old machine. The bottleneck in your day is rarely there.

Try it. Measure what you actually wait for every day:

# clean install
rm -rf node_modules && time bun install

# your test suite
time bun test

# the production build
time bun run build

In my case, on a mid-sized monorepo, bun install with a warm cache already took a few seconds. What was slow was the TypeScript type-check and the web app build. A new machine trims that a bit. It won't fix a tsconfig that checks the whole folder, or a test that spins up a real database for every file.

New hardware hides slow code. It doesn't fix it.

If your workflow is slow, first look at what you can cut. Tests that can run in parallel, a leaner TypeScript include, a build cache nobody set up. That works on the new Mac, on the old one and in CI, which is where you pay by the minute.

Touchscreen on the Mac: what changes in your frontend

This is the part that makes the article worth it. For years, a lot of people wrote CSS like this:

/* "desktop = mouse" */
@media (min-width: 1024px) {
  .card:hover .actions { opacity: 1; }
  .actions { opacity: 0; }
}

The logic was: big screen, so there's a mouse, so there's hover. With a touchscreen Mac, that assumption is gone for good. It was actually already wrong since touchscreen Windows laptops and the iPad with a keyboard. But the Mac was the safe haven for people who ignored it.

The user taps the card, there is no hover, and the actions stay invisible. The bug doesn't show up on your work Mac. Only on someone else's machine. The worst kind of bug.

The right way is to ask about capability, not size:

.actions { opacity: 1; }

@media (hover: hover) and (pointer: fine) {
  .actions { opacity: 0; }
  .card:hover .actions { opacity: 1; }
}

Now hover becomes an enhancement for mouse users, and touch users always see the buttons. Notice that the default rule is the one that works for everyone.

The same reasoning applies to JavaScript. If you still have duplicated mousedown and touchstart in your code, switch to Pointer Events:

el.addEventListener('pointerdown', (e) => {
  if (e.pointerType === 'touch') {
    // larger touch area, no tooltip
  }
  startDrag(e)
})

One event, three input types: mouse, pen and finger. Less code and fewer bugs.

Other things I'd review right away:

  • Touch targets. A 24px button works with a mouse and frustrates a finger. Aim for about 44px of clickable area.
  • Tooltips. If the information only shows on hover, it doesn't exist for touch users.
  • Gestures. Dragging with a finger can fight with page scroll. Use touch-action: none only where needed, never on body.

How to test this with Bun without the new Mac

You don't need to buy the machine to validate it. Bun serves HTML directly, with hot reload, which makes this kind of test really quick:

bun ./index.html

With the server running, open Chrome DevTools, turn on device emulation and enable touch mode. The (hover: hover) media query starts responding like it would on a touchscreen. To be sure, test on your phone over the local network. It's the cheapest test there is.

If you want to lock this down in CI, you can write a Playwright test that simulates touch and run it with Bun. Something like this:

import { test, expect } from '@playwright/test'

test.use({ hasTouch: true, viewport: { width: 1512, height: 982 } })

test('card actions visible without hover', async ({ page }) => {
  await page.goto('http://localhost:3000')
  await expect(page.locator('.card .actions').first()).toBeVisible()
})

Look at the viewport: laptop size, with touch. That's exactly the case your suite has probably never covered.

HDR display and color: a detail few people check

An XDR display shows color and brightness most monitors can't reach. For dashboards, photo apps and anything visual, that has two effects.

First: an image with the wrong color profile looks even stranger on a good screen. If your image pipeline strips the ICC profile to save bytes, the brand red may come out different from what the designer approved.

Second: CSS already has color(display-p3 ...) and the (dynamic-range: high) media query. You can offer a more vivid color to people with a capable screen, without breaking it for people without one:

.highlight { color: #e63946; }

@supports (color: color(display-p3 1 0 0)) {
  .highlight { color: color(display-p3 0.95 0.2 0.25); }
}

It's a detail. But it's the kind of detail that separates a polished product from one that just works.

Is it worth upgrading because of this?

My honest take: if your current Mac is Apple Silicon and handles your day, no. The gain in bun install and bun test will be a few seconds, and you weren't waiting much for them anyway. Touch is interesting, but nobody codes by poking the screen. Your arm gives up in ten minutes, and the screen turns into a fingerprint museum.

If you're still on Intel, that's a different conversation. And the reason is the chip, not the screen.

What I'd do today, whether or not you buy one: open the project, search for every :hover and every mousedown, and ask if it works with a finger. That fix pays off on Mac, Windows, iPad and phones. It's the kind of improvement that costs an afternoon and lasts for years.

The new screen is beautiful. What makes sure your app works on it is code that assumes nothing about who's on the other side. That's how I try to build the projects I maintain.

LinkedIn summary

Apple now sells a MacBook Pro with a touchscreen, and your `:hover` may have just broken.

For years we wrote CSS assuming a big screen always came with a mouse. That assumption is gone for good.

The user taps the card, there is no hover, and the buttons stay invisible. The bug doesn't show up on your Mac. Only on someone else's.

The fix is to ask what the device can do, not how big the screen is: `@media (hover: hover)`, Pointer Events and 44px touch targets.

And about upgrading your machine for Bun: `bun install` was already fast. New hardware hides slow code. It doesn't fix it.

I wrote about how to test all of this with Bun without buying the new Mac. The link is in the comments.

#Bun #Frontend #CSS #WebDev #TypeScript