Supercharging Your Xcode Efficiency

Some Behavior Recommendations

There are two different sets of actions I recommend for the Generates output event, depending on your development environment. If you have a dual-screen environment, try the first one. If you work on a single screen, try jumping ahead to the second method below.

If you work on two or more screens, wouldn’t it be handy to have the debug console in its own window on your second screen? Well, you can set up the actions so it looks like this:

Now build and run, and you’ll see a separate window appear. Position it on your secondary display, and just like that, you have yourself an efficient debugging setup!

If you have a single screen environment, maximize the effective area for the console by hiding the utilities pane and setting the console to take up the entire debug area. To do this, set up the actions like so:

Now run the app, and watch as Xcode automatically follows your commands!

You’ll also want to change the behavior to account for when the project pauses. Go to Pauses event under Running, and change the settings like this:

Now whenever you hit a breakpoint, you’ll get a new tab named Fix that will display the variables and console views, and automatically navigate to the first issue. You should really think about demonstrating this next time you host a party, because it’s that cool.

Well, maybe not…unless your guests are burgeoning coders.

The last behavior you’ll create for now is the one of my personal favorites. This is a custom behavior that you can assign to a hotkey. When triggered, it transforms Xcode into what I refer to as Dev Mode, which is an optimized layout for developing your next masterpiece.

To do this, create a new event by pressing the + button near the bottom left of the behavior preferences window. Name this behavior Dev Mode.

Double-click the Command symbol (⌘) to the right of the event name, and then type Command . to define a hotkey.

Next, configure the behavior with the following actions:

Now whenever you press Command . you’ll be greeted with the same, clean development interface.

This is the perfect time to introduce you to Xcode tab names, which work beautifully with behaviors.

Xcode Tab Names: You can rename an Xcode tab simply by double-clicking on its title. This is rather a useless feature by itself, but becomes extremely powerful when you pair it with behaviors.

In the second example above, when modifying the Pauses behavior, you named the tab Fix. This means that when the behavior is triggered, Xcode will use the Fix tab if it exists, or create a new tab if it’s not already there.

Another example is the dual-screen Starts behavior. If a tab named Debug is open from a previous run, it’ll re-use it instead of creating a new one.

You can create some very interesting behaviors by utilizing tab names in this manner.

Okay, take a few minutes to play around with behaviors. Don’t worry, this tutorial will wait for you. :]

Wait, are you back already? Okay, then it’s time for some action!

Test Your Skills

In the following sections, you’ll learn to put these tricks to a test, and learn some new ones while working on CardTilt.

Build and run CardTilt, and you should see a screen like this:

Not what you’re seeing? Looks like it’s time for some ninja-level bug squashing!

Locating the Bug

It appears as though the app is having trouble loading the data, and it’s your job to fix it. Open CTMainViewController.m and enter Dev Mode (Command .).

Notice these first few lines in viewDidLoad:

self.dataSource = [[CTTableViewDataSource alloc] init];
self.view.dataSource = self.dataSource;
self.view.delegate = self;

Looks like CTTableViewDataSource implements UITableViewDataSource and provides the table with data. Time to use your Xcode skills to confirm this and get to the bottom of the issue.

Hold Command and click on CTTableViewDataSource to open CTTableViewDataSource.h in your primary editor. CTTableViewDataSource.m should’ve loaded in your assistant editor, as well. If that’s not the case, use the Jump Bar to change the assistant editor mode to counterparts like this:

Look around, and you’ll see members holds the data, and loadData loads it from the bundle. That looks like a great starting point for debugging. Switch CTTableViewDataSource.m to the primary editor by right clicking anywhere inside the assistant editor, and then choosing Open in Primary Editor.

Below is an animation showing the steps you’ve taken thus far:

Ninja Dojo: For bonus ninja points, you can do all of the above without your mouse by following these steps:

Remember that being a ninja isn’t always the most efficient route, but you’ll always look cool.

Bonus Ninja Tip: Open Quickly (Command Shift O) is one of the coolest Xcode ninja tools. Use it and love it.

1. Press Command + Shift + O, typeCTMainViewController.m and then hit Enter to open the controller
2. Enter Dev Mode (Command .).
3. Place your cursor on CTTableViewDataSource and press Command + Control + J to jump to the definition.
4. Change focus to the assistant editor by pressing Command + J, ->, then Enter.
5. Bring down the jump bar tab by pressing Control + 4, then navigate to counterparts using arrows and Enter.
6. Press Command + Alt , to open CTTableViewDataSource.m in the primary editor.

Fixing the Bug

You need to determine if data made its way into members, so start by setting a breakpoint right below self.members = json[@"Team"]; and run the project.

Note: If you are new to setting breakpoints and debugging in general, check out our video tutorial series on debugging.

Of the behaviors you looked at earlier, Generates output will get triggered first, and then Pause follows immediately after. Because of the custom setup you created for Pause, you’ll get a new tab named Fix with a layout that is perfect for debugging! Now you have another cool trick to show your friends at your next party.

Look at the variable inspector. Do you notice that self.members is nil a little, um, fishy. In loadData you can see that self.members is populated like this:

NSDictionary *json = [NSJSONSerialization JSONObjectWithData:data options:kNilOptions error:&error];
self.members = json[@"Team"];

Dig into json in the variable inspector, so you can determine if the dictionary loaded correctly.

You’ll see the first key in the data is @"RWTeam" instead of @"Team". When loading self.members, the key used the wrong data. Ah-ha! Eureka, there’s that little bug!

To resolve, you need to correct the data in the source file:

1. First, enter Dev Mode with Command ..
2. Press Command + Option + J to jump to the filter bar and type this: teammember.
3. Then, hold Alt and click on TeamMembers.json to open it up in the assistant editor.
4. Finally, replace "RWTeam" with "Team".

This is how it looks when you follow these steps:

Now remove the breakpoint, and then build and run. You should see this:

Much better, but it looks there is another bug. See how the descriptions below Ray and Brian’s titles are missing? Well, that’s a good thing because you’ll get to add more points to your coolness and ninja stats by resolving the problem.

Stats:

Coolness points gained:200

Total Coolness points:800

Ninja points gained:100

Total Ninja points:350