The learning curve is quite steep. The best advice I can give you is to unlearn what you know about imperative programming and make a concerted effort to understand Delegates and Notifications.
The classic example is when people try to use a NSTableView and ask "how do I send it the data?" This is the wrong question. The view will ask its delegate for the data in a cell by calling a method you implement in your own class when it is ready to display it. It's a really elegant way to do it, but it runs so counterintuitive to the typical pattern of bossing around a bunch of objects like you're the supreme object master or something.
> The classic example is when people try to use a NSTableView and ask "how do I send it the data?" This is the wrong question.
If this is what makes Cocoa "hard," then it's not unique to Cocoa. I'm seeing the same design patterns and philosophies of event-driven programming in recent toolkits and frameworks, even in places where languages like Java and C# are dominant. The drift away from imperative programming to more object-oriented and functional paradigms (sorry) is even showing up in unexpected places, like how jQuery made JavaScript take on OOP and functional aspects in coding style.
It's a learning curve everyone will have to traverse, since, in the future, heavy parallelism and capped clock speeds of future computer systems will more heavily favor such "modern" design techniques (a misnomer, since the concepts have been around for decades). Like many, the first languages I learned were stuff like BASIC, COBOL and Pascal, and I spent most of my college career unlearning stuff to program the "correct way."
(Just for the record, to the grandparent poster, Objective-C should only take you a day to learn. It's a strict superset of vanilla C, so much so that the first ObjC "compiler" was a set of pre-processor macros for a C compiler. All the real work is in learning the coding conventions in Cocoa; the language enforces surprisingly little.)
http://news.ycombinator.com/item?id=254256