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.
You misunderstand what I mean - personally I find it impossible to remember the crazy number of enums that iPhone programming foists upon you, so the popup of options is greatly welcome.
The thing I don't like about that is that instead of displaying the name of the enum, it displays a human-friendly name. I love the menu, but I'd rather not move my mouse to select one of the options, nor move my hands to the arrow keys to navigate it. It'd be great for the popup menu to provide the actual programmatic name (along with the awesome visual aid of what the enum actually means) so I can just start typing the first few characters of what I want, hit TAB, and complete it.
Similarly, if I want to include an image, the popup with the image previews is awesome, but I'd rather not have to move my mouse to scroll through it and pick it out. Odds are I have some notion of what the name begins with.
You could solve this easily by only activating it after a period of inactivity. Stop typing for a second, and the suggestion box pops up.
Xcode has a preference (well, two) that help out with autocorrection. I heard about it at last WWDC, and can definitely see the tip being mentioned again at the next one (that is, if you're going to WWDC and go to the Xcode presentation). I believe the key I changed/added after the presentation is:
that may be related. Basically, it lets me hit enter to autocomplete methods/functions/classes/etc right away and only showing whats actually available to the class.
If those aren't it -- and someone wants -- I'll skim/rewatch the Xcode presentation from last year and look it up.
And built into every Cocoa app: Hit escape while typing and it will show you a list of available completions. In Xcode, this ends up being potential classes and methods available from the framework.
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.
Great update on the UX; Significantly better. The design is lovely as always. Way to go Taptivate!