How to run app simulator xcode mac: step by step for Xcode 26 and Xcode 27

The Simulator lets you run an iPhone, iPad, Apple Watch or Apple TV app on your Mac, so you can test it without the hardware in front of you. The core routine is short. Pick a scheme, pick a simulated device, click Run. The part that changes between Xcode versions is what opens after the build finishes, and that is where most confusion starts.

What you need before you start

Check your macOS version first, because it decides which Xcode you can install. Xcode 27 requires macOS Tahoe 26.6 or later, according to Apple's Xcode support page. It installs only on Apple silicon Macs, so an Intel Mac cannot run it.

Xcode 26 has an older floor. It requires macOS Sequoia 15.6 through macOS Tahoe 26.x. If your Mac cannot reach Tahoe 26.6, Xcode 26 may be the version you can actually run. The steps below still apply to it, with one difference that the later sections explain.

• Xcode 27: an Apple silicon Mac running macOS Tahoe 26.6 or later.
• Xcode 26: a Mac running macOS Sequoia 15.6 through macOS Tahoe 26.x.
• An Xcode project that builds on your Mac without errors.
• Enough free disk space for the simulated devices and runtimes you plan to use.

Xcode is a Mac app. Apple's help pages do not describe a web version, so you need Xcode installed on the Mac you are working on. Confirm that the project opens and builds before you aim for the Simulator. A build error stops Run before any simulator opens, so that error is the first thing to fix.

Which Xcode version are you on?

Open Xcode and check Xcode > About Xcode. The version number appears in the window that opens. Xcode 27 became generally available on September 14, 2026. The newest stable build in my sources is 27.2, released October 29, 2026. A 27.3 beta followed on November 3, 2026.

Use the stable release for daily work. Beta builds change often, and a beta can move features around, including the Simulator window. If you test on a beta, expect the steps in this guide to differ in small ways.

Step by step: run an app in the Simulator on Xcode 27

These steps follow Apple's help page for running an app on a simulated device. That page does not list a menu path or a keyboard shortcut for Run, so the steps name the toolbar controls first and add the menu path as a backup. The same steps work on Xcode 26, but the window that opens at the end is different.

Keyboard shortcuts for Run and Stop

If you prefer the keyboard, Command-R runs the selected scheme on the selected device. Command-period stops the run. Both live in the Product menu, so open Product in the menu bar if a key does nothing. These shortcuts come from Xcode's standard menus, not from Apple's simulator help page, so check the Product menu on your own copy of Xcode.

A worked example: a to-do app on iPhone 17 and iPad

Say you built a to-do app with one scheme called TodoApp. You want to see how the layout looks on a phone and on a tablet. Open the scheme pop-up menu and choose TodoApp. Then choose iPhone 17 under the iOS Simulators heading and click Run.

When the phone version runs, open the device pop-up again and choose an iPad from the same heading. Click Run. Xcode builds again for the new device, and the app launches on the iPad. Compare the two screens side by side, then switch devices once more if you need a third size.

Two destinations mean two runs. Keep the same scheme and change only the device. That way any difference you see comes from the device, not from a different build setting. If the iPad screen looks wrong, check the layout code before you blame the simulator.

Xcode 27: Device Hub replaces the Simulator app

On Xcode 27 the standalone Simulator app is gone. Apple says you manage every device that appears in Xcode as a run destination using Device Hub. Each simulated device opens as a detail view, and you select it from a source list.

Apple's Xcode page says Device Hub lets you test an app on physical devices and simulators. It also offers dynamic resizing and adjustable appearance. Those two features help when you want to check several window sizes in one place.

To open Device Hub without starting from Xcode, run open -a DeviceHub in Terminal. Expo's developer documentation gives that command for Xcode 27. On Xcode 26, the matching command is open -a Simulator.

Xcode 26 and the separate Simulator app

On Xcode 26, Run opens the Simulator as its own app after the build succeeds. You may need to switch to it from the Dock if it opens behind your editor. The Device menu holds the reset option. Expo's docs say Erase All Content and Settings sits there, and they suggest that step when reinstalling Expo Go fails.

Erasing content resets the simulated device. Anything you stored on that device goes away, including test accounts and saved data. Use it on purpose, not as a first guess. On Xcode 27, the same reset is in the Device menu inside Device Hub.

When the simulator list is empty or won't start

Sometimes Run builds without trouble, but no device appears. Start in Terminal, because it shows what Xcode can see. Run xcrun simctl list devices available. The output lists each installed simulator by name.

If the command line seems stuck, boot one device by its exact name. For example, xcrun simctl boot 'iPhone 17' starts that simulator. Then go back to Xcode and click Run. The name must match the list, including capital letters and spaces.

• xcrun simctl list devices available: lists the simulators Xcode can use.
• xcrun simctl boot 'iPhone 17': starts one simulator by name.
• open -a Simulator: opens the Simulator app on Xcode 26.
• open -a DeviceHub: opens Device Hub on Xcode 27.

Build errors before the simulator opens

If Run fails, the Simulator never launches. Read the first red error in the issue navigator, not the last one. The first error often causes the rest. Fix it, then click Run again.

A common cause is a scheme that points at the wrong target. Another is a device family your project does not support. Check the deployment settings for your target before you rerun the build.

Known gaps in Device Hub

Device Hub was still in beta when developers wrote about it in June 2026. Commenters on Michael Tsai's blog listed features that were missing at that time. Read that list before you plan a long test session.

• No Debug menu, so no slow animations and no memory-warning simulation.
• No pixel-accurate zoom and no pinch-to-zoom gestures.
• CarPlay simulator support was removed.
• Drag-and-drop file transfer is gone, and so is the copy-screenshot menu item.
• Command-W does not close the Device Hub window.

Some of these may have changed since the June beta. My sources could not load the body text of Apple's Xcode 27 release notes, so I could not confirm the current list. Check Apple's release notes yourself before you rely on a missing feature.

Physical devices and the Run button

Device Hub also manages physical devices as run destinations. A connected iPhone appears beside the simulators, so the Run button works the same way for it. A physical device needs its own setup, such as trust and signing. My sources do not cover that setup, so treat it as a separate task.

Common mistakes that waste time

• Running the wrong scheme. The build succeeds, but it is not the app you meant to test.
• Picking a device the project does not support. Check the device list before you assume a bug.
• Looking for the Simulator app on Xcode 27. The window lives in Device Hub.
• Following Xcode 26 screenshots on Xcode 27. Window names and menus have changed.
• Clicking Run with the wrong device selected. Read the toolbar before each run.

Most of these take ten seconds to avoid. Read the scheme and the device in the toolbar, then click Run. Repeat that habit each time you change either one.

What to do after the app launches

A launched app is only the start. Use it the way a person would. Tap every screen, rotate the device if your app supports rotation, and try the edge cases first. Empty lists, long names and failed network calls show problems faster than the normal path does.

Keep a short test list. Write down the device, the Xcode version, and the action that failed. That list saves time when you return to a bug after a day away. It also helps when you report the problem to a teammate.