Stateful iOS CI
After each iOS commit, boot virtual iPhones from a range of preserved device states to catch upgrade failures early and retain a debuggable failure environment.
When an iOS team is ready to merge code, the biggest risk is that a new version fails on an older OS, with little free storage, or under a particular language setting. These issues often surface only on release night, while simulators at a developer’s desk rarely preserve the state of a device that has just been upgraded.
The team defines critical states as version-controlled test fixtures: an upgrade from an older app version, accumulated notifications, low disk space, or a changed system language. After each commit, the service starts a disposable virtual iPhone for every fixture, boots it into the corresponding state, installs the new build, and runs through login, upgrade, notifications, and core screens.
If a step fails, the review page provides an interaction recording, before-and-after snapshot differences, console output, and a virtual device that remains available for debugging. A developer can stop one second before the failure, inspect the files, system settings, and app UI at that moment, then rerun the fixed build from the same state.
The first release covers the three most common upgrade states and in-app paths, excluding personal Apple IDs, real photos, and live push content. It brings the hardest-to-preserve user environments into every code review before release.
Why now
vphone-cli reached Hacker News on August 28, 2026; when observed on August 30, it ranked No. 1 with 378 points and 101 comments. S1 Its cloneable, importable, and exportable virtual iPhones make it easier for teams to experiment with bringing upgrade state into CI now. S2
Target user
Small and mid-sized teams that already run iOS automation but still preserve older devices manually. The critical moment is before merging changes involving database migrations, cache formats, or system permissions. Fresh-install tests cannot cover legacy state from an older version, and physical devices are difficult to restore quickly. The on-call developer needs to see the failure environment in the pull request rather than scramble to reproduce it on release night.
Minimal entry point
Start with a GitHub App as the control plane, receiving commits and build artifacts. Limit execution to customer-owned Apple Silicon Macs. It uses vphone-cli commands to create, clone, boot, import, and export virtual machines. S2 Each fixture stores a VM bundle, app version, and state description. Initially, install apps and inject state through controlled scripts over SSH; VNC can provide visual access. The first release serves only teams with test builds, test accounts, and script entry points. Validate three paths first: upgrading old app data, switching languages, and changing free disk space. The review page aggregates only recordings, logs, snapshot differences, and a reconnect address.
Punching above its weight
The first users are in vphone-cli GitHub discussions, Hacker News comments, and engineering teams that maintain iOS CI. Open-source a self-hosted runner and three sample fixtures, then charge for the review page, access controls, and concurrent scheduling. Provide a GitHub Actions template so a team can launch a trial from its existing repository with a single commit. Failure recordings and state diffs fit naturally into pull requests and can reach other developers on the team.
Competitors & gaps
- CorelliumGoogle
- Corellium already offers on-demand virtual iOS devices across device and OS combinations, with snapshots, cloning, restoration, APIs for test-tool integration, and filesystem and console access. S3 Those capabilities cover the underlying virtualization and deep debugging, so rebuilding them offers little advantage. Its public materials focus more on mobile security, forensics, and penetration testing. They do not emphasize storing pre-upgrade user states as repository-managed fixtures or automatically rerunning upgrade paths on every commit. The opening is a narrower development workflow: fixtures travel with code review, and failures return directly to the state just before the fault. The product must reduce state preparation, build upload, and review-report generation to a single CI call. Otherwise, teams can build a similar workflow directly on the Corellium API.
- BrowserStack App AutomateGoogle
- BrowserStack App Automate already accepts iOS builds and test packages, supports Appium, Maestro, and XCUITest in CI, and returns logs, screenshots, recordings, and other debugging artifacts. S4 Its strengths are real-device coverage and a mature automation ecosystem for regression testing across device models and OS versions. Custom Device Lab also offers persistent configurations for more specialized real-device scenarios. Its public interfaces focus mainly on organizing device configurations, builds, and test sessions. It does not emphasize versioning a complete pre-upgrade user state and cloning it for every commit. The opportunity is state fixtures for old app data, accumulated notifications, and storage limits. If those states can only be assembled temporarily through test scripts, the difference quickly narrows.
How it makes money
Subscription priced by concurrent virtual devices, with additional charges for runtime and state storage. Early on, offer a team plan that runs only on customer-owned Macs, avoiding the cost of hosting hardware.
The case against
vphone-cli currently requires Apple Silicon, macOS 15+, relaxed SIP/AMFI protections, and private entitlements. S2 That makes execution nodes high-privilege infrastructure that is harder to isolate, update, and audit. The VMs also depend on patched firmware, so system upgrades could immediately break fixture compatibility. Low storage, notifications, and background scheduling may not faithfully match physical-device behavior. Credential strings, push tokens, and server-side accounts can also make state reruns unreliable. Cloning, storing, and starting large VMs concurrently will raise costs. Unless failures can be reproduced reliably in a controlled Mac cluster, the service will remain limited to a small set of research-oriented teams.