I somehow activated this once while clicking around but I'm not sure how I did it and I don't see it mentioned in the preferences or shortcuts.
Anyone know how this feature works?
If you double-click a dynamic tab, it will become a static tab.
Open Quickly (CMD+SHIFT+O) will open up a file into your dynamic tab.
From View->Always Show Tab Bar, Xcode will always show the document tabs, even if there is only one.
I'm not sure if "Document Tab" is the official name of these or not. That's what they're called in the "Introducing Xcode 12" page but I don't see them called that in Xcode itself.
It would be nice if there was a visual difference between a regular tab and a tab that contains document tabs? In fact the whole notion that a Document Tab is a tab and it contains tabs.
the whole notion that a Document Tab is a tab and it contains tabs is confusing
Open an Xcode project and close any Document tabs that may open by default in result of where you left off with your last session.
Now single click on a file in the Navigator - it will open in a Documents tab.
Now in the Navigator, randomly single click one file after another; you will see each successively replace the preceding in the same Documents tab.
Now in the Navigator, double click on a file to open it. It will also replace the last one you opened. But then the next file that you single click or double click, will open in a new Documents tab.
within one Window tab have multiple .swift files in different Document tabs
within a second Window tab have multiple .scn files in different Document tabs
within a third Window tab have one or more .xcassets files in different Document tabs
etc.
Using the term "windows" for the top tab like items, and "tabs" are those under each window - I can see a rational as grb2007 mentions for grouping related items.
But this was already possible by having an actual movable "window", with multiple tabs (which are now called "windows"). We have all used that function for years.
My biggest issue is that swiping between tabs seems to be broken. If I click on file1 in the navigator, it shows up. If I click another file2, it shows up. But swiping to the right doesn't show file1, but somewhere else. What's worse, is my file1 shows up for a second, then it's yanked away and that somewhere else shows up. I assume it's using the tab history, but I can't figure it out.
Anyone know how to either remove the new "tab" feature, or at least fix the swiping between files in the file history?
thanks.
Here's my attempt to answer dogcoder's issue (3rd paragraph):
Like grb2007, I've found out the following through experimentation rather than through Apple's Xcode documentation, though I tried hard to go that route.
If you open a project and close all the document (not window) tabs, to start fresh, then open a file in the project navigator, a temporary document tab is opened. Ignoring the tabs for a moment, if you click a couple more files in the project navigator, their contents will be displayed in the editor window. After doing that a few times, you'll find that swiping left or right works as you expected. It will go back and forth between the files you opened in the order that you opened them.
However, the more valuable use of swiping left and right, which matches the behavior of clicking the back and forward buttons in the document tab bar, is to do a manual "stack trace" through your functions and methods.
If you're examining a function's code and it calls another function, you can Cmd-Cntrl-click that second function's name to immediately open its file with it's declaration selected. As you go through its code, you Cmd-Cntrl-click a function it calls to move deeper into the logic. Again, that function's file will open with it selected. Let's say you repeat that sequence three or four more times. Now you're pretty deep in the calling sequence but how do you get back? The incredibly valuable answer is either the back button or swiping. Each back button click (or swipe right) will take you back to the calling function, so you can very conveniently move right back up the calling stack.
This approach includes clicks on any symbol, as far as I can tell, so you can use it to examine type and named value (let or var) declarations as well as function declarations and find your way back up to the top of the reference "stack" when you're done. Of course, if you go half way back up, then click the forward button (or swipe left), you'll retrace your steps back down the stack.
As you'd expect, if you go half way back up, then Cmd-Cntrl-click another symbol, the original stack below you will be lost and replaced by this new reference. Of course, this works whether the symbol you clicked was in another file or the same file you were already in. In either case, your editor window will display the referenced symbol's definition which will be added to the stack. This means that sometimes when you go back up the "stack trace", you will move within a file rather than opening a new file in the editor.
I just discovered this yesterday and haven't yet experimented with the relationship between these clicks and the document tabs but I thought this might be helpful for some.
I'd like to add a couple caveats to my previous post.
First, if you Cmd-Cntrl-click on a symbol, the editor will take you to the declaration of that symbol, as I said above. However, once you've Cmd-Cntrl-clicked on a symbol and it's declaration is displayed in the editor, you can scroll around in the editor. Wherever you scroll to will be the location displayed when going back to that symbol's place in the reference stack, whether the symbol you clicked on is shown in the window or not.
Second, it seems that Cmd-Cntrl-clicking will attempt to select any static tabs that have already been established for the newly opened file. However, if the file doesn't have any static tabs referencing it, a new temporary tab will be created and any subsequent Cmd-Cntrl-clicks on symbols in other files for which there are no static tabs will replace the file in the newly created temporary tab.
Again, I haven't exhaustively tested this, so I'm open to any corrections that others find in this behavior.