Claude Code Desktop adds a shared iOS Simulator pane

Who can use it—and where it stops

The pane is in public beta for Claude Code Desktop on macOS. It requires Claude Desktop version 1.24012.0 or later, a Mac, and Xcode with the iOS platform installed. Anthropic lists Pro, Max and Team plans as eligible and excludes Enterprise.

It also works only in local sessions. Cloud and SSH sessions run on machines that cannot reach simulators on the user’s Mac, according to the documentation. That makes this a feature for projects and Apple tooling available on the local machine, rather than a way for a remote Claude Code session to operate an iOS simulator elsewhere.

Once a session has a simulator attached or has edited Swift files, a developer can open the pane manually and attach a device. Claude can target a named simulated device during a build; a device it boots also appears in Apple’s Simulator app. Sessions do not share devices, and a session can have up to four panes. Those controls support parallel work, but they do not make results from one simulator a test of every iOS device configuration.

Consent separates device control from project execution

The first time Claude uses a particular simulated device, the desktop app asks for permission. That consent covers controlling the device and taking screenshots; after it is granted, Claude can tap, type, launch apps and take screenshots on that device without a prompt for each action. If permission is declined, the device and pane remain available for the developer’s own input.

Two related actions follow the session’s normal permission mode instead: opening a URL in the device, because a URL can carry data off it, and building an app, because xcodebuild can run a project’s build scripts on the Mac. The distinction matters because a visible simulator pane does not turn project execution into a risk-free preview.

The privacy boundary is also explicit. Anthropic says screenshots Claude takes of a simulated device are sent to Anthropic and kept under the account’s usual conversation-retention settings, and advises users not to sign in to real accounts on a device Claude uses. Independent coverage of the release relayed the same company warning.

Organizations can block Claude’s simulator tools with a managed setting while leaving the pane available for their employees’ own taps. A policy that requires sessions to run inside an isolated virtual machine disables both the pane and the tools.

The next test is usefulness, not access

The release makes the loop from an instruction to a visible simulated result more direct: Anthropic’s example is asking Claude to build an app and check an onboarding flow, then watching it install the app, tap through it and read the screen. A report on the beta described the same intended workflow.

What remains to be established is whether that shared visual loop reliably finds the problems developers care about. The current limits—local sessions, Xcode’s simulator tooling, simulated devices only, and screenshot retention—mean teams still need their usual decisions about hardware testing, test data and account access. The useful evidence will be whether developers can reproduce meaningful checks in the pane without exposing production credentials or mistaking simulator behavior for a device result.