Seven iPhone Development Rules of Thumb

I've been an Apple developer since it was called NeXT and found the following rules of thumb helpful when introducing new people to Apple development.

1. Read the introductory documentation.  Build a simple application.  Read the documentation again.

The Apple development environment is very different from other application development environments. There is going to be some ramp up time. This isn't like learning .NET after you learned Java.

Expect to throw away your first couple of applications.

2. Don't buck the system.

This is a general theme in the Apple world. If you do things the Apple way, life is pretty easy. If you try to do things the MFC/.NET/Java way... it will be very hard.

Apple heavily uses the delegate pattern. Don't fight it. Apple's view of MVC is a little odd. Adapt.

3. If it seems hard, you're probably doing it wrong.

The Apple developer forums are full of people tracking down difficult problems that are solved by simply doing it in a slightly different way. Not all of these are cases of RTFM, sometimes it's just a trick that all the experienced developers know and you just need to ask.

If something seems harder than it should, head for Google or Bing sooner rather than later!

4. Respect "Apple doesn't want you to do this".

Apple makes customization of most things easy and customization of things it doesn't really want you mucking with very hard. This has been the case since Mac OS X was NeXTStep and cell phones were the size of a brick.

Apple has stringent rules on iPhone apps. Apple wants you to do things a certain way, so just go with the program. Or develop for Android/Blackberry/Pre.

5. Understand retain, copy, release and autorelease.

Really, really understand them. You need to know at a visceral level when to retain or copy, when to release and when to autorelease.

If you run into a retain/release imbalance, stop and think about it until you understand where you went wrong. Don't just start inserting retains and releases until the problem goes away. If you really think about these every time it won't be too long before you never create them again.

6. Learn the difference between should, will and did methods.

Create a simple delegate example and log when every method is called. Read the documentation before and after you think you understand how this all works.

7. Don't ignore warnings.

Warnings are often telling you that your code doesn't do what you think it is  doing. Or that things don't work the way you think they do. 

Comments

[iPhone App Development]

Love that all point, thanks man for sharing cool steps :)

[supra shoes]

Great and very insightful posting. Awesome list of recommendations.Thanks a lot for this.Write really good, I feel so cool to see the next time you see your new article.

[www.facebook.com/profile.php?id=731555573]

I'll second that bit on Don't Ignore Warnings. And I'll add that the version of Clang Static Analyzer included in Snow Leopard as "Build and Analyze" is crucial also. While Clang can be wrong, it usually is helpful, and it can point out parts of code you haven't thought much about lately even if it's actually not a problem its highlighting. (Unused variables, misnamed functions, etc.)