Running the iOS Simulator is one command, and Apple says it does not replicate a real device.

What do you actually type to run it?

Four setup steps, then one command. Install Xcode from the Mac App Store. Open Xcode Settings, go to Locations, and choose the newest version in the Command Line Tools dropdown, which is the step people skip and then spend an afternoon on. Install an iOS runtime under Settings, Components, Platform Support, iOS, where there is a Get button. Then, in the project folder, run npx expo start and press the i key. Press Shift and I instead if you want to pick which simulated device opens. Watchman, which older guides treat as mandatory, is only needed for projects on Expo SDK 55 and earlier.

Two things go wrong at this point, and both have printed answers. The command sometimes sits there and never opens anything. Boot a device yourself with xcrun simctl list devices available to see the names, then xcrun simctl boot with one of them, then start the app again. And the app installs but does not launch, because iOS is waiting to ask you whether to open it. Click around inside the simulated screen until the prompt appears, then accept it. You can have several simulated devices running at once, and the Expo CLI always targets the one you opened most recently, which is a good thing to know before you spend ten minutes wondering why your change is not showing up.

The window itself has a new name. Apple's current documentation says simulators run within Device Hub on your Mac, and Expo states that Xcode 27 replaces the Simulator app with Device Hub, so you open it by hand with open -a DeviceHub, while on Xcode 26 the command is still open -a Simulator. Menu items moved with the rename, so the instruction you find in an old answer may be correct and still unfindable. Resetting a device is Reset Content and Settings in Xcode 27 and Erase All Content and Settings in Xcode 26. Xcode 27 needs a Mac running macOS Tahoe 26.6 or later, so this step can turn into an operating system upgrade.

One thing it does not need: an Apple account. Apple's instructions for signing in, choosing a team and creating a provisioning profile sit under a heading about physical devices, and begin with the words if you choose a physical device as the run destination. A simulated device skips all of it. Expo's build reference makes the same point from the other side, describing a simulator build as a standalone version of the app that runs without needing to deploy to TestFlight or even having an Apple Developer account. The Simulator belongs to Xcode rather than to your framework, which is why a comparison of Flutter against React Native has almost nothing to say about this step. Both of them end up in the same Apple window.

Expo, iOS Simulator, last updated 16 October 2026, read 17 October 2026

What can the Simulator not do that a real iPhone can?

Start with what Apple itself commits to, because it is narrower than the lists you will find. Its page on running your app says to be aware that simulators do not replicate the performance or features of a physical device, and that to verify your app runs exactly as intended you should run it on one or more physical devices. Its only marked warning says that some hardware-specific features might not be available, that the frameworks giving access to device-specific features also provide an API to tell you when those features are available, and that you should call those APIs and handle the case where a feature is not available. To test the feature itself, run your code on a physical device.

Notice what is not there. Apple does not print the list. We read that page and the four Device Hub pages it links to on 17 October 2026 and found no enumeration of missing hardware, only the instruction to ask the framework at runtime. The familiar list belongs to Expo, on its own iOS Simulator page, and it is short: audio input, barometer, camera, and motion support, meaning the accelerometer and the gyroscope. Expo adds one more line that matters more than the hardware, that the Simulator suspends background apps and processes on iOS 11 and later. If your app syncs, uploads, finishes a download or tracks anything while the user is elsewhere, that behaviour is not being exercised here at all.

Then there are the gaps Apple does print, in the Xcode 27 release notes rather than in the guide. Under Device Hub, known issues, read on 17 October 2026: Device Hub does not currently support sending a two-finger touch to a device or simulator. Connecting a game controller is only supported for the visionOS simulator. Sound output and input for simulators cannot be set to None. And the Controls menu Shake item does not work, which is worth sitting with, because the same release of the documentation tells you to choose Controls and then Shake in order to shake the device. If your app has a pinch of its own rather than one inherited from a standard component, that is a gesture you cannot send it on your Mac. Apple also says the mouse and trackpad behaviour it added for convenience does not reflect functionality available on physical devices.

