Xcode Tip of the Day: Where Am I?

As soon as your app grows to more than a few view controllers, you can easily find yourself looking at code in Xcode’s code editor without a clear idea of where that code lives in your project as a whole. You know what code you are looking at, because the jump bar at the top of the editor tells you the file’s name. But where is that file in your project?

“No no,” you say, “how could that be? There you are in the Project navigator. This is your table of contents for the entire project. All your code files are laid out for you here, nicely clumped into hierarchical groups that you have created for organizational purposes. You click the name of a code file, and that code appears in the editor. How can you not know where the code is in your project? You just clicked it — that’s how you got here in the first place!”

Ah, but you can arrive at code in the editor in many other ways. For example:

  • You might do a global Find and click a file listed in the Find navigator.

  • You might select a name in your code (the name of a class, a struct, an enum, a method, a property, and so on) and click Jump To Definition (there are many ways to make that move).

  • You might select a method in your code and use the Related Items menu at the left end of the jump bar to view one of its Callers.

And so on.

In short, exploring your code, tracking things down, figuring out how things work (or why they don’t work), involves jumping. And as soon as you start jumping around in your code, you are on your own. Jumping is something that happens in the code editor. But the Project navigator, which acts as the table of contents to your project, doesn’t necessarily change its display just because you are now viewing a different file in the code editor. Indeed, you probably wouldn’t want it to.

But now you do want it to. You have jumped to some piece of code, and you want to say: Okay, Project navigator, get in line here! Show me where I am.

This becomes particularly important when the notion “where I am” assumes semantic significance. That can easily happen if you’ve done a good job of grouping things in the Project navigator.

For instance, in a recent large project I was working on, all services were in the Services group, all entities were in the Entities group, all extensions were in the Extensions group, all custom views where in the CustomViews group, and so on. Moreover, we were using VIPER to organize our code, so every view controller was in a group of its own, accompanied by its associated Presenter, Interactor, and Wireframe. In other words, in our app, groups were meaningful, clumping together things you would very likely need to see together.

In a situation like that, the project’s group hierarchy is big and deep — and meaningful. In a way, you are now hoist on your own organizational petard. Your organization has meaning, so you need to be able to see that organization in order to work on your code. That’s why you want Xcode to show you where you are. To work on your code, to understand it, you need to be in that code’s neighborhood. That’s why you want to say: Show me, in context, in its group and with all its accompanying group members, the listing for the file I am currently viewing in the code editor.

And there’s a command for that. That command is Reveal In Project Navigator. You can reach it in the contextual menu under Navigate. You can reach it in the menu bar, also under Navigate. And it has a keyboard shortcut. The default shortcut is Shift-Command-J.

Using that keyboard shortcut has become second nature in my use of Xcode. I say Shift-Command-J all the time. I do a global Find, I do a Jump To Definition, or whatever; I find myself looking at the code I’m interested in, and I immediately hit Shift-Command-J to show my place within the Project navigator.

It may seem like a very small thing, but it has completely changed my Xcode life; not to put too fine a point on it, the pain quotient associated with developing code has gone way down. Try it! Who knows, it might change your life too.

You Might Also Like…

Little Swift Tricks: Boxing Multiple Types

Here’s a little Swift language trick I sometimes use — more often than you might suppose, actually. As I’m sure you know, Swift is very strict about the types of its objects. You have to declare clearly what type a reference is, and from then on, you have to stick to that. That’s one of …

Little Swift Tricks: Boxing Multiple Types Read More »

    Sign Up

    Get more articles and exclusive content that takes your iOS skills to the next level.