I first tried to learn mac development a year ago by going through http://www.amazon.com/Cocoa-Programming-Mac-OS-3rd/dp/032150... . I did the examples in the book, so I was getting my hands dirty somewhat, but as I went through the book I got more and more confused. There were too many questions I had that the book didn't answer, nor did Apple's online documentation.

Part of the problem was that I didn't know C at all. Recently I decided to have another go at it, so I read the first chapter of K&R and did all the exercises, then read a few of the other chapters (2, 5, and 6 I believe). After that, I read this book: http://www.apress.com/book/view/1430218150 . "Learn Objective-C on the Mac" has been great - it's readable, good-humored, succinct, and comprehensive. It's answered all the remaining questions I still had about ObjC and I finally feel like I get the language.

I tend to go back and forth with this. I read the entire book but stopped doing the exercises at some point and focused on the project I wanted to do. I think it's good to have an overview so when you do run into some problem it may trigger your memory about something you read so you can easily find the documentation you need, but nothing really replaces coding.

It helps if you're familiar with the terminology Apple uses in ObjC. But that's the sort of thing that you pick up as you go along, not know from the very beginning.

Ummm... Look "mutable" up in a dictionary?

I downmodded you because your response is snarky in addition to not being applicable. If you're new to Objective C and are used to a language like Ruby, where all strings are mutable, you wouldn't even realize it was necessary to use a class other than NSString to modify your strings.

If you're expecting a different language, framework, and platform to behave like a ruby, I would argue no amount of eschewing documentation and getting down to coding will help you. In fact, I suggest documentation to be even more vital to you in this instance.

As to my snark, I'm only faithfully transcribing how I figured out I was supposed to use an NSMutableString instead of an NSString. I was reading the documentation for NSString (and this was back in the NeXTStep days, so it was crap. Thanks Scott for making it a joy!) but I came across a line very similar to what's there now:

"The mutable subclass of NSString is NSMutableString."

"What on earth to they mean by mutable?" I thought. So I looked it up. And that's when it all made sense.

Note that it is highly unlikely I would have figured this out by coding alone. Sifting object dumps of NSString or whatever would not have helped (unless I noticed -mutableCopy and was able to suss out what the NSMutableCopying protocol was all about) -- esp. coming from C where the expectation is there are no string conveniences and you have to roll it all yourself.

Point being, its idiotic to say "Forget theory; ... Just set yourself a project and start working." Cocoa and, perhaps to an even greater extent, Cocoa Touch are hyper-complex frameworks that are made simple and understandable through the theory behind them. If you never learn the method to the madness -- all the patterns and best-practices behind Cocoa and why they're there -- all you will see is madness. You have very little hope of grokking iPhone development by "just doing it".

> If you're expecting a different language, framework, and platform to behave like a ruby, I would argue no amount of eschewing documentation and getting down to coding will help you.

I actually learned this lesson the hard way in the past week and basically consult the iPhone SDK and Objective-C documentation constantly. Thanks.

For example, looking at NSViewController's documentation for loadView, pointed out the fact that you should override this method if you want to do any intialization (like initialize instances of custom classes you need to handle controller interaction).

And yes - I did spend some time looking without results at NSString object dumps before stumbling on the NSMutableString tip via google (and it would have been much faster to have read the NSString documentation)

It's a common pattern in Objective-C (all of the "collections" classes are the same way), but not obvious if you've only seen NSString and not NSMutableString mentioned.