My Xcode workflow has been slowing down development, especially when navigating files, debugging, and running builds. I’m looking for practical Xcode shortcuts, settings, or productivity tips that can help me code faster and work more efficiently.
Don’t make deleting DerivedData your routine fix for every slowdown. It forces Xcode to rebuild caches and re-index the project, so it can actually waste more time unless the build state is genuinely broken.
The shortcuts with the biggest day-to-day payoff are Shift-Command-O for Open Quickly, Command-Shift-F for project-wide search, Command-click or Control-Command-J to jump to a definition, Command-B to build, Command-R to run, and Command-U to run tests. Use Command-1 for the Project navigator and Command-0 to hide the navigator when you need more editor space. For debugging, Command-\ toggles a breakpoint, while F6, F7, and F8 step over, into, and out of code.
A less obvious improvement is setting up Xcode Behaviors so starting a run hides panels you do not need, while hitting a breakpoint automatically shows the debugger and variables. Keep the Issue navigator open after failed builds instead of scrolling through the full build log. It is worth learning Open Quickly first, though. Once you stop hunting through nested folders manually, Xcode feels much less sluggish even when its actual performance has not changed.
Command-U is often too blunt during active development because it can run the entire test plan. Run the single test or test class from the gutter, then use “Test Again” while iterating. Save the full suite for checkpoints or CI. That change usually saves more time than memorizing another dozen shortcuts.
Set up Xcode’s Behaviors so the UI changes automatically when you run, pause, or hit a build failure. For example, have Run hide the navigator and debugger, then have Pause show the debugger area. It removes a surprising amount of repetitive panel shuffling.
For navigation, Shift-Command-O is usually faster than hunting through the project tree. Type a few letters from a file, symbol, or method name and jump straight there. Command-clicking symbols and using Control-Command-J for definitions covers most of the remaining movement.
@mark_sql’s targeted-test advice is solid. I’d apply the same idea to builds: use Command-B when you only need compilation feedback instead of repeatedly launching the app. And don’t routinely clear Derived Data as a “speed fix.” It can solve stale build problems, but doing it casually throws away caches and makes the next build slower.
Measure the delay before you start rearranging Xcode. If builds are the real problem, use Product > Perform Action > Build With Timing Summary and inspect what is consuming the time. Custom Run Script phases are frequent offenders. A script without declared input and output files may run on every incremental build and can block other work, so fixing that often matters more than another keyboard shortcut.
Check the active scheme too. The Build action may include extensions, tools, test bundles, or framework targets you do not need for normal app development. A smaller development scheme can build only the relevant targets, while an umbrella scheme handles full tests and release checks. That applies the same targeted approach @neonninja4117 mentioned for tests, but earlier in the build pipeline. Keep the scheme’s build order set to Dependency Order so independent targets can compile in parallel.
For debugging, conditional breakpoints and breakpoint actions save more time than stepping through the same loop repeatedly. Add a condition such as item.id == failingID, or configure the breakpoint to print a value and continue automatically. That gives you lightweight logging without editing the source, rebuilding, reproducing the bug, and later removing temporary print calls. An exception breakpoint is worth keeping disabled in the Breakpoint navigator so you can enable it quickly when a crash does not stop somewhere useful.
The shortcuts already listed cover movement well. The other habit I would prioritize is separating compile, launch, and test feedback. Build when checking compiler errors, run only when behavior needs verification, and test the narrowest relevant target during iteration. If Xcode itself is hanging rather than the build being slow, then inspect indexing, package resolution, and source-control activity before reaching for Derived Data. Clearing caches should be recovery work, not maintenance.
Open Quick Actions with Shift-Command-A and type the command you want instead of digging through menus or trying to memorize every shortcut at once. For a beginner, that is much easier than keeping a cheat sheet nearby. Search for things like “show console,” “format,” “rename,” or “reveal in navigator.” Once you notice yourself using the same command repeatedly, assign or learn its shortcut in Xcode’s Key Bindings settings.
The navigation history cleared up another confusing part for me. Shift-Command-O is great when you know where you want to go, as @mark_sql said, but sometimes you only want to return to the code you were just reading. Control-Command-Left Arrow goes back through previous locations, and Control-Command-Right Arrow goes forward. That keeps you from reopening files and losing your place after following several definitions. Option-clicking a symbol for Quick Help is useful too, especially when you only need its type or documentation and do not want to leave the current file.
For repetitive code, create a snippet instead of copying an old implementation and cleaning it up every time. Select the code, Control-click, and choose Create Code Snippet. You can give it a completion shortcut and add placeholders, then move through those placeholders with Tab. This works well for test setup, decoding boilerplate, common SwiftUI view structures, or whatever pattern your project repeats. Keep snippets small, though. Large copied templates can hide outdated assumptions and become their own maintenance problem.
I would learn Xcode’s rename tools before relying heavily on project-wide text replacement. Command-Control-E edits matching names in the current scope, while Refactor > Rename handles symbols across the project and gives you a preview. Plain search-and-replace can accidentally change strings, comments, or unrelated names. That distinction was not obvious to me at first, and using the proper refactor command saves both typing and cleanup.
Nobody’s mentioned that if you’re on SwiftUI, the preview canvas is often the real thing dragging you down. It recompiles constantly in the background, and on a big view hierarchy it can spike your CPU and make the whole editor feel laggy even when your actual builds are fine. I keep it closed (Option-Command-Return toggles it) until I actually need to check layout, then shut it again. That alone did more for responsiveness than any shortcut I picked up.
The Behaviors advice from @zerobot5559 and @mark_sql is genuinely good, but I’d add a small warning: it’s easy to over-configure and then get confused when panels vanish ‘on their own.’ Set up two or three behaviors, live with them for a week, then add more. Otherwise you spend time fighting the automation you just built.
One more thing people forget is tab behavior. Check the Navigation settings so single-clicking a file doesn’t keep hijacking your current editor tab. Setting clicks to open in the same tab but double-clicks in a new one saved me from constantly losing my place while chasing definitions.
Don’t force Open Quickly into every navigation job. Shift-Command-O wins when switching files, but Control-6 is faster inside a long source file because it lists that file’s methods and symbols, and you can type to filter them.
For source-and-test work, a split editor can beat bouncing through navigation history. Keep the implementation on one side and its test on the other, then close the split when screen space matters more.
Half the shortcuts in this thread are useless until they’re muscle memory, and you don’t build that by reading a list. Pick two, force yourself to use them for a week, then add more. @redwizard already made this point about Behaviors and it applies to everything else here too.
The thing nobody’s hit directly: indexing is what wrecks my day, not builds. Switch branches, resolve packages, and Xcode quietly re-indexes while you’re trying to work, which makes jump-to-definition and Open Quickly feel broken even though nothing is actually wrong. If your navigation suddenly goes sluggish, check whether it’s still indexing before you touch DerivedData or blame your shortcuts. Usually you just wait it out.
A hidden slowdown is leaving expensive scheme diagnostics enabled after chasing a bug. Open Edit Scheme > Run > Diagnostics and turn off Address Sanitizer, Thread Sanitizer, or other checks unless you currently need them. They are useful, but they can make launching and running feel much slower.