An iPhone inside Claude

What it is and why it matters

When Claude changes a screen in your iOS app, it usually tells you “done”. Then it's on you: build, open the simulator, get to that screen and look. And if it's wrong, you explain it again in words.

The Claude desktop app for Mac has the iOS Simulator pane: a simulated iPhone next to the chat. Claude builds the app, installs it, opens it, taps the buttons and reads the screen to check its own change. You watch live, and you can tap too.

The second half of the guide is the trick we use at STRIKT for posts and for the App Store: demo screens that open already full with a launch parameter, so every screenshot is real and comes from the latest commit. The pane is in public beta, only in the desktop app for macOS, on the Pro, Max, Team and Enterprise plans (except Enterprise organizations with the HIPAA configuration).

1. What you need

• A Mac: Apple's simulator only runs on macOS.
• Xcode with the iOS platform, which brings the simulators. If they're missing, download them from Xcode's settings or with xcodebuild -downloadPlatform iOS.
• The latest version of the Claude desktop app: Claude > Check for Updates…
• A local session: in cloud or SSH sessions Claude runs on a machine that can't see your Mac's simulators.
• A project that builds for the iOS simulator. Any project that does will work.

2. Start it and have it check its own work

1. In the desktop app, open the Code tab and start a session in the project folder.
2. Ask it to run or test the app. The pane opens by itself as soon as the app launches; you can also open it yourself with the iOS Simulator button in the title bar and then Attach simulator.
3. The first time, the app asks whether Claude may use that simulator. The consent covers controlling it and taking screenshots, once per device. Building the app and opening a link on the device follow the session's permission mode instead, because the build runs the project's scripts on your Mac.

The point isn't seeing the app: it's having Claude check its change instead of telling you “done” on trust. Put it in the request:

Move the “Save” button to the bottom of the profile screen. Then build, run the app in the simulator, open the profile, change the name and tap “Save”. Close and reopen the app and check that the name is still there. Send me the before and after screenshots, and tell me if anything looks off.

Want a specific device? Say so: “run it on the iPhone SE simulator”. It's how you see whether a text wraps badly on a small screen.

3. Tap along with it

• You tap and swipe by clicking and dragging on the pane's screen.
• Cmd+Shift+H for Home, Cmd+L to lock, Cmd+Right Arrow to rotate.
• Cmd+S saves a screenshot and Cmd+R a screen recording, to your Desktop.
• When the label Claude is using this device sits above the screen, don't tap: it's the same device, and your taps change what Claude sees.

Each session has its own simulators, up to 4. The ones Claude boots shut down by themselves when you quit the app, when you archive the session, or 10 minutes after you detach them from the pane.

4. The trick: demo screens that start full

For a post or the App Store you need the screen at its best moment: the full leaderboard, the completed day. Getting there by hand means test accounts, network, sometimes the camera, and lots of taps. So you end up with old or redrawn screenshots that aren't the real app anymore.

Here's what we do: the app has demo views that open with a launch argument, meaning a word you pass to the app when it starts, or with an environment variable. They start already full of realistic data written in the code, with no account, network or camera. They're the real screens, with the same components: only the data changes.

• One demo view for each screen you need, with a clear name.
• Fake but believable data: numbers the app could really show, no data from real people. When the demo's names and numbers show up in a post, we say it's an example.
• All the demo code inside #if DEBUG, so it doesn't end up in the app you ship.
• The language is set at launch with -AppleLanguages "(it)" -AppleLocale it_IT: the same screens, in every language.

You don't have to write the demo views yourself. Ask Claude:

Add demo views for screenshots to my app. If the app launches with the argument -DemoScreen followed by a name (for example today, stats, profile), it skips login and onboarding and opens that screen directly, already full of realistic data written in the code: no network, account, camera or permission prompts. Use the same components as the real screens, only the data changes. Put everything inside #if DEBUG. At the end, write in the README the list of views and the command to open them in the simulator.

5. Screenshots from the latest commit

With demo views, a screenshot becomes a command. Claude uses xcrun simctl, the Xcode tool that controls simulators from the terminal:

1. Update and build the latest version for the simulator, and note the commit with git log -1 --oneline: that way you know where each image comes from.
2. Use a simulator just for screenshots, not one booted by another session: xcrun simctl create with a name and the iPhone model, then xcrun simctl boot.
3. A clean status bar: xcrun simctl status_bar <device> override --time 9:41 --batteryState charged --batteryLevel 100 --cellularBars 4 --wifiBars 3.
4. Install: xcrun simctl install <device> <path to the .app file>.
5. Open the view: xcrun simctl launch --terminate-running-process <device> <bundle id> -DemoScreen today. Environment variables reach the app if you put them before the command with the SIMCTL_CHILD_ prefix.
6. Shoot: xcrun simctl io <device> screenshot today.png. Then look at the image: it has to show exactly what the post's text says.

Make me the 6 App Store screenshots from the latest commit. Update the repository, note the commit, build for the simulator and create a new simulator just for this, of a model whose size App Store Connect accepts. Status bar at 9:41 with full battery and signal. Then open the demo views today, stats, workout, friends, profile and settings one at a time with -DemoScreen and save a PNG for each in screenshots/, with the commit in the name. Check that the PNGs have no transparency, look at every image and tell me if anything is empty, cut off or in the wrong language.

For the App Store you can upload up to 10 screenshots per display size, in PNG or JPEG, with no transparency. The pixel sizes change with the type of iPhone: check them on App Store Connect's Screenshot specifications page before you pick the simulator. For social media we put the screenshot inside a whole iPhone with the real proportions; when the code changes, you just run the same request again.

Common mistakes

• Asking “fix the screen” without asking for a check in the simulator. Always ask: relaunch, get there, send me the screenshot.
• Signing in to real accounts in the simulator. The screenshots Claude takes of the device are sent to Anthropic and kept with the conversation: use fake data only.
• Leaving the demo code outside #if DEBUG: it ends up in the published app.
• Taking the screenshots on a simulator another session is already using: the app's state isn't what you think.
• Expecting Claude to use your real iPhone: it only controls simulated devices. For the real phone, you run the app from Xcode and send it a screenshot.

Checklist

• Xcode with the iOS platform and at least one simulator
• Claude desktop app up to date, local session in the Code tab
• Demo views inside #if DEBUG, one per screen
• Status bar at 9:41 before the screenshots
• Commit noted next to the images
• Every screenshot looked at before using it

Frequently asked questions