An iOS simulator needs macOS hardware underneath it. VibeView runs that hardware, streams the device into your browser at 30 frames a second, and sends your taps back — so the machine on your desk can be a Windows laptop or a Linux workstation and still drive a live iPhone.
Two ways in. Upload a simulator build and open a session. Or, if you work in React Native, point the VibeView CLI at the Metro bundler already running in your project and develop against the cloud device directly.
Who this is for
Developers building iOS apps on Windows or Linux, and mixed teams where the Macs are outnumbered by the people who need to see the build. If your whole team has Macs and never shows the app to anyone outside it, a local simulator is faster and free — use that.
What you get
A live device, not a screenshot
Tap, swipe, type and use your own keyboard against a running iPhone or iPad. Sessions start on a free device immediately, or queue and start on their own when one frees up.
Hot reload from your local project
The CLI connects a cloud simulator to your local Metro bundler. Save a file and Fast Refresh lands on the device in about a second — no Mac in the loop.
A link anyone can open
Send a URL and the recipient uses your app in their browser. No install, no account, no Xcode. Pin it to a build or let it follow your latest, and revoke it when you are done.
Tests that survive a moved button
Recorded steps replay exactly; an AI agent picks up only the steps where the screen actually changed. Visual regression runs after every step, against a baseline held per device.
Developing against a cloud simulator
This is the part that has no local equivalent when you have no Mac. Upload a debug build once. From then on, live development runs your latest JavaScript on the cloud device against the bundler on your own machine — you only rebuild and re-upload when you add or change a native dependency. Everyday code and asset edits never need a new upload.
It works for tvOS too, so an Apple TV app gets the same loop.
Getting your build in
The one piece of setup that catches people: you need a build compiled against the simulator SDK, not the device one. A .app bundle, on its own or compressed. The upload dialog names the formats it takes.
If your pipeline only produces an .ipa today, that is one extra build target — preparing your build has the command per framework.
Showing it to people who do not have Macs
A share link is an ordinary URL that plays your app on a live device. The recipient taps to start and uses it. You decide which build it serves, which devices it offers, how long a session may run, whether it expires, and whether visitors must log in — and you can revoke it at any point.
To put the device inside your own site rather than send a link, an embed key gives you an iframe you can lock to your domains. Embedding needs Starter or above.
If the worry is an unreleased build sitting on someone else's machines, the controls are: builds are scoped to your organization, members hold roles rather than shared access, changes are written to an audit log, and every share link and embed key is revocable on the spot. Ask us directly about your procurement requirements rather than taking a marketing page's word for it.
Testing without writing a framework suite
Record a flow by using the device, and it becomes a test of numbered plain-English steps. Runs replay those steps directly and hand a step to an AI agent only when the screen no longer matches, so one design change costs one step instead of a red suite. Visual regression compares each step against its own baseline, per device, with separate warn and fail thresholds.
Runs go through the CLI in CI, with JSON or JUnit output and exit codes. AI test authoring is beta, and a run can be set to replay only, with no agent involved at all.
What this does not do
Simulators, not hardware. There is no physical device cloud here. Camera capture, Bluetooth peripherals, NFC, cellular conditions, GPU performance and OEM firmware bugs are not testable on a simulator, and no amount of streaming changes that. Use a real-device service for those and keep a hardware pass before release — simulator vs real device testing sets out exactly which bugs fall on which side.
No network capture yet. The Network Logs tab exists but does not capture traffic — no intercept proxy, no HAR export. If a bug lives in a request body, you are debugging it elsewhere. Device logs do stream.
No importer for existing suites. Tests are recorded or written in our own format. A mature Appium, XCUITest, Espresso or Detox investment does not migrate, and that is a genuine reason to stay where you are.
Rotation is not driven on iOS. If your app rotates itself the stream follows it, but a rotate command cannot force an iOS simulator to turn. Android does rotate on command.
What it costs
Pricing is per organization, not per seat — one pool of sessions and credit for everyone in the team. Streaming is metered on every plan, with overage billed at $0.06 a minute against usage credit, and overage can be switched off so sessions hard-stop instead of billing. AI runs can go through your own provider key, which takes model cost off our bill entirely.
The free tier is a tier rather than a trial: two concurrent sessions, 30 streaming minutes a month, $1 of credit that refills monthly, up to 3 people, no card. Know the limit before you start — each free session ends after 5 minutes, so those 30 minutes come in 5-minute slices. Embedding needs Starter.
Start on the free tier and put your own build on a device, or read getting started for the step-by-step version first.
Frequently asked questions
Can I use an iOS simulator on Windows or Linux?
Not locally — the simulator runtime needs macOS hardware underneath it. VibeView runs that hardware and streams the device to your browser, so the machine on your desk only needs a browser. You upload a simulator build, or point the VibeView CLI at the Metro bundler already running in your React Native project.
Is a simulator good enough to trust?
For layout, navigation, state, permissions dialogs and most regressions, yes. For anything touching real hardware — camera capture, Bluetooth peripherals, NFC, cellular conditions, GPU performance — no. A simulator cannot tell you about silicon it does not have. Plan a pass on physical devices before you ship, whatever else you use.
We already have Macs. What does this add?
The people who need to see the build usually do not have one. A reviewer, a PM, a support agent or a prospect can open a link and use the app in a browser with no install and no account. It also means a CI-built simulator artifact is something anyone in the company can open, rather than something only the iOS team can run.
Can I upload the .ipa our CI already produces?
No. An .ipa is a device build and will not install on a simulator — the upload is rejected with a message saying so. You need a build compiled against the simulator SDK: a .app bundle, uploaded as-is or compressed to .zip, .tar.gz or .tgz, up to 500 MB. For most projects that is one extra CI target, not a rewrite.
What does the free tier actually give me?
Two concurrent sessions, 30 streaming minutes a month, $1 of usage credit that refills each calendar month, up to 3 people, and no credit card. The catch worth knowing before you start: each free session ends after 5 minutes of wall clock, so those 30 minutes are spent in 5-minute slices. Embedding a device in your own site needs Starter or above.
Can I run this in CI?
Yes. The CLI runs a single test or a whole suite and emits human, JSON or JUnit output, with exit codes for the pipeline to branch on. Runs can be pinned to a specific build, and results can post back as GitHub commit statuses, webhooks or Slack messages.