Xcode Tips for the Savvy iOS Developer

Nathan Hillyer

Last updated Jul 23, 2019

For those of us developers working on platforms like iOS, Xcode permeates our day-to-day duties. If we're not coding or debugging in Xcode, we're usually still using it to run a test app on one of our devices. Xcode isn't all about coding. In the three years I've used Xcode, I've tackled a surprising variety of activities, from viewing source control diffs to measuring how well an app is performing. After spending countless hours in the tool and reading up on tutorials from other iOS developers in the community, I decided to pay it forward with my own list of my favorite Xcode hacks I use on a daily basis. I also polled the rest of Savvy's developer team to make this list as comprehensive as possible to save you time, up your accuracy, and make you a more proficient and productive developer.

Find Your Files with Xcode's Open Quickly Shortcut

The Open Quickly shortcut should be mandatory to memorize before starting in Xcode. Mac OS X has a feature called Spotlight Search (⌘ Spacebar) to help you find files and apps (among other things). Open Quickly is the Spotlight Search for Xcode.

I use the Open Quickly shortcut the most because it’s the easiest way to open a file as long as you know its name or the name of a method/public variable in the file. The nice thing about Open Quickly is its use of fuzzy matching logic. For example, if I know that the file has something to do with profiles, I can type in “profile” and it will show me any file with the word “profile” in its name. Click here to see Open Quickly in action.

Protip: Searching for a method or property with Open Quickly can be slow because it has to do a project-wide index and search. And this gets worse as your project gets bigger, so instead of searching for a method or property with Open Quickly, try this:

  1. Use ⌘ ⇧ O to search for the file and open it
  2. Use the ⌃ 6 shortcut to open up a jump menu
  3. Start typing in the name and hit enter when you’ve found it

This is much faster because it only has to index the public symbols in a single file instead of the entire project.

Shortcut: ⌘ ⇧ O

Code Faster with Xcode Shortcuts and Code Snippets

We unscientifically (using the stopwatch on an iPhone) measured the time it takes to do five common Xcode duties with the mouse, and estimated that about 5 percent of my coding is spent navigating Xcode. The measurements showed that the keyboard shortcuts were 1.5 to 3 times faster depending on the run. Based on this and the conservative assumption of a 10,000-hour career, you could save approximately 250* *hours of your time by using Xcode shortcuts.

There's also a qualitative value to learning shortcuts. The more shortcuts you learn, the more time you'll notice your fingers resting on the keyboard. This helps you keep focused on your train of thought. Try it now! Start concentrating on typing a paragraph, select and delete a word with your mouse, and then continue typing. Notice how the flow was broken? When you’re balancing a complex programming problem in your head, you’re in a very fragile state and the slightest interruption in flow can set you back.

Click here to get the full version of the Xcode Keyboard Shortcuts Cheat Sheet.

For those of you who want a more exhaustive list of the UI Navigation shortcuts available in Xcode, refer to the following screenshot of the Xcode interface. The shortcuts will refer to these different parts in the Xcode window. I've marked the screen regions as follows: Navigator (blue), Editor (red), Debug (green), Utility (yellow), Toolbar (purple).

  • ⌘ 0: Show/hide Navigator region
  • ⌘ 1 through ⌘ n: Switch Navigator tabs
  • ⌘ ⌥ J: Filter Navigator results
  • ⌘ ⇧ Y: Show/hide Debug region
  • ⌘ ⌥ 0: Show/hide Utility region
  • ⌘ ⌥ 1 through ⌘ ⌥ n: Switch Utility tabs
  • ⌃ 6: Jump menu for methods
  • ⌃ 1: Magic Menu
  • ⌃ ⌘ Up and ⌃ ⌘ Down: File counterpart navigation
  • ⌃ ⌘ E: Rename symbol within scope (Note: No support for properties)
  • ⌃ ⌘ Left and ⌃ ⌘ Right: Navigate file history
  • ⌃ ⌘ J: View source of symbol
  • ⌥ Selection: Vertical selection
  • ⌘ ↵: Show/hide Assistant Editor (as mentioned above)
  • ⌥ as modifier: Execute shortcut in Assistant Editor (as mentioned above)
  • ⌘ ⇧ ] and ⌘ ⇧ [: Move to next/previous tab
  • ⌘ ⌥ ] and ⌘ ⌥ [: Move line up / down
  • ⌘ R: Run app
  • ⌘ B: Build app
  • ⌃ .: Stop app while running
  • ⌃ i: Format code (code needs to be highlighted)

Xcode's code snippets are another way to speed up your programming. I use code snippets to assign a code name to a small chunk of code that I type repeatedly. By then typing out the (very much shorter) code name, I can add the corresponding chunk of code to what I'm working on with little effort. It can be the most productivity increasing feature of Xcode depending on the type of code in which I'm working.

Check out these GitHub links to get started on your own code snippet collection:

  • https://github.com/Xcode-Snippets/Objective-C
  • https://github.com/burczyk/XcodeSwiftSnippets

Develop with Context Using Xcode's Assistant Editor

The Assistant Editor is easily the most useful tool in Xcode. I lived without it for a few months until I found this magic little button that opened the next file I planned on editing. It isn't always 100% accurate, but the menu system design is super intuitive so you can almost always find a related file.

It works by splitting the text editor into two panes and intelligently deciding what to display in the second pane based on the file you are editing in the first pane. For example, if you are in a storyboard, it will show the view controller code related to the view you are editing; if you're in an Objective-C implementation file, it will show you the file's header. You can also tweak the Assistant Editor to show files based on common filters or navigate to a file manually.

Say I’m looking at a class and trying to view how it's used. This is the perfect task for the Assistant Editor. By default the Assistant Editor selects the implementation file because we were on the header, so I tweaked the filter to show files that include the file on the left. Right away I find a usage of the class and wrap my head around how to use it. I used to do this by doing a project-wide search, but the Assistant Editor is faster and allows me to keep both contexts on the screen at once. You can see this in action here.

Protip: A common activity while working with UI files in Xcode is setting IBOutlets (IBOutlets are in-code references to a view in Interface Builder). There are quite a few ways to do this, but my favorite is using the Assistant Editor to control-drag the view right into the code file. Watch how to do this here.


  • ⌘ ↵ and ⌘ ⌥ ↵ to show/hide Assistant Editor
  • ⌥ as modifier to execute in Assistant Editor. For example using fuzzy file search ⌘ ⇧ O, then holding ⌥ when selecting a file will open it in the Assistant Editor instead of the Main Editor.

Use, Edit, and Add Actions to Breakpoints in Xcode

Breakpoints are a great feature for more experienced Xcode users. Why? Well, debugging is hard and a developer will spend more time debugging than writing code over the course of his or her career. Xcode provides some powerful debugging tools that can be overlooked by people coming from other IDEs.

First things first, turn on exception/error breakpoints. This makes the debugger hit a breakpoint every time an error or exception is thrown. A lot of times when we get errors or exceptions our application crashes and we end up in a nasty call stack of assembly code. Turning on the breakpoints will pause the debugger further up the stack in the application logic, which is more useful for diagnosing an issue than raw assembly. Check it out in action here.

You can then take breakpoints to the next level by editing them. I've done a lot of pair programming and the power of editing breakpoints can blow people’s minds. Most people are aware of the feature but not of its utility; I was lucky enough to have a wise developer teach me about editing breakpoints early in my Xcode career.

Protip: Edit the breakpoints to add an action to them. These actions can vary from debugger commands to log messages. Say, for example, that I wanted to know when this view is loaded in the application lifecycle. Instead of adding a traditional breakpoint and disrupting my workflow, I can make a sound play when the breakpoint hits but the debugger doesn’t stop the application (via the “Automatically continue after evaluating actions” checkbox). Now I can go on my merry way testing and hear a pleasant beep whenever the view controller is loaded. Here's a quick demo to show you how to set it up.

Xcode's Version Editor carries two powerful code reviewing features. I use the first, Blame mode, when I come across code that looks out of place or is difficult to comprehend. Blame allows me to find out who the original author is and why they wrote the code, assuming they wrote down the reason. If they didn’t write down the reason, I’ll usually contact them and ask myself.

Likewise, the Compare mode helps me pinpoint exactly what's changed in the code before I upload it. Did I accidentally leave in some testing code or an empty comment? Compare will tell me. Then I can revise the code and push it up for review without having another developer wade through my accidental changes. The Compare mode of the Version Editor can also be useful in tracking down bugs.

How exactly do I use the Blame and Compare modes? Say I'm trying to track down the cause of an issue. I notice that somehow along the way temporary certificates were added to the code. So I use the Blame mode to find out when we added temporary certificates (denoted by the tempCertificates variable) and why. It tells me right away that it was added last year to fix a crash. Now that I know we added temporary certificates last year, I figure that probably didn’t cause our issue. Well, what else changed? To find out, I pull out the Compare mode, set the comparison to the commit introducing the temporary certificates, and learn that we recently made allowedCertificate a require. That must be it! Now I’ve located the source of my issues and can start coming up with a solution.

Another useful feature to take advantage of while reviewing code is the Show Related Items feature in Xcode. I affectionately call this the “Magic Menu” because even though it’s super useful, I never knew it existed for my first year or so using Xcode. It’s well hidden and doesn’t look clickable, but it packs some power with the Callers and Callees feature, showing you where the code you’re looking at is called and to whom it makes calls. This helps me figure out what could be broken by a change and how to alter a chunk of code without breaking things. Click here to see the “Magic Menu” in action.

Add Functionality to Xcode with Extensions

Extensions add new or missing features to Xcode. Unfortunately, the extension ecosystem isn’t as robust or well known as other IDEs. There are still a lot of cool things out there, but the problem is discovery. Most IDEs have an extension gallery built-in, whereas Xcode doesn’t even document their extension APIs.

That’s where Alcatraz saves the day by adding a package manager for Xcode extensions, templates, and themes. Before we get to it, know that you’ll have to reinstall Alcatraz on every Xcode update to have the extensions continue to work (fingers crossed that Apple is more lenient about this in the future). You can find Alcatraz at http://alcatraz.io/ and the installation consists of a terminal command plus restarting Xcode.

FuzzyAutoComplete: The Open Quickly (⌘ ⇧ O) search has fuzzy matching for file and symbol names but Xcode’s default implementation of autocomplete only matches from the beginning of the word. This extension ports the open quickly matching logic to autocomplete.

VVDocumenter: Helps you document public interfaces by giving you an appledoc compatible template whenever you type “///” above a method.

Uncrustify: Allows you to specify a coding style and then formats code on save or ad-hoc so you don’t have to constantly tweak code to match your style. You can check in the style configuration to the root of a repository and anyone who has the extension can automatically format their code in the right style. Caveat: Only works for Objective-C right now.

Color Themes: Xcode ships with a set of default themes. But if that’s not enough, installing themes from Alcatraz is the way to go.

AdjustFontSize: Increases or decreases the font size in the Xcode editor.

DerivedData Exterminator: Adds a button to Xcode to fully clear its cache. This is useful in debugging build errors.

ObjectGraph-Xcode: Generates a graph of dependencies between classes in a project.

OMColorSense: Shows a preview of a UIColor or NSColor from within the text editor. It helps by giving a visual representation of the color you are creating or editing. Here's an example video.

OMQuickHelp: Rather than using Xcode's documentation viewer, this will open Dash.app to review documentation.

SCXCodeSwitchExpander: When using switch statements in Objective-C, it can be easy to forget to check all cases, which can result in bugs. This plug-in auto generates your switch statement code, safely handling all cases.

Maximize Your Efficiency with the Interface Builder

Xcode includes a visual tool for making user interfaces called Interface Builder. It isn’t required to build UIs with Interface Builder, but it makes the tedious task of tweaking UI a lot easier. Most of the action in Interface Builder comes from the Utility Region of Xcode, so it’s important to know what parts are useful and when. These six unlabeled buttons show up once you open the Utility Region (if you don’t see it, use the ⌘ ⌥ 0 shortcut) while you’re in Interface Builder. Each one is of varying importance and finding which one you need can be confusing to Xcode beginners. From left to right they are: File Inspector, Quick Help, Identity Inspector, Attributes Inspector, Size Inspector, Connections Inspector.

File Inspector: This feature is very rarely used. However if your heart desires, you can click this to turn on and off auto layout and configure localization.

Quick Help: This feature is also rarely used but will link you to the documentation for the item you have selected.

Identity Inspector: A more useful feature, the Identity Inspector is used for accessibility and to set the class for custom views.

Attributes Inspector: I use this one the most. It allows you to configure the properties, like label text, background color, and alpha value, of the selected item.

Size Inspector: Another useful feature, the Size Inspector allows you to view and edit Autolayout constraints or configure springs and struts.

Connections Inspector: The frequency at which you'll use this depends on your IBOutlet workflow. The Connections Inspector allows you to hook up and view IBOutlets.

Concluding Note

You don't have to use every trick listed above to be an Xcode pro. Everyone has a list of their own favorite Xcode tricks that help their development process, and no two lists will look exactly the same. There's a great joy in figuring out which shortcuts and hacks suit your development style the most. I hope this list has inspired you to take a look at your own Xcode experience and figure out additional ways to make yourself a more productive and proficient developer.

Written By:

Nathan Hillyer

Nathan is a full-stack developer who works primarily on mobile apps. He's passionate about education and empowering people to take learning into their own hands.