Awesome tip! Never knew about this. Then again, how could I have known? Is this even documented in the Interface Builder help?

I'm really glad that Interface Builder is having a revamp, alot of the functions are currently quite undiscoverable, and the sparse "manual" doesn't really help either.

I "clicked" a few months ago to this button and was quiet surprised.
Apple should really try to implement Xcode prgramms for University projects.
Documentation from Apple is weak since the 1st day of OS X.
Not only in the developer area - not to mention Applications - compared to both NeXT and Classic Apple apps.
Last week somenone asked for a "design tool" for databases. Of course no-one even checked Xcode.
Pdf documentation does not replace high quality books.

Documentation is a tricky thing. Most people don't read manuals back to front, so it's not a solution in itself. Bloggers and one-on-one teaching seem to do a lot of good. There are some pretty good books out there, but Mac OS X is a very large piece of software. If you've seen this book in person, you can get a feeling for how involved this stuff really is.

The situation could be a lot better, though. Apple doesn't have the institutional commitment to developer documentation that Microsoft does. Not one of Apple's current manuals, in my opinion, meets the standard of Amit's internals book. The Apple material is usually better grammatically, but communicates much less information in the same amount of space and usually with more ambiguity. In part, the ambiguity results from Apple not wanting to be tied to specific implementation details, where Amit's book is all about the implementation details. But it also results from bad -- or simply incomplete -- writing.

This is probably partly because Avie T. didn't believe in a separate documentation group; he thought engineers could write documentation. Most engineers, even ones capable of excellent writing, can't crawl out of their heads and empathize with someone who doesn't already know the technology. There are major exceptions, but they are very rare.

In part, the ambiguity results from Apple not wanting to be tied to specific implementation details
I think this makes sense, since the programmer should generally only be focused on the interface. The implementations details can and do change. I realize this is a tricky area, though.

didn't believe in a separate documentation group; he thought engineers could write documentation
Apple has a separate docs group today.

One problem that i've personally experienced and seen around me in my previous job is that if you leave developers to write their own docs, they might end up being extremely focused on their own "pet features" and neglect the oher parts that they're not so keen on. Unfortunately, from the user's point of view, what the developer thinks is The Best Thing Ever might be just ho-hum for the user. And vice versa. So its great to hear that Apple has a seperate docs group now.

I guess my earlier comment on the sparse manual of Interface Builder should be rethought. Even if Apple does produce a really good manual for Interface Builder, how many amongst us would read it? I'm the type that likes to read manuals, but I know many of my fellow developers that i've worked with in the past don't. Manual readers seem to be the exception, and not the norm.

Perhaps Apple should start learning from the bloggers and podcasters and produce screencasts for their products. Imagine a WebKit podcast where the developers behind it will explain to you how to say.. implement download behaviour. Or perhaps an Interface Builder podcast showing you this exact tip that is mentioned in this article. All in video with commentary of course.

But text documentation must still be kept actively maintained, these videos should be though of as the potatoes with the text documentation as the meat.

The suggestions here that engineers are left to write the documentation or that Apple does not care about developer docs are - well, let's just say "wrong".

Apple has (to a close enough approximation) "always" had a Tech Pubs department (see, for example, this interview with Chris Espinosa or this folklore.org article)
NeXT also had a Tech Pubs group.

The documentation is considered part of the product. If you find it to be inaccurate, misleading, or insufficient in any way, you should file bugs. Without feedback, it is impossible to know in what way you consider it to be deficient or how it could be improved. For a long time now it has been easy enough to provide feedback using the form at the bottom of every reference page...

mmalc I did and a numerous of Swiss Apple User too. Especially the calculator application. Switzerland uses the dot as seperator for numeric results instead of comma. (comma is Germany)
This mistake was implemented in Version 10.3 or 10.4.
It never happened in OS Classic or NeXT.
The guy which programmed or maintain the currency converter is on LSD. It don't work. (Swiss Version at least, in the first version they forgot Switzerlands Currency)
The application Topcalculette works like a champ compared to the Apple calculator.
I know you're working hard - but that an application like calculator changes if it had worked over 20 years is a bit funny.

When OS X first reared its head, I would agree that Apple's developer documentation was...well, challenged. It wasn't that the dev docs were innaccurate or misleading, but they were certainly insufficient.

Apple, to its credit, has improved on this allot since 10.0.

But there are still gaps, as by gaps I mean not just explaining the arcana of say Cocoa Bindings, i.e. the rather full documentation of the principles of Key-value Coding, but also how to implement Cocoa Bindings in a few ways. And yes, Apple does have some sample apps that it uses to describe Cocoa Bindings in the docs such as Currency Converter and the Image app. But for anyone who is trying to figure out how to make a pull-down menu in a Cocoa App, one whose parts are implemented in code and not in IB, using Cocoa Bindings, those lil' apps are about as helpful in actually using this technology as a hole in the head. And the differences in implementing Cocoa Bindings in a Cocoa App vs. a Documents based app are not well documented or exampled, but differences there are.

Lastly, would someone from Apple's senior rank please authorize Developer podcasts, that is a series of podcasts on...say, Cocoa Bindings, Core Data implementation, among other subjects of interest to developers? I mean, come on, people at Apple should be looking at ways of leveraging Apple's own technology (read iPod and iTunes here) in getting info, documentation, and how-to's to developers. And what in the world possessed Apple's management to NOT deploy the WWDC sessions as videocasts? Just imagine how helpful THAT would be to developers.

It's not clear how the Calculator application is relevant to documentation?

It's also not clear if you are referring to the Currency Converter tutorial? If so, it is perhaps unfortunate that it does not illustrate the addition of a formatter to the text fields. It is intended, though, to provide a simple introductory example with little "irrelevant"(*) detail. I don't immediately however see any feedback that requests localisation -- indeed most of the feedback is complimentary.

If you think that it would be useful to illustrate the use of a formatter in the tutorial, please do send in feedback.


(*) This is not in any way to suggest that formatting in general or localisation in particular are "irrelevant", but they're not necessary for this example.

But for anyone who is trying to figure out how to make a pull-down menu in a Cocoa App, one whose parts are implemented in code and not in IB, using Cocoa Bindings

It's not clear what you're asking for here. If you want to know how to establish bindings programatically, and how the code you write compares to what you configure in Interface Builder, that's documented here.



And the differences in implementing Cocoa Bindings in a Cocoa App vs. a Documents based app are not well documented or exampled, but differences there are.

How so? Bindings work in exactly the same way whether you're developing an application derived from the "Cocoa Application" template or a document-based application.



Lastly, would someone from Apple's senior rank please authorize Developer podcasts, that is a series of podcasts on...say, Cocoa Bindings, Core Data implementation, among other subjects of interest to developers?

There is an ADC video that introduces bindings and Core Data here. If you would like to see more of this sort of thing, as ever, please send in feedback.

mmalc The calculator example is only used compared to your "feedback" argument above. The calculator is since more than one year wrong for the Swiss users.
to release WWDC Videos after say three months would be great.

Documentation and utility applications are developed by different groups...

WWDC videos were released to Select and Premier ADC members using iTunes within three months of the conference (see, for example, this report).