Xcode Build, Run, and Debug Shortcuts
Compiling, launching, and debugging an app against the Simulator or a physical device is the core feedback loop of iOS and Mac development, and this cluster of shortcuts covers that entire cycle from initial build through pausing execution mid-run to inspect what's happening.
| Action | Windows | Mac | Description |
|---|---|---|---|
| Build and Run | — | Cmd+R | Compiles the project and launches it on the currently selected simulator or connected device, the single most-used command during active development. |
| Build (without running) | — | Cmd+B | Compiles the project to check for errors without launching it, faster than a full Build and Run when you just want to confirm the code compiles cleanly. |
| Stop running app | — | Cmd+. | Terminates the currently running app on the simulator or device and stops the debugger session attached to it. |
| Toggle breakpoint | — | Cmd+\\ | Drops a blue breakpoint marker on the current line that also registers in the Breakpoint Navigator sidebar for later enabling, disabling, or editing with conditions; Xcode's debugger is LLDB under the hood, so a paused breakpoint hands control straight to the LLDB console at the bottom of the window for direct expression evaluation. |
| Step Over | — | F6 | Advances LLDB past whatever the highlighted line does and stops again on the next line, without following the debugger down into any function that line happens to call — the everyday stepping command for tracing your own logic without getting lost in Foundation or UIKit internals. |
Build and Run (Cmd+R) is the single most-pressed key combination during active development, compiling the current scheme's target and immediately launching it on whichever Simulator or connected device is currently selected in the scheme dropdown — the fundamental 'let me see if this works' action repeated dozens of times per session.
Build without running (Cmd+B) serves a narrower, faster purpose: confirming the code compiles cleanly without the overhead of actually launching and initializing the app, useful when you're mid-refactor and just want quick confirmation that your changes haven't introduced compile errors before committing to a full run cycle.
Stop (Cmd+.) terminates a currently running app and detaches the debugger, necessary before making further code changes in many cases, since Xcode won't allow rebuilding over an app that's still actively running and attached.
Breakpoints (Cmd+\\ to toggle one on the current line) pause execution at that exact point the next time the debugger reaches it, opening up the full debugging toolchain — inspecting variable values in the sidebar, stepping through subsequent lines one at a time with Step Over (F6) to trace exactly how a piece of logic behaves rather than only seeing its eventual output or crash.
A practical note on the Simulator versus a physical device: Build and Run behaves identically in concept regardless of target, but a physical device requires code signing configuration (a valid development team and provisioning profile) to be set up correctly first, which is a common source of Build and Run failures for developers new to Xcode that have nothing to do with the code itself being broken.
Clean Build Folder (Cmd+Shift+K) clears out cached derived data for the current project, a more aggressive reset than a normal build that's worth reaching for when you're seeing stale-looking errors that don't match your actual code, or after a significant Swift Package Manager or dependency change that a regular incremental build sometimes fails to pick up correctly. It's slower than a normal build since everything recompiles from scratch, so it's a targeted troubleshooting step rather than a routine part of the run cycle.
Switching the active scheme or run destination — which Simulator device, or a specific physical device plugged in over USB — happens through the scheme selector in the toolbar rather than a dedicated keyboard shortcut, but it's worth understanding that this selection persists across Build and Run invocations until changed again, meaning a stray Cmd+R after switching contexts unintentionally can launch on a device you weren't expecting if you forgot you'd switched targets earlier in the session. Teams juggling several physical test devices for a client project often develop a habit of glancing at the scheme selector before every run specifically to avoid this.
A subtlety worth knowing for teams working across multiple Apple platforms in one workspace (an iOS app alongside a companion watchOS or macOS target, for instance): each target maintains its own scheme, and Build and Run always acts on whichever scheme is currently active, not necessarily the one you most recently edited code for. It's easy to make a change intending to test it on the iOS target, only to have accidentally left the watchOS scheme selected from earlier, producing a build that succeeds but launches the wrong app entirely — checking the scheme selector before a run becomes second nature quickly once this has happened once or twice.
For projects with slow build times, Xcode's build system caches intermediate results aggressively, which is why a Clean Build Folder feels noticeably slower than a normal incremental Build and Run — normal builds only recompile files that actually changed since the last build, while a clean build discards that cache entirely and starts from zero, which is exactly why it's reserved for troubleshooting rather than routine use.