You assemble an app in the browser, the live simulator behaves exactly as expected, you sideload it onto your own iPhone — and notifications never arrive, the purchase button does nothing. These "the simulator never warned me" stumbles aren't tool bugs. They happen the moment you step past the boundary of what the simulator can actually verify.
In 2026, Rork compiles on a cloud-hosted Mac and streams the result back to your browser as a 60fps live simulator, with your touch input flowing through in near real time. Being able to raise the number of times you try an idea, without setting up a heavy local environment, is a meaningful shift — especially if you are an indie developer who has just started building solo. But ride that convenience all the way to submission and you'll hit a device-only trap at the very end. This article draws a firm line between what you can settle in the simulator and what you need to move to a real device through Companion.
The live simulator is fast because it removes the round trip
Understanding the mechanism sharpens your judgment. Rork's live simulator isn't building on your machine. It compiles an iOS simulator on a cloud host Mac and streams that screen to your browser as video. Your taps and scrolls are sent back to the cloud, and the result returns with barely any lag.
The advantage is obvious: without a heavy local toolchain, you can check behavior the instant you make a change. From my own years of building apps solo, the thing that ate the most time was never the app itself — it was the preparation: builds, device transfers, environment setup. The lighter that becomes, the more often you actually test an idea. I cover the mechanism in more depth in how Rork Max's cloud compile works.
But the simulator is exactly that — an iOS simulator. It reproduces iOS on a Mac rather than running on a device, so device-specific hardware, sensors, OS permission dialogs, and the purchase sandbox are either absent or behave differently. Knowing this is the shortest path to avoiding wasted rework.
What the simulator is fully enough for
The following are fine to settle entirely at the live-simulator stage. Moving them to a real device rarely changes the outcome.
- Layout and spacing: element placement, safe-area avoidance, text wrapping. Switch across screen sizes to crush layout breaks.
- Navigation and transitions: tab switching, back gestures, modal open/close. Whether your flow holds together is fully traceable here.
- In-app state: whether a value carries to the next screen, whether a list re-renders. Logic that stays inside the app is trustworthy.
- Light/dark appearance: palette and contrast, and text readability when the theme flips.
- Basic text input: focus movement and validation — though fine-grained Japanese IME conversion is safer to re-check on a device.
In short, appearance and logic that are self-contained inside the app are most efficient to finish in the simulator.
What the simulator can't judge — move it to a real device
This is the core. No matter how smoothly the following run in the live simulator, never call them "working" on that basis alone. Their true behavior only shows on a device.
- Push notifications: remote delivery assumes a real device. The simulator won't deliver them, or behaves differently — so run the full path on a device, from the permission dialog through receipt and post-tap navigation.
- The ATT (tracking) dialog: display timing and the allow/deny branches. Whether the advertising ID is available can only be verified correctly on a device.
- In-app purchases (subscriptions and one-time): purchase flow, restore, sandbox receipt validation. A purchase can't even complete in the simulator, so always verify billing on a device.
- Camera, photo library, microphone: features tied to real hardware and permissions. The simulator offers limited stock images and won't reproduce the permission-dialog experience.
- Haptics: vibration can only be felt on a device. Tune strength and timing with the phone in hand.
- Scroll "feel" and perceived performance: inertial smoothness, jank on image-heavy screens, slowdown from thermal throttling. None of this measures accurately over a stream.
- Biometrics (Face ID / Touch ID): success, failure, and fallback branches belong on a device.
- Deep links from other apps: launches via the share sheet or a URL scheme should be checked on a device, in combination with the other app.
What they share: every one touches device-specific hardware, an OS permission, or integration with an external service like billing or notifications. If a feature hits any of those three, treat the simulator pass as a draft and carry the final judgment to a device.
When to move from the browser to a device through Companion
So when do you move off the browser? The rule I use in solo development is dead simple. The moment a feature touches hardware, a permission, or billing/notifications, run that one feature on a device. Rather than batching all device testing until everything is built, checking each risky feature the instant you add it makes isolating the cause far easier.
With Rork, you can transfer to your own iPhone through the Companion app without even a paid Apple Developer account. Because that first "run it on a device" friction is low, frequent device checks fit the workflow well. I've written up the transfer steps in how to start device testing with Rork Companion. For the final pre-submission pass, going one step further and running it through beta-distributing your Rork app on TestFlight — close to the real delivery path — buys you extra peace of mind.
The minimum I always run on a device before submission
To close, here's the minimum set I always verify on a real device before submitting in my solo work. Even when the simulator looks fine, these get one pass each on the actual phone.
Notifications, from permission through receipt and post-tap navigation — one round trip. Purchases, buy and restore in the sandbox — one round trip. Camera and photo access, from a first-run deny through re-allow. And an image-heavy screen, scrolled for a real few-dozen seconds to feel the heat and the speed falloff in your hand. Just running these four noticeably lowers the odds of hitting a device-only defect after release.
The browser live simulator is a powerful base for raising your number of attempts. Use that speed — but move anything touching hardware, permissions, or billing onto a device. Holding that one line removes most of the late-stage stumbles. Start by taking the next feature you'll touch and sorting it, with the three criteria above, into "simulator is enough" or "needs a device."