Cross-Browser Compatibility Testing on macOS Mojave and Safari 12

To test a website on macOS Mojave and Safari 12, use a Mac or cloud browser session that provides that exact operating system and browser version, then record both versions with every result. Automate repeatable interactions with Safari’s safaridriver WebDriver support and manually inspect visual or workflow details that your assertions do not cover. Safari Technology Preview is a separate, frequently updated app; it cannot reproduce a Safari 12-specific issue.

This is a targeted legacy validation setup, not a general-purpose current compatibility baseline. Use it when reproducing a report, supporting an explicitly identified legacy audience, or investigating a historical defect. Apple documents Safari WebDriver for Safari 12 and later, and BrowserStack’s capability documentation identifies macOS Mojave with Safari 12.0. Check current provider catalogs before depending on that pairing.

1. Define the test target

Write down what you need to learn before choosing a test environment. “Safari” alone is not a sufficiently precise target: WebKit behavior changes between releases, and a newer Safari build may not reproduce the same bug.

Reproducing a report: record the reported macOS version, Safari version, URL, steps, and expected versus actual result.
Maintaining legacy support: identify the specific user-visible workflows and layouts that must continue to work.
Investigating a historical defect: preserve the old browser and OS pairing in the test notes so a newer build’s result is not mistaken for reproduction.

Set a viewport and test data as well as the OS and browser. For responsive defects, repeat the workflow at the reported viewport and at the relevant breakpoints. Include keyboard use, form validation, navigation, state changes, and media behavior if they relate to the issue.

2. Choose how to access Mojave and Safari 12

Route	Useful when	Check before relying on it
Local Mac	You need hands-on debugging, local network access, or a controlled environment.	Confirm that the machine can run the required macOS version and Safari release. Plan for setup and maintenance.
BrowserStack	You want remote access to older Safari without maintaining a dedicated test machine.	BrowserStack documents Mojave with Safari 12.0 and advertises older Safari versions including 12.1. Confirm the exact selector remains available for your account and workflow.
Sauce Labs	You need broader cloud browser coverage or live and automated sessions.	Its reviewed materials describe Safari testing, but do not establish Mojave/Safari 12 availability. Verify the exact pairing before choosing it for this task.
Safari Technology Preview	You want to explore upcoming WebKit behavior.	It is a separate app with newer WebKit updates, not a Safari 12 substitute.

Cloud inventories change. A provider’s general claim that it supports Safari, or even older Safari, does not guarantee this specific OS/browser combination is available now. Verify the exact configuration before writing automation around it. A local Mac is useful only if it can actually run the target version; the sources reviewed do not identify a particular Mac model as the recommended choice.

3. Run a repeatable test workflow

Open the target site in the confirmed Mojave/Safari 12 environment.
Set the required viewport and prepare deterministic test data.
Follow the steps from the report or the acceptance criteria. Check navigation, forms, state changes, responsive layout, keyboard interaction, and relevant media.
Automate stable interactions with WebDriver where practical; retain manual inspection for rendering and workflows not covered by assertions.
Record the exact OS, Safari version, viewport, URL, result, and reproduction steps. Capture evidence only when it helps explain the defect.
Repeat the same behavior in the other browser/OS configurations your product supports. Keep results tied to each exact environment.

Apple describes WebDriver as a cross-browser API for automating web content interactions and identifies Safari’s driver as safaridriver. The Safari resources include command references for Safari 12 and later. Consult Apple’s Safari WebDriver documentation and Safari resources for setup and version-specific details. WebDriver can make interactions repeatable, but it does not eliminate the need to inspect the parts of the page your test does not assert.

4. Automate interactions with safaridriver

For a local setup, enable Safari’s remote automation in Safari’s Develop menu, then use Apple’s documented safaridriver and WebDriver setup for the installed Safari release. Exact setup steps can depend on the macOS and Safari version; follow the Apple reference for that target rather than assuming a command or permission flow from a current Safari release applies unchanged.

Structure automated checks around observable behavior: whether a link navigates, a form shows the expected result, or a control changes visible state. Keep browser-specific implementation assumptions out of assertions unless the defect itself requires them. Use the same test intent with other WebDriver-compliant browser drivers for cross-browser comparison.

Retain a manual pass for visual details, focus and keyboard flow, timing-sensitive interactions, and other issue-specific behavior your assertions do not cover. A screenshot can show a rendering difference, but does not establish that an interaction works.

5. Capture and compare visual evidence

For a visual defect, capture the same URL, viewport, page state, and test data in each environment. A screenshot helps compare layout and rendering, while manual inspection or interaction tests are still needed for behavior such as keyboard focus, validation, and state changes. Avoid treating screenshots from different viewport sizes or page states as a browser-only comparison.

You can capture a reference page with a browser automation setup in your chosen environment, or use a screenshot service when you need a URL-to-image result without managing the capture browser. ScreenshotNeo is a website screenshot API and MCP server. Its API can return PNG, JPEG, WebP, or PDF, and its options include viewport and device presets, full-page capture, element selection, custom CSS and JavaScript, and wait conditions. For this legacy test, treat a remote screenshot as visual evidence only; it does not prove the capture ran on Mojave and Safari 12 unless that exact environment is explicitly provided.

Or skip the browser setup

For a URL-to-screenshot capture, ScreenshotNeo takes one GET request and returns an image or PDF. See the ScreenshotNeo API documentation for request options. This captures a page for visual inspection; use an actual Mojave/Safari 12 browser session when you need to reproduce version-specific behavior.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. Responses identify the page verdict and billing status in headers.
An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.
1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000. Every feature is on every plan.

6. Troubleshooting

Symptom	Likely cause	What to do
The issue does not reproduce on a newer Safari.	The newer build uses a different WebKit version than Safari 12.	Confirm the exact Mojave/Safari 12 pairing and repeat there; record both versions in the result.
The cloud provider offers Safari but not the requested setup.	Its current inventory may not include that OS/browser combination.	Inspect the live selectors and confirm Mojave with Safari 12.0 specifically before committing to the workflow.
A preview build behaves differently.	Safari Technology Preview tracks newer WebKit and is not the fixed target.	Use it for forward-looking checks only. Reproduce the defect in Safari 12.
WebDriver automation does not cover the reported problem.	The assertions may test interactions but miss visual rendering or an unmodeled workflow.	Add a targeted assertion if the behavior is observable and stable, then manually inspect remaining visual or workflow details.
Local and cloud results disagree.	The environments may differ in OS/browser version, viewport, network access, test data, or virtualization.	Compare those details first and record them with both results. Check whether the site or required assets are reachable from each environment.
A screenshot appears different but the cause is unclear.	The captures may have different viewport sizes, page state, loaded content, or timing.	Align viewport and state, wait for the relevant content, and use interaction testing for behavior a still image cannot demonstrate.

7. Performance, reliability, and cost considerations

A local target machine has setup and maintenance costs, but can help with direct debugging and access to local or internal sites. Cloud sessions can reduce machine setup and help with remote or parallel coverage, but their precise browser inventory, local-site access, and current pricing depend on the provider and account. Confirm those details directly before estimating cost or designing a required test path.

For reliable comparisons, control the inputs: exact browser and OS, viewport, URL, test data, and relevant wait conditions. Repeat a failure to distinguish a stable defect from a timing or environment issue. Do not infer overall compatibility from a single successful screenshot or a single automated workflow.

Safari Technology Preview release 62 listed a WebDriver hang as a known issue on Mojave beta. That note applies to that preview build context; it should not be generalized to Safari 12 or current Safari.

Frequently asked questions

Is Safari Technology Preview equivalent to Safari 12?

No. It is a separate app that receives newer WebKit updates, so it is useful for previewing upcoming behavior but not for reproducing a Safari 12-specific issue.

Does “Safari testing” confirm Mojave and Safari 12 are available?

No. Confirm the exact operating system and browser release in the current local setup or cloud catalog.

Can screenshots replace WebDriver tests?

No. Screenshots help inspect appearance. WebDriver checks interactions, and manual review covers behavior and visual details your assertions do not test.

Should every project treat Mojave and Safari 12 as a required baseline?

No. Use this pairing when a reported issue, supported legacy audience, or historical investigation calls for it. The reviewed evidence does not establish it as a current general-purpose baseline.

Sources

Apple: Testing with WebDriver in Safari.
Apple Safari resources, including Safari 12 and later WebDriver references.
Apple Safari Technology Preview.
BrowserStack Safari testing and its capability documentation for legacy Safari configurations.
Sauce Labs Safari and cloud testing information; the reviewed material does not verify this exact legacy pairing.

For a capture API and MCP server for developers, visit ScreenshotNeo.