Here is a familiar small-business scene. You launch a new website. It looks fine on your laptop. A client messages two days later: the Add to cart button does nothing on their iPhone. You take screenshots. You paste them into Slack. Someone replies “works on my machine.” Three days disappear.

A lot of that pain is Safari. Many people still buy on iPhone. Most design and AI coding tools still look at the site through Chrome. The two browsers are close. They are not the same. Date pickers break. Sticky headers cover buttons. Checkout forms fail quietly.

Safari 27 gives your coding assistant a way to look at the real Safari page, click through it, and tell you what broke. Apple built that hook itself. This is not a chatbot sitting in the browser sidebar. The assistant can open tabs, read what is on the page, take screenshots, watch network requests, fill forms and report the error.

You do not need to become a browser engineer. You do need a Mac, Safari 27 or later, and a coding assistant that can use outside tools. Claude Code and OpenAI’s Codex are the obvious ones today.

What this is, in plain language

Think of it as giving the assistant eyes and hands inside Safari, on your own computer.

Two checkboxes and one command turn it on.

  1. Safari > Settings > Advanced > Show features for web developers
  2. Developer > Allow remote automation and external agents
  3. Then, if you use Claude Code:
claude mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp

Codex is the same idea with codex mcp add. Other tools get a short config file pointing at /usr/bin/safaridriver. When the assistant takes control, a banner appears on the Safari window so you can see who is driving.

Nothing here phones home to Apple. The connection stays on your machine. Safari does not hand over your bookmarks, iCloud tabs or personal browsing. What the assistant sees goes to the tool you already run, not to Cupertino.

The feature is off by default for a reason. First commands fail if no controlled window is open yet. That is a setup detail, not a product flaw.

Why a non-developer owner should still care

If you pay an agency or a freelancer for websites, this is a QA cost story.

A mid-size agency still puts a human through Safari because Chrome-only checks miss iPhone bugs. That hour shows up on every launch. If an assistant catches the same two checkout bugs, spend the human hour on copy, offer and trust.

If you are the person who “just updates the site,” this is how you stop finding out about broken forms from a customer.

Do the first tests on a staging site, not on a live ads manager, bank or client CRM. Watch the banner and the click path once before you point it at anything logged in.

What an SMB or agency should test this week

  1. Checkout on staging. “Open this cart in Safari, add the bestseller, apply the 10% code, go to payment. Screenshot every state. List console errors and failed network calls.” Compare that write-up with your last manual QA sheet. If it finds the same bugs, you can cut a junior hour off every launch.
  2. Phone width, not just desktop. Ask it to look at the page at iPhone size, around 390 by 844 pixels, and rerun the form. This is where small-business sites still break: date fields, sticky headers, buttons that sit under the browser chrome.
  3. The pages that make money. Home, pricing, contact, checkout. Ask for missing labels, poor contrast and anything a screen reader would stumble on. Use that as a pre-launch gate, not as a full redesign brief.
  4. Safari versus the browser you designed in. “Compare the main button on this page with this Chrome screenshot.” Clients still use Safari. Your design file does not care. Now the assistant can.

What a solo should test this week

Solos lose days to “a user said the button did nothing.”

  1. The form that dies quietly. Contact form, booking widget, Stripe checkout. “Fill it with dummy data, submit, tell me which request failed.” One afternoon of this beats another week of screenshots.
  2. The ship loop. After your coding assistant writes a new section, do not switch windows and describe the bug in words. “Open the local site, screenshot it at phone and desktop width, list layout problems.” Less hopping. Fewer typed descriptions of what you can already see.
  3. One messy client site you already know. If the assistant starts writing poetry about colours instead of naming the failed request, tighten the instruction: “Only report broken clicks, error messages and failed network calls.”

Skip this if you do not ship websites and do not own a Mac. It will not run your company. It will stop you shipping a cart that fails in Safari.

The honest limits

This is a developer tool, explained for the person who pays for the website. It is not a magic tester for every app. It will not replace a careful human on a brand-new custom widget. It will not scrape the web in secret. Treat it as eyes and hands on the page you are already building.

Test the staging checkout today. If you get a usable bug list in under five minutes, add it to the launch checklist. If it flails, keep it for screenshots and error logs and wait for the next Safari update.