Confirm your application works across operating systems. Autonomously.

Give your existing agent a fresh macOS machine for the application journey. It can run guest jobs, drive native controls, inspect screenshots and accessibility state, and compare the evidence with an earlier run. Your desktop stays yours.

Source-installed development prototype. Used in Reflow QA on one Apple Silicon host with macOS 27 guests. SwiftVM is not bundled with the public CLI; compatibility across other OS versions, Windows and Linux remains unproven.

Less manual desktop testing.
More evidence for your agent.

Delegate the journey through Reflow, then review what the application actually did. The source-installed integration already runs native app journeys in Reflow QA.

  1. You define what needs to work.

    A launch, a key interaction, an expected result. Your existing agent uses the application’s checks to decide what to exercise.

  2. Your agent drives the check.

    vm.guest_run starts a fresh, off-screen macOS clone and runs the declared jobs. The MacOSApp guest executor presses controls, waits for state and captures the result.

  3. The evidence comes back.

    Named screenshots, accessibility snapshots, job results and exported files give your agent something concrete to compare and explain alongside the code change.

An earlier prototype recording.
The same isolation principle.

This 16 October recording predates Reflow’s guest_run integration. It shows the native controller building and testing in a guest, launching a sample app and clicking its interface from the host. Its playback trace follows those recorded actions.

The tests ran in the guest.
All three Swift tests passed before the sample counter app launched.
The click changed the application.
Screenshots show 0 before input, 0 in a control frame, then 1 after the host clicked Increment.
The host desktop stayed yours.
The VM ran off-screen. All 133 window-list samples found no VM window on the host desktop.

The current Reflow path stages application inputs and runs guest jobs through vm.guest_run. The MacOSApp guest executor supplies native UI actions and captures; this older counter video is not a recording of that flow.

SwiftVM · disposable macOS runRecorded run, composited
Recorded controller journalLine 8 · selected step

Controller actions from the 16 October recording, before Reflow guest_run integration. This trace follows that recording; the current guest_run flow is shown separately on the VM page. Select a checkpoint line to inspect its output; preceding lines provide context.

Recorded output · selected phase
144.5 sVerdictPassed, with nothing shown on the host desktop

Visual checkpoints · one recorded run

  1. Before input0
  2. No-input control0
  3. After host click1

Within-run delta: 0 → 1 after input; the no-input control stayed at 0. Counts are read from the VM screenshots, not a cross-run snapshot comparison.

  1. 0.0 s Clone Sealed template cloned and checked against its seal
  2. 9.9 s Boot VM started off-screen, no network
  3. 30.0 s Guest ready Guest agent connected to the host
  4. 34.7 s Tests Built in the guest; 3 of 3 tests passed
  5. 135.1 s App launched Sample counter app on the hidden display
  6. 138.3 s Host click Count read from screenshots: 0, 0, then 1
  7. 141.9 s Stopped Stop confirmed; clone removed at 143.3 s
  8. 144.5 s Verdict Passed, with nothing shown on the host desktop

Required checks from this run

  • passed host-window-hidden 133 samples, no window on screen
  • passed test-pass-result 3 of 3 Swift tests passed
  • passed gui-host-input-proof Count 0, 0 without input, 1 after the click
  • passed cleanup-confirmed Clone removed after a confirmed stop

All 19 required checks passed. Coverage was not requested.

Composited from one recorded prototype run (16 October 2026 UTC, one Apple Silicon host, macOS 27.0.1 guest). The macOS frames are captures from the VM’s own display, time-compressed from 144 seconds to 12. The dark intervals are not captures: no frames were kept during clone and boot, and the VM has stopped at the end. The crossfades, zoom and click ring are added. Times come from the run journal. Not a performance figure. This recording predates the source-installed vm.guest_run integration now used in Reflow QA; it does not show that Reflow flow.

Start from a known environment.

A fresh VM helps separate application behavior from the state left by an earlier test. In the prototype, every run starts with a copy-on-write clone of a sealed macOS template; the original stays unchanged.

The guest_run path stages inputs by digest and boots without a network device. The clone is checked against the template’s seal; its Accessibility and Screen Recording grants are checked before the jobs run.

Keep the result open to inspection.

Reflow keeps the guest job results and attached captures with the step. Your agent can compare named window images and accessibility snapshots across runs, then inspect the originals behind a changed result.

  • Named window captures and matching accessibility snapshots
  • Guest job results and exported files, re-hashed on the host
  • Coverage profiles exported by instrumented journeys
  • VM cleanup status and export receipts

Exported files are re-hashed on the host. A guest_run passes only when its jobs succeed, its export is complete and VM cleanup is confirmed. If shutdown cannot be confirmed, the clone stays available for recovery.

A native app journey,
applied through Reflow.

Source-installed SwiftVM already runs application journeys through reflow plan and reflow apply. This excerpt follows the QA wrapper: stage the campaign and executor by digest, check out the application source in the guest, then run the named journey.

The scenario shown is shortened to waiting for the plot and capturing launched. The wrapper also prepares the test app, runs the MacOSApp guest executor, checks its outcomes and exports evidence. Input digests and the export prefix are declared flow inputs supplied for the run.

Compare what the journey exercised.

Reflow QA has compared launch and zoom/back captures and ingested both Go and Swift coverage from the exported profiles. Your agent can relate a visible change to the code the instrumented journey exercised. Coverage establishes execution; it does not establish every application state.

SwiftVM is available for development through a private source checkout and a pinned source-catalog installation. It requires a provisioned, sealed macOS template, a private binding and staged inputs. It is not bundled with the public CLI. The MacOSApp guest executor inherits Accessibility and Screen Recording grants from the template’s guest agent, checked in each clone.

Current guest_run flow · QA excerptSwiftVM
vm.guest_run (
  inputs=json(
    [{"name":"campaign.tar","sha256":"${inputs.campaignTarSha256}"},
     {"name":"pin.bundle","sha256":"${inputs.pinBundleSha256}"},
     {"name":"guest-exec.tar","sha256":"${inputs.guestExecTarSha256}"},
     {"name":"guest-journey.sh","sha256":"${inputs.guestJourneySha256}"}]
  )
  files=json(
    {"scenario.json":{"version":1,"actions":[
      {"do":"waitFor","selector":{"identifier":"gigahog.plot"},"state":"present"},
      {"do":"capture","name":"launched"}]}}
  )
  jobs=json(
    [{"name":"checkout","timeoutMs":300000,
      "argv":["/usr/bin/git","clone","-q","inputs/artifacts/pin.bundle","src"]},
     {"name":"journey","timeoutMs":1200000,
      "argv":["/bin/sh","inputs/artifacts/guest-journey.sh","src",
        "inputs/artifacts/campaign.tar","inputs/artifacts/guest-exec.tar",
        "inputs/files/scenario.json","J01-launch-root","scanned","1","1","0","out"]}]
  )
  exportName="${inputs.exportPrefix}-j01-launch-root"
  timeoutMs=1500000
)

From the source-installed QA wrapper, with a shortened scenario. Requires its staged app, executor and journey script, declared inputs, and a private VM binding. This page does not execute the flow.

Check the rest
of the application.