The 8 steps are not wrong, although simplistic. Most importantly, I would reorder the list and move point 5 "Sign-up as an official developer" to the very top. Sign up, pay the money and finish the procedure for tax-withholding, if applicable. Do that from Day ONE. It looks like it takes Apple to finish the contract paperwork in days for some developers, but up to months for others. It took me 3 months, with no ETA, with 2 applications approved and me sitting there like a lame, frustrated duck.

Why it's so big, I have no idea. A few months ago it was only 1.25GB. Maybe they're including complete copies of the iPhone OS.

http://appcubby.com/blog/files/the_experiment.html

Less kool-aid, more reality.

Forget theory; forget mastering Objective C with your first attempt. Just set yourself a project and start working."

A couple days ago I stopped slogging through Kochan's Objective C book (made it to Chapter 7) and started coding. I think I was kidding myself that I could learn by reading - I think it was an indirect form of procrastination. For example, how will you ever learn that you need to use NSMutableString instead of NSString if you want to modify Strings?

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.

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".

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)

I'm a bit torn, actually. I'm making good money on the App Store with 4-5 apps, but I don't learn much making iPhone apps compared to doing other kinds of programming. So, I'm making a significant trade-off. (That said, I'm open to doing iPhone contract development, so contact me if you're interested.)

How to write an iPhone app in ONE easy step:

1. Write an iPhone app.

Just being able to bang my head on Objective-C after a day with Flex or something worse (requirements meetings) is worth it. It is something different. Yes, there is the undeniable Gold Rush mentality, and my expectations for selling an app will be realistic (e.g. sell it to someone you don't know/are related to). It's about entertaining yourself intellectually.

1. Buy a Mac

It may not be specialized to development, but it still is something special you have to buy. And it pushes your lower bound for computer price up by a lot.

B. Creation/allocation is +1, thus: +alloc (+1), -copy (+1).

C. Your goal is to keep the count balanced at 0. If you do a +1, make sure you do a -1 either now (-release) or later (-autorelease).

(C) is the guiding principle, thus in this order:

1. If you +alloc/-copy something in a function and is done with it, make sure you have a corresponding -release.

2. If you +alloc/-copy something in a function and return it, -autorelease before you return, so that counts are 0 (in the end anyway).

3. If you didn't +alloc/-copy an object, (1) and (2) don't apply. E.g. NSMutableString's +string.

4. If you -retain, make sure you -release or -autorelease to pair it up. (remember balanced to 0).

5. If you get an object from calling another function, you shouldn't -release/-autorelease it because someone else or you should have done (2). But don't forget (4).

The rest is about memory management in accessors and IB outlets.

PS: I give up on formatting this. Hope it's readable.

Also, this has a few rules you can follow: http://www.stepwise.com/Articles/Technical/2001-03-11.01.htm...

Just remember that adding elements to containers bumps their retain counts. So the following is a common pattern for me:

  MyClass *c = [[MyClass alloc] init];
  [arr addObject:c];
  [c release];

http://www.mobileorchard.com/iphone-memory-management/