Xcode 10 Library

Hoping that Apple will read this thread and give us the option of docking the pane, I also have to add a comment so we have more votes on this.

I really really don't see how this is an improvement rather than beeing a deterioration. I mean, changing the content depending on the context should be possible even if the window is docked. So what amelioration gives this new feature us? It requires more actions than before to do the same thing. Even when it is kept open, the window is weirdly hovering on top. And if we have the option of keeping it open (and place it where it was in Xcode 9, which I guess most of us will do), then why isn't it dockable and always open?

I hope that next release will give us the old behaviour back. And if you don't find any good reason to change something, so please keep fixing bugs instead of trying to change things just for having something to do.

This is the first time I've been frustrated enough with a change to Xcode that I wanted to voice my concern. With this one change, Apple has made it far more annoying to work with Interface Builder, and it seems to add no benefit whatsoever. Now I have a new button, and a ton of empty space at the bottom right. I hope that they revert this change soon, or at the very least, allow us to dock the control in its original location. Time to start reviewing the changelog, and giving my opinion more regularly!

I agree. The mania to change for the sake of change is counterproductive in the extreme. Understand, the frustration here is not about the floating pane - it's about the 1000th Apple change for no reason, while removing user choice. What makes Apple believe they understand my work process better than I do? How does a floating panel, requiring clicks or keyboard actions, improve anything? Why does Apple object to user choice? Does Apple ever actually do usability research for product changes?

found the old UI guidelines here : http://modelessdesign.com/backdrop/204

General design principles from 1986 Mac -let us see how the Utilities library 'disappearing window' stacks up

• Metaphors from the real world- nope. i have never opened a toolbox / toolkit / paint pallette, took something out (or looked away), looked back and it had closed itself and put itself back in a drawer
• Direct manipulation - i can directly manipulate it, right up until the point it disappears from existence
• See-and-point (instead of remember-and-type) - by default you have to remember and type in order to find objects, unless you take the extra step of clicking the 'four squares in a square' icon view thing
• Consistency - i don't remember ever seeing a pallette-type tool window that disappeared after you drag an object from it, and ive been using many types of computers since 1985 and various GUI builders since the 90s.
• WYSIWYG (what you see is what you get)- what i see is a window, except that it disappears when you switch apps, or drag something from it, which is not what i expect from any window in any modern computer system.
• User control- no, i did not tell the window to close
• Feedback and dialog - there was no feedback, it just disappeared quietly, silently, without asking
• Forgiveness - if i dragged the wrong widget, i have to delete it, go back to the toolbox, open it up, scroll to, or type the widget again to find it, and drag it again.
• Perceived stability - see above
• Aesthetic integrity - well, a lot of stuff can be docked inside xcode, but the Library apparently cannot.

Granted i dont use xcode very much, i was trying to follow a Swift "hello world" tutorial from a year or two ago

Agree. This unwanted change reminds me when they stopped offering multiple windows in iTunes...surely they realize people have multiple monitors and like to spread out their work. They reintroduced the multiple window option a few releases ago.

Hopefully they will offer a docked view for object assets in a future release. It stinks right now to constantly be holding down bizarre key combinations.

Hopefully Apple will see this thread and decide to bring it back to its original location. There's just an empty space now where to old library panel used to be, so I don't really see why they would move it. Even on my 13" macbook I had no "space" issues with it being there.

This is an absolutely terrible design change, and i have no idea why they did it.

I submitted a radar. I'm sure its a black hole, but I submitted it nonetheless.

>This is an absolutely terrible design change, and i have no idea why they did it.

As noted above, Apple tends to on again/off again features in the tools just for the sake of it. Xcode isn't the only example, look at Photos... Death by a thousand changes, when only a handful over time were actually improved new features.

More about changing the landscape so the manager thinks they've done real work, where anything different gets passed off as progress, even if it means putting something back the last engr. just took out, while bulking the resume in the bargain, than it is about fine-tuning existing tools, genuinely making them better, earning a loyal user base in the bargain - they seem to think that it helps to keep users on their toes if they change the furniture on a regular basis, relying on some sort of stumbling 'discovery process' to promote learning, squelching hard earned workflow habits that might lead to...ghaa ..stagnated curiosity.

Heaven forbid they build trust in the tools, instead. Let's reap discord - keeps the louts on their toes.

Hello! I didn't really use Xcode for a year so I missed the change in Xcode 10... I just discovered this horrible change in Xcode 11 beta. I guess the voices against it in the bug report as a suggestion were not enough in number :/

For what it worth, I just sent my voice against it yesterday with the Feedback Assistant.