Xcode UI Improvements

Really, Apple just needs to release their plugin documentation - and some of these problems could actually be fixed by developers who have to fight them every day.

FWIW, If you use the key commands, the first and third issues are avoidable -- though, I have run into all of the issues when using the mouse.

There's a key combo for that opening the find and replace menu; ctrl + cmd + c. Then you can tab through. Hitting enter will "replace and find next", shift + enter will "replace and find previous."

By default, there aren't any explicit key combinations for specifically replacing the selected text / replace all / replace and find {next, previous}. But, you can set them in Xcode's preferences, under the Key Bindings tab (in the Edit -> Find subtree). I hijacked cmd + r (from "run") for "replace and find", shift + cmd + r is used for "replace all".

Not to mention that locating the search-in-selection feature is now tantamount to discovering an easter egg. I had to google it.

Prefixing methods is ugly. Methods should be named after what they do.

Squeak (not sure about other Smalltalks) has a thing called protocols: a method belongs to a given protocol and the browser shows it to help you explore your classes. Depending on the method name, the browser can suggest a protocol to file it within. A "sort by protocol" could then be useful in this scenario - provided you had some way to tell the IDE where your method should be grouped.

The only thing I disagree with is the visual dropdown for enums (e.g., the modalPresentationStyle). At the end of the day we're still writing code - I feel like instead of English-equivalent descriptors like "Full Screen", "Page Sheet", etc, it needs to labeled with the actual programmatic name. This way the UI is a transparent, helpful supplement to code, not an opaque interface.

This way when I type:

viewController.modalPresentationStyle =

it will pop up the list of possible values, along with visual aids, but I can just keep typing the value I want and tab-complete it. This keeps workflow smooth and prevents me from having to exercise the mouse, and keeps me focused on the code I'm writing rather than creating something that's more of a wizard.

The imageNamed example is a good one: it displays the string you'd use under each icon, and hopefully the search narrows as I begin to type the image name. Quick workflow-easing popups should not require users to interact with them.

Plugins for Xcode would be great.

My first candidate is one that helps you write code that will run under GNUStep.

If Macs have 10% market share than being able to port your code to all other Unixes with a simple recompile would increase your market by about 10%.

And Mac programmers could help by filling whatever blanks GNUStep may have.

I didn't think that Xcode had an API that would allow this. To my knowledge the only thing the API allows is adding differ end ways to build things. For example, adding fortran support natively. I could be wrong though.

I agree this is the way that the code autocompletion should be though.

Yes, I second this.

An absolute tour-de-force article, which I've skimmed and plan to go back an re-read.

One point though, successive versions of XCode help have got slower and slooowwwwer. The current 'public' release is wretched compared to even a couple years ago.

This is reminiscent of what happened to Visual Studio / Visual C++, in that Visual C++ 4.2 (?) had a fantastic super-speedy help, which basically slowed down to a crawl in later versions, and lost its 'tight' feel.

Even if nothing else in XCode got fixed, speeding up the documentation would be a big step forward.

I disagree entirely. There's a lot of things it does poorly - from managing the list of files in the project (why can't I have it just choose a directory?), it's half-baked implementation of Open Quickly, and it's bad find UI.

But all of this wouldn't be an issue if XCode was easily extendable with plugins. And this is where Eclipse and Visual Studio wins out - you can download plugins to do almost anything you need, and to customize it exactly the way you want it. This is the most glaring omission from XCode, and it's really long past due.

I am annoyed by the error bubbles too because they truncate the actual error message - you have to open a whole new window just to see the entire message. In Eclipse, you get a red (X) in the sidebar on which you can click (and a list of problems) so you never have to fight any extraneous windows just to see your error in context.

In my opinion, Eclipse is way better than XCode (not to mention more versatile), and Eclipse's code assist (or whatever they call it) is far superior to XCode's precisely for the reason outlined in this article.

Maybe it's because I'm relatively new to OS X but I find Visual Studio and its single-window interface vastly more efficient and usable than Xcode+IB and it's plethora of open windows.