Testing Safari Differences: Sequoia vs Ventura

The quickest way to find Safari rendering regressions between macOS Ventura and macOS Sequoia is to run the same test suite against system Safari on two hosted Macs and diff the JSON results. Request two Figment M-series Macs at /mac-hosting/start, pin each to the OS and Safari build you ship against, and run the comparison script at the bottom of this page.

Before the script, one correction worth making up front. Safari 16 shipped with macOS Ventura in 2022; Safari 17 shipped with macOS Sonoma in 2023; Safari 18 shipped with macOS Sequoia in 2024, and Safari 18 is also installable on Ventura and Sonoma through Software Update (WebKit — Safari 18.0). So the real fork is the exact Safari build on the exact OS, not the OS name alone. Pin the Safari version on each runner, confirm it in /Applications/Safari.app/Contents/Info.plist, and pause automatic updates during a comparison window.

What Changed Between the Default Safari Builds

These are the behaviours that most often appear as new test failures when teams compare Ventura's default Safari 16 against Sequoia's default Safari 18. Verify against the WebKit release notes for your exact point release.

A test that calls document.startViewTransition throws on Safari 16 because the function is undefined. A visual check that relies on unprefixed backdrop-filter renders as a no-op. The comparison run surfaces every such gap in a single table instead of one bug report at a time.

Why Playwright's WebKit Is Not Enough

Playwright ships a bundled WebKit build that is identical on every OS. Running browserName: 'webkit' on a Sequoia Mac and a Ventura Mac measures the same WebKit, not the system Safari each OS actually installs. To expose OS-specific Safari differences you need to drive system Safari through Apple's built-in WebDriver, safaridriver (Apple — About WebDriver for Safari). Enable it once per Mac with safaridriver --enable and point a WebDriver client (Selenium, WebdriverIO, or Playwright with a custom WebDriver bridge) at http://127.0.0.1:4444.

Two Hosted Macs: What the Options Cost

Request two M-series Macs — one with Ventura, one with Sequoia — at /mac-hosting/start. Figment's M-series listing starts at $95/month; the exact chip, RAM and disk are confirmed in the quote, and physical M-series plans are filled as supply is confirmed. If you need managed CI, Managed Build Mac is $249/month and includes one M-series Mac, CI setup, backups, monitoring, and 30 minutes of monthly support.

Current published entry prices on comparable providers, pulled on 2026-11-10:

For two Macs running for one year, Figment's listed entry is 2 × 12 × $95 = $2,280; two CloudMac annual reservations are 2 × $999 = $1,998, when both regions are available. Figment's $95 entry is a lower monthly entry than CloudMac's $99.99 M4/16 GB listing, but the two are not necessarily the same hardware class until Figment's quote confirms the chip and RAM — compare entry price, then compare the configured build. The material difference to weigh against a lower sticker is Managed Build's bundled CI setup, backups, monitoring and included support minutes at $249/month on one Mac.

Access Pattern on Figment

The $29 virtual Intel macOS plan (2 vCPU, 8 GiB RAM, 80 GiB disk) is useful for Intel toolchain work and for running compatible Xcode 26 or earlier on x86_64 (Apple — Porting your macOS apps to Apple silicon), but Safari UI testing wants Apple silicon and the real system Safari, so use M-series Macs for this job. Access on the VM is the browser-based desktop console today; for M-series Macs confirm the access and network ports you need (WebDriver port, GitHub Actions outbound, artifact upload) at order time.

The practical pattern is a self-hosted CI runner on each Mac that pulls jobs outbound and uploads artifacts — no inbound SSH required. Current guidance for locking those runners down is at GitHub docs — Hardening for self-hosted runners.

The Comparison Workflow

On each Mac, as the login user that will run tests:

# one-time, on each Mac
safaridriver --enable            # requires admin password once
npm ci
npx wdio run wdio.safari.conf.js # your WebDriver runner; writes results.json

A minimal WebdriverIO config targets local Safari:

// wdio.safari.conf.js (identical on both Macs)
exports.config = {
  runner: 'local',
  hostname: '127.0.0.1',
  port: 4444,
  path: '/',
  capabilities: [{ browserName: 'safari' }],
  specs: ['./tests/**/*.spec.js'],
  reporters: [['json', { outputDir: './results', outputFileFormat: () => 'results.json' }]],
  baseUrl: process.env.APP_URL || 'https://your-app.staging.example.com',
};

Upload results/results.json from each runner as a CI artifact named by OS (results-ventura.json, results-sequoia.json). Then, in a coordinator job that downloads both artifacts, diff them:

#!/usr/bin/env bash
# compare-safari.sh ventura.json sequoia.json  — example, not a benchmark
set -euo pipefail
node - "$1" "$2" <<'JS'
const fs = require('fs');
const [,, vFile, sFile] = process.argv;
const load = f => {
  const d = JSON.parse(fs.readFileSync(f, 'utf8'));
  const m = {};
  (d.suites || []).forEach(s => (s.tests || []).forEach(t => {
    m[`${s.name} › ${t.name}`] = t.state || t.status || 'unknown';
  }));
  return m;
};
const v = load(vFile), s = load(sFile);
const names = new Set([...Object.keys(v), ...Object.keys(s)]);
let diff = 0;
console.log(`${'Test'.padEnd(70)} ${'Ventura'.padEnd(10)} ${'Sequoia'.padEnd(10)} Diff`);
for (const n of [...names].sort()) {
  const a = v[n] || 'missing', b = s[n] || 'missing';
  const d = a !== b; if (d) diff++;
  console.log(`${n.slice(0,69).padEnd(70)} ${a.padEnd(10)} ${b.padEnd(10)} ${d ? 'YES' : ''}`);
}
console.log(`\nTotal: ${names.size}  Divergent: ${diff}`);
process.exit(diff > 0 ? 1 : 0);
JS

Treat the output as a worksheet, not a benchmark. Failing jobs must fail the pipeline; do not count a crashed run as a passing comparison.

Reading the Report and Deciding

Three signals decide whether to drop Ventura support:

1. Your own analytics of Safari-on-Ventura user share.
2. The divergent-test count from the script above — small lists are polyfillable, large ones aren't.
3. Roadmap features that only land on Safari 18 (View Transitions, @starting-style, content-visibility).

Record the decision in a short BROWSER_SUPPORT.md so it is not re-litigated every release. Start two Macs at /mac-hosting/start or review plan options at /mac-hosting.

Related Reading

• mac-simulator-ats-exception-test
• mac-safari-extension-permission-test
• mac-github-actions-self-hosted-runner