The practical reading for a project you did not write is this. Open the code and find every place it asks the device for something: the camera, the microphone, the step count, a location in the background, a biometric prompt, a haptic. Each one is a screen you have not seen yet. The cheap fix is to make sure the generated code handles the unavailable case the way Apple asks, because that branch is the one your Mac will take every single time, and the one a reviewer on a real phone never will.

Apple, running your app on simulated or physical devices, read 17 October 2026

Can you test a purchase or a push notification here?

Pushes first, because the received wisdom is simply out of date. Apple's Xcode 14 release notes say that Simulator supports remote notifications in iOS 16 when running in macOS 13 on Mac computers with Apple silicon or T2 processors, and that it supports the Apple Push Notification service sandbox environment, so your own server can send to the app running there. The same note carries the catch: each simulator generates registration tokens unique to the combination of that simulator and the Mac hardware it is running on. A token you grab from your Mac is not a device token. Expo's push notification setup page, modified on 28 July 2026, lists the same conditions as a supported way to test. So the notification arriving is real evidence. The token is not.

Purchases are the one worth being careful about, because Apple has two test environments and only one of them lives here. StoreKit Testing in Xcode is local. Apple describes it as a test environment for in-app purchases without requiring a connection to App Store servers, with products you define in a configuration file in the project, and its page on testing at all stages of development says you can test your app in Simulator or on real devices. Its comparison table is honest about the trade: no App Store Connect setup needed, and the receipts and transactions are signed by Xcode rather than by the App Store.

The sandbox is the other one, and it is where the real product information lives. Apple requires an active Apple Developer Program account, a signed Paid Applications Agreement, products configured in App Store Connect and a Sandbox Apple Account. Every step it documents happens on a device: you sign in to the Sandbox Apple Account there, the controls appear under Developer in Settings after your first attempted purchase, and Developer Mode has to be on. Read on 17 October 2026, the word Simulator does not appear once on Apple's sandbox testing page. That is an absence rather than a prohibition, and the honest statement is the careful one: Apple does not say a simulated device cannot take a sandbox purchase, it just never describes one doing so. TestFlight uses the sandbox, so the first genuinely end to end purchase in your app will happen on somebody's phone.

The thing to take away is the order of operations. Build the paywall against local products, where you can force failures and replay the flow as often as you like, and treat a green run as proof that your code handles a transaction. Then budget for the device pass, because the account, the agreement and the uploaded build are the prerequisites for it, and they are the part of what it costs to publish an app that people meet last and plan for least.

What is a simulator better at than a phone?

Store images, and it is not a close contest. Apple's page on capturing screenshots and videos from devices lists preparing and updating your App Store page among the reasons to capture, and says the screenshot is taken at the full resolution of the simulated or physical device regardless of the display resolution of your Mac, then saved to your Desktop folder. Video recording is documented for simulated devices, with the file name beginning Screen Recording. The only size warning Apple prints is for visionOS, where captures can differ in size and ratio from a physical device and may need cropping. So the screenshots your listing needs for hardware you do not own come from a window on your Mac, for nothing.

Second, devices you will never hold. You add a simulated device with a specific model and operating system version from the sidebar, and Apple's stated reason for simulators is to let you debug on a variety of hardware you might not have access to. There is also a resize mode that lets you drag a simulated iPhone screen to an arbitrary size, snapping to the nearest valid one, which finds layout that only works at the width you happened to develop on. Appearance, Liquid Glass and text size are switches in an inspector rather than a trip through Settings on a handset, and a Slow Animations menu item exists for exactly the layout and performance problems that go by too fast to see.

Third, and most undervalued: the first run. Resetting a simulated device, which Expo describes as reinitialising it from a blank image, gives you back the state every one of your users starts in and that you personally cannot return to once you have opened your own app once. Empty lists. Permission prompts not yet answered. Onboarding you wrote three weeks ago and have not seen since. A generated project tends to be strongest on the happy path and weakest exactly here, so a reset and a cold launch is the highest value ten minutes available to you.

It is worth knowing that this surface moves. The window changed its name between Xcode 26 and Xcode 27, the reset menu item changed its wording, pairing a phone over the network now wants iOS 27, and the newest Xcode wants a newer macOS. None of that is your code breaking, and all of it is time, which is the quiet half of what an app costs to maintain once it is live.