In Xcode, the object of your attention is very often two or more files simultaneously. In Objective-C, you might want to work in a class’s header file and its implementation file. In a storyboard-based app, you might want to work in a storyboard scene and in the UIViewController subclass that it corresponds to. You might want to edit a method in one class, and also a method in a different class that calls the first method. And so on.

In Xcode 10 and before, to help with this, there was something called an assistant editor that allowed you to work in two places at once; but you were limited to just two places, and by default there was rather a complicated automatic relationship-based interplay between what the two places could be. It happens that all the examples I just gave are cases in point; the assistant editor knows about the pairing between header and implementation, or between storyboard scene and view controller subclass, and with some futzing it can be made to display a caller and its callee, at least in some simple situations.

But one of the absolute best features of Xcode 11 is that it introduces, for the first time, true multipane editing. Gone is the limitation to just two panes. Gone is the limitation that expects a relationship between the edited objects. You get to construct panes, and you get to say what goes into each pane. The assistant editor still exists; but you are far less likely to use it. You’ll use true multipane editing instead.

So what’s the problem?

The problem is how to configure the panes. If you’re like me, once you’re aware of the multipane interface, you start out generating a second pane by Option-clicking. For example, let’s say you Option-click in the Project navigator. If there was just a single editor pane before, now there are two editor panes; the second one displays whatever you just clicked on. That’s good, but there isn’t enough control over the details of what actually happens.

For instance, sometimes the panes appear side-by-side:

I usually find that configuration pretty much useless; I prefer above-and-below. Even worse, I can’t figure out a rule for when the panes appear that way. Sometimes they appear side by side, sometimes they appear above and below, and I don’t know why. And when you’ve already got two panes and you want to add a third one, the problem is even worse.

For months after Xcode 11 came out, I really enjoyed having true multipane editing, but I felt helpless whenever I made a new pane. It was like a crap shoot. I’d Option-click, and something would happen. Sometimes, it was what I was hoping for. A lot of the time, it wasn’t. (I don’t actually know what a crap shoot is, but I hear that they work like this.)

And then one day I had a revelation: I discovered the destination chooser.

Choose your destination

The destination chooser in Xcode 11 is a really slick interface. When you summon it, you get a kind of overlay on your existing pane, like this:

Now you can use the keyboard to put the target file editor where you want it:

• If you hit Return right now, the target file replaces the current file.

• If you use arrow keys and then hit Return, the target file appears to the right or below the current file in a new pane.

• If you hit Command-T, the target file appears in a new tab.

• If you hit Shift-Command-T, the target file appears in a new window.

• If you hit Esc, the destination chooser simply goes away.

The question now is how to summon the destination chooser. By default, it appears when you Shift-Option-click on something, such as a listing in the Project navigator. But that’s not good enough for me; I want the destination chooser all the time! To configure that, I’ve set it (in Xcode’s Navigation preference pane) to appear in response to an Option-click:

Now the destination chooser is effectively the default. To be sure, that means I have to take multiple steps when I Option-click: instead of the new pane just appearing, I have to say where it goes. But that is exactly what I want! This way, I’m in control.

Other ways to summon the destination chooser

You may have noticed that I keep hedging my bets as to what you’re doing when you hold Option to summon the destination chooser. It might be that you are clicking a file’s listing in the Project navigator, but it might not. Basically, the idea is that you can now hold the Option key during any navigation command, and summon the destination chooser.

For example, let’s take Shift-Command-O, the Open Quickly window. Suppose I want to jump to my app delegate in a new pane. I say the following:

1. Press Shift-Command-O to open the dialog.

2. Type “appdel” to select the AppDelegate class.

3. Hit Option-Return!

Now the destination chooser appears, asking me where I want to see the AppDelegate class. I can see it in the current pane, in a new pane to the right or below, and so on.

The same thing for Jump to Definition. Let’s say I want to see the UIViewController header. You probably know that you can Control-Command-click on the term UIViewController in your code. Instead, I Control-Option-Command-click, and the destination chooser appears; now I get to say where I want to see this header.

I could go on, but the mind begins to reel.

One more thing

Perhaps this goes without saying, but perhaps it doesn’t, so I’ll say it: When I refer to working in two places at once, that includes two places in the same file. It is perfectly legal to open a file in an editor pane and then open the same file again in another editor pane. The file that you Option-click in the Project navigator (or whatever) can be the file you’re already in.

That way, if a file is long, perhaps even only a little bit long, you can operate into two areas of the file simultaneously.

This is such a useful thing to do, in fact, that there’s a shortcut: Command-Option-Comma. That means: pretend I Option-clicked on the very file I’m already editing. In my configuration, that shortcut summons the destination chooser, and now I can decide where to put this additional editor pane viewing this same file.

An unsolved problem

An issue is that, even when the panes appear above-and-below, they can appear in the wrong order:

In that example, I started in the storyboard, and Option-clicked to summon the corresponding view controller code. It happens that I wanted the code on top and the storyboard on the bottom. But that’s not how it turned out, and I don’t know how to swap them. The destination chooser doesn’t let me open the view controller in a pane above the storyboard. To me, that’s a bug.

A new alternative

Xcode 12 has introduced another way of working in two places: document tabs. These allow you to “freeze” an editor pane so that you can readily switch between two or more files. You can’t see them both at once, but you aren’t subdividing the valuable editor real estate. It will be interesting to see whether this new mechanism changes my work habits.

You might also like: Xcode 12 — What a Pane!