Work Efficiently With XCode

XCode often slows down the entire system to a crawl, forcing the coder to either restart the application or even the computer itself. Unfortunately, we can’t control how aggressively XCode uses system resources. Fortunately, we can learn to work faster and more efficiently by learning some of the hidden conveniences inside XCode.

Below are some tips and tricks I use in my everyday coding sessions. This post has the beginner in mind, though I hope advanced and expert XCode users may occasionally find something useful.

**Disclaimer: Examples below are done using XCode 4.2.1

Master Your Shortcuts

The goal here is to use the hot keys to speed up your work flow. Reducing the number of times you use your mouse to navigate the UI will help you stay focused on the task at hand by recapturing your attention to the cursor back to the actual lines of code.

  • Open new tabs using ⌘T, navigate between them using ⌘⇧{  or  ⌘⇧}
  • Build/Run/Clean using ⌘B/⌘R/⌘K, respectively
  • Quickly open files using ⌘⇧O and enter file name
  • Go to a line using ⌘L  and enter line number
  • Jump between .h/.m files using ^⌘↓
  • Navigate forwards/backwards in a single tab using ^⌘→ or ^⌘←
  • Go to the end or beginning of a line using ⌘→ or ⌘←
  • Find text using ⌘F
  • In the middle of typing, Tab to autocomplete, Esc to see close matches
  • Highlight some code and ⌘/ to comment/uncomment
  • Indent or dedent(?) code using ⌘] or ⌘[

This is not an exhaustive list, but these are certainly enough to get you started on training your muscle memory. If you have any other cool shortcuts you’d like to share, please leave it in the comments below.

Maximize Your Usage of Screen Real Estate

How you do this will be a little bit of personal taste. In any case, the point here is make it so everything you can see on the screen is relevant to the task at hand. For example, don’t clutter your windows with unnecessary panels that you will never use. Do you really need the debugger panel on the bottom if you are coding? Or the object panel on the right unless you’re editing a .xib?

Note that window layouts are done on a per-tab basis, and creating a new tab will clone the layout from the previous tab.

Here’s a screenshot of how I chose to layout a single tab for coding:

Let’s consider this portion of the screen (top right):

Direct your attention to 3 buttons (which are mutually exclusive) above “Editor”. From left to right they represent Standard Editor, Assistant Editor, and Version Editor. I use the Assistant Editor, this allows me to edit my implementation file in the middle while having an auxiliary editor on the right, which I use exclusively for “counter parts”, or more specifically, header files. You are free to use a drop down menu to configure what you would like to be placed there. Like so:

If your screen is too small to support two editors, consider using multiple tabs instead.

Next, consider the 3 buttons above “View”. Toggling each in turn will slide in and out a panel from the left, bottom, or right. In this case, I only want the left panel, and more specifically, I only want to see the 4th tab (⌘4) in this panel for any warnings/errors I may introduced while coding this class.

**Aside: You may have noticed the presence of line numbers, which are very useful when looking at code with another person. To turn this on, find the option under the “Text Editing” tab in Preferences (⌘,) .

Moving on, let’s take a look at a tab I use for debugging (a topic to be addressed in a future blog post):

Here’s the setup. A Standard Editor to get the maximum view of a breakpoint’s context. A left panel (5th tab) to detail the thread and stack trace. Also note that I eliminated the Toolbar at the top altogether. A Debugger panel on the bottom for, well, debugging. Note that you also want the split view for the debugger so you can see the local variables and the log at the same time.

Miscellaneous

Handling XCode Behaviors

Say you have two tabs open, one for file1 and the other for file2. You also have a breakpoint in file1, but you are on file2′s tab. Now you run the project and it hits the breakpoint in file1, the default behavior will change the tab with file2 into file1, leaving you with an annoying situation where you have two tabs that are looking at the same file. After a few more hours you’ll end up with multiple duplicates, and now you need to either close the tabs or change the duplicates back to what it should have been.

Here’s how I get around this inconvenience. XCode allows you to change its behavior at crucial times of the development process. Here we are interested to when we hit a breakpoint, which is equivalent to saying the “Run Pauses”, note that this will also happen in the case of a crash. To change this behavior, go to Preferences and mimic this:

In top-down order, the lines with blue check marks tell XCode to do the following.

  1. Show the tab named “Debug” (it will create one if this doesn’t exist)
  2. Show the 5th tab on the left panel (the one with stack traces)
  3. Show the bottom panel (debugger) with the splitview
  4. Hide the toolbar at the top
  5. Show the Standard Editor

And this pretty much recreates my debugging layout for me. As you can see, there’s a lot of behaviors you can customize and automate, in the end, it is a matter of taste.

Alternative to NSLogs

Consider a different situation, you’ve built and ran your app. You’re noticing some weird behaviors, and you know it may involve a couple functions. To investigate these functions’ order of invocation and/or relationships, you stop the app and start filling in some NSLogs and rerun.

Don’t do this!! Instead, deploy a couple breakpoints in key places and right click on them to edit, pulling up this menu:

This menu is extremely powerful. You can conditionally enable/disable a breakpoint, ignore for some number of times, perform an action, or to automatically continue.

Using a combination of the above, you can effectively sprinkle “adhoc” nslog statements without having to stop your app and recompile the whole thing. And if you know more about gdb or lldb, you can print out values of surrounding local variables too!

Jump to Relevant Definition or Documentation

Maybe you want to see where something is defined. You might try to ⌘F on the project and look for it, but instead you can ⌘+(left click) on an interesting block of character, such as a method name, and it will either pop up a menu to ask you to be more specific, or take you to the only definition right away! You can do the same trick for Apple’s objects as well. You can do the same trick for Apple’s objects as well.

Have you ever tried to search the Documentation in Organizer? It takes an eternity. Instead, use ⌥+(left click) on something you want to search for to bring up a menu like this:

Not satisfied? Click on any of the blue text to bring you full fledged documentation window. I’ve literally typed what I wanted to search in some random place just so I can do the above trick to get to the documentation as fast as possible.

Global Breakpoints

When your application crashes, you probably go into the debugger to identify where the crash happened, then you set up some breakpoints before the offending line, and try to reproduce the exact steps. And hopefully, you’ve reproduced your steps to hit the exact same crash. What if you can insert a breakpoint dynamically right when the system throws the exception? Here’s how:

  1. ⌘6 to bring up the breakpoint navigator
  2. Click + on the bottom left
  3. Add Exception Breakpoint…
  4. Done

If you’ve done it correctly, you should see:

That’s it! Next time you crash, you’ll be able start investigating right away!

Conclusion

Now that you know how to work smarter, hopefully you can spend the rest of your time on things that actually matter, such as implementing a feature or fixing a crash. While I’ve dipped into a little bit of tricks regarding debugging, it really deserves its own blog post. So next time, I’ll be giving a small tutorial on how you can use the various instrument tools to help you manage your apps memory usage and performance bottlenecks. Thanks for reading!

This entry was posted in All, Engineering. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.

Add a Comment

Your email is never published nor shared.

*
*

8 Comments

  1. Cory says:

    One nit I have to pick: Xcode, not XCode.
    Some good tips though, I especially like your alternative to NSLog.

  2. yogsototh says:

    Thanks for these tips. I am mostly a Vim user but for debugging Xcode make a very good job. Your alternative to NSLog will save my future days. Thanks!

  3. David says:

    Regarding using ⌘→ or ⌘← to go to the end/beginning of a line: Using ^E and ^A are even faster (because you don’t have to take your fingers from the home row).

    If you really want to get the most out of Xcode, you should learn the basic Emacs movement keys. Most are available in Xcode.

  4. alexito4 says:

    Wow thanks!
    I didn’t know the alternative for nslogs! ;)

  5. Craig says:

    Great tips, thanks! BTW, the opposite of indent is outdent.

  6. qun says:

    wow, this is a very nice tip for xcoder, thanks for sharing, though I know some of them, but some are new to me and very helpful.

  7. Thank you for those shortcuts.. it did make work a lot easier and flexible

  8. Martin says:

    Select some text and auto-indent with ^I – it also works in many IDEs.
    Another great shortcut is ” opt+cmd+[ " (or]) to move the selected text one line up (or down).
    I also set my own shortcut ( Preferences > Key Bindings ) e.g. ” cmd+9 ” to Show/Hide Toolbar. You can edit the behaviors to perform desired actions and assign a keyboard shortcut to it.