A persistent remote Mac for interactive Xcode development
For developers who write and debug iOS or macOS apps but do not work on a Mac, or who need a second, always-on Mac. You connect to your own Mac mini, open Xcode, run the simulator and pick up where you left off the next day.
- 01
Your computer
Screen Sharing or SSH
- 02
Hosted Mac mini
Dedicated, admin access
- 03
Xcode
Edit, build, debug
- 04
Simulator
Run and preview
What this solves
Developers on Windows or Linux
Xcode only runs on macOS. A remote Mac gives Flutter, React Native and web teams a place to build and debug the iOS side.
One workspace that stays put
Your checkout, simulators, settings and caches persist. Nothing is reset between sessions.
No hardware to ship or manage
New team members or contractors get access to a Mac in the datacenter instead of a laptop in the post.
Example workflow
A Flutter developer on Windows ships an iOS fix
- 1
The developer connects to the Mac with Screen Sharing over a VPN or SSH tunnel.
- 2
The project is already checked out and the simulators are installed from previous sessions.
- 3
They run the app in the iOS Simulator, set breakpoints in Xcode and fix the issue.
- 4
Xcode signs a debug build with the team's Apple Developer account.
- 5
The fix is pushed to Git, where your CI pipeline takes over.
Ways to work on the Mac
Most developers combine a graphical session for Xcode with SSH for everything that runs in a terminal.
| Connection | Best for | You need |
|---|---|---|
| Screen Sharing (VNC) over an SSH tunnel or VPN | Best forXcode, Interface Builder, SwiftUI previews and the Simulator | You needA VNC client and an SSH key or VPN |
| SSH terminal | Best forgit, xcodebuild, fastlane and scripts | You needAny SSH client |
| Remote editor over SSH, for example VS Code Remote-SSH | Best forEditing code and running builds from your own editor | You needAn editor with SSH support; Xcode itself still needs Screen Sharing |
| JetKVM console (optional add-on) | Best forRecovery when macOS is not reachable over the network | You needA web browser |
How to set it up and run it
- 1
Choose a configuration and the macOS version that your target Xcode version requires.
- 2
Connect over SSH first, create user accounts and enable macOS Screen Sharing. Expose it only through a VPN or an SSH tunnel, not directly to the internet.
- 3
Install Xcode, sign in with your Apple ID in Xcode and add your team from the Apple Developer Program.
- 4
Install the simulator runtimes you need
Each runtime takes several gigabytes, so plan storage.
- 5
Add the optional JetKVM if you want a console that works even when macOS networking or Screen Sharing does not.
Which configuration fits
Good fit for
One developer running Xcode with a few simulators open.
Mac mini M6
- 12-core CPU · 12-core GPU
- Memory: 24 GB
- Storage: 512 GB SSD
Who does what
vBoxx provides
- A dedicated Mac mini with full admin access, reachable over SSH and Screen Sharing
- The macOS version you choose at order time, so it matches the Xcode release you need
- Persistent storage for your checkout, simulator runtimes and DerivedData
- Optional JetKVM console if Screen Sharing stops responding
- Support during EU business hours, emergency remote hands 24/7
You manage
- Xcode, SDKs and simulator runtimes
- Apple ID and Apple Developer Program membership
- User accounts, VPN and secure remote access
- Software licences for tools you install
- Your source code and backups beyond Git
Before you choose this setup
- This is interactive work over a network. Typing and scrolling feel responsive on a stable connection, but animations and video are not as smooth as a local Mac.
- Physical iPhones and iPads cannot be connected to the hosted Mac over USB. Test on devices locally or through a device cloud.
- For automated builds on every commit, use a separate build runner. See the CI/CD use case.