Test in real Safari and on real macOS
For QA teams and web agencies that need to see how a website behaves in Safari, or how a Mac application behaves on a real macOS installation. Run manual checks, automated UI tests and screenshot comparisons on a Mac you control.
- 01
Test suite
Your scripts and cases
- 02
Safari on macOS
Real macOS environment
- 03
Results
Reports and screenshots
What this solves
Safari bugs you cannot reproduce on Windows
WebKit engines in other tools are close, but not identical to Safari. Layout and media issues often only show up in real Safari.
Testing a Mac app before release
Installers, permissions prompts, notarisation and sandboxing behave differently on a real Mac than in a description.
Unreproducible test results
A dedicated machine with a known macOS and browser version gives consistent screenshots and test runs.
Example workflow
Nightly Safari regression run
- 1
Your CI system starts a job on the Mac every night.
- 2
safaridriver drives Safari through your Selenium or WebdriverIO test suite.
- 3
Screenshots of key pages are compared with yesterday's baseline.
- 4
Differences and logs are uploaded to your CI system for review.
- 5
A tester opens Screen Sharing to reproduce a failing case by hand.
Testing matrix
What a single hosted Mac can cover, and where you need something else.
| What you want to test | On a hosted Mac | Notes |
|---|---|---|
| Safari on macOS | On a hosted MacYes | NotesThe Safari version that ships with the macOS version on the Mac. |
| Safari Technology Preview | On a hosted MacYes | NotesCan be installed alongside regular Safari. |
| Chrome, Firefox and Edge on macOS | On a hosted MacYes | NotesYou install and update them yourself. |
| Mac app installers, permission prompts and notarised builds | On a hosted MacYes | NotesFull admin access; you reset the machine between test cycles. |
| Mobile Safari in the iOS Simulator | On a hosted MacPartly | NotesUseful for layout checks, but it is not a physical device. |
| Older Safari versions on the same Mac | On a hosted MacNo | NotesSafari is tied to the macOS version. Use one Mac per version. |
| Physical iPhones and iPads | On a hosted MacNo | NotesUse your own devices or a device cloud. |
How to set it up and run it
- 1
Choose the macOS version you want to test on at order time
Note it in your test reports, because Safari versions follow macOS updates.
- 2
Enable Remote Automation in Safari settings and run safaridriver --enable once for automated tests.
- 3
For Mac apps, use XCUITest from Xcode, or tools such as Appium with the Mac2 driver.
- 4
Keep macOS and Safari updates under your control
Delay automatic updates so a test run is not interrupted by an upgrade.
- 5
To return to a clean state, reinstall macOS through the optional JetKVM with virtual media, or keep a scripted setup you can rerun.
Which configuration fits
Who does what
vBoxx provides
- A dedicated Mac mini with one known macOS and Safari version, chosen at order time
- Optional JetKVM console with virtual media for clean reinstalls between test cycles
- Remote APC power control to recover a machine stuck in a test, included
- Network: 10 Gigabit Ethernet port · 1 Gbit/s unmetered · public IPv4 + IPv6
You manage
- Test frameworks, test data and CI integration
- Choosing when to update macOS and Safari
- Resetting the machine between test cycles
- Accounts and credentials used in tests
Before you choose this setup
- No physical iPhones or iPads are included or connected. For tests on real mobile devices, use your own devices or a device cloud.
- One Mac runs one macOS version. Multiple simultaneous macOS environments on one Mac are not part of the service.
- For wide cross-browser coverage across many browser versions, a browser-testing cloud may be more practical. A hosted Mac fits when you need real Safari and full control.