Do not call -retainCount

Great question! A sporadic list of things I've noticed;

• Don't code your interface (don't be afraid of IB)—it's there for a reason.
• Adhere to the method name conventions ^[1]. It makes Obj-C really self-documenting.
• MVC does make everything better—ignore it at your own peril. It keeps your code clean and organized the way that goto doesn't.
• Plan out your whole project, from feature list and UI to the code organization. Otherwise, you'll quickly find yourself swamped, trying to juggle features, UI, and fixing bugs in your code. And the project will fall far behind. Yucky situation to be in.
• Make sure to use your accessors. In one of the CS193P lectures (Fall 2010—the debugging one, I think), the guy had a retain property on an ivar, but he was directly setting the ivar, and then releasing it later on. Because he didn't use his retained property, it crashed...(of course, that was done intentionally for education purposes).
• Use (and don't misuse) the pointer nature. You pass pointers around; therefore, remember that changes you make in one place percolates back to the source. Java has a lot of methods that use this (Arrays.sort, for example). This isn't so popular in Obj-C, but remember that you can still do this. Of course, this also leads to pitfalls, if you don't make a copy when you shouldn't have changed the initial value.
• Not using dot syntax: Many people hate dot syntax. I've read the articles, and to an extent, I agree. However, dot syntax really does make everything simpler—at the very least, it removes one nested method call. And the fact that it looks like you're accessing a struct member is simply because you (effectively) are accessing a struct member (in an indirect way)—classes store their ivars in structs. And for me personally, I find that dot syntax is clearer in a nested method call than using a standard method call—it makes the item seem like an actual variable (due to the lack of square brackets) than a method call. But that could just be me.
• Writing too much code. Rely on the API as much as you can—every line of code you don't have to write is one less chance for a bug. The API has been used for as much as 20 years. If there's a bug in there, chances are it would've been found already. Also, try to condense your code. Following Shipley's great advice ^[2], don't clutter your code with braces and parentheses when you don't need them. It's just something else to distract you. I prefer to nest message calls; with Objective-C's English like nature, it still keeps the code readable, but also helps with organization—I try to make each line perform one complete operation (rather than "wasting" a line declaring a temporary variable that I don't use again two lines later). But again, this is my own preference; many people will probably disagree.

Finally, make sure to use the tools that Apple provides. Once you perform a Build to test for syntax errors, also run a Build and Analyze (⌘⇧A)—it'll run the static analyzer, which will detect basic errors that you might miss, such as memory leaks, an if without an else, which may end up returning a garbage value because you don't catch every circumstance, and some subtle things like that. And of course, test your program—press every single button, with all different types of inputs. Instead of just putting in your name where it asks for your name, try putting in a period. Or a comma. Or a negative number. See what your program does. Do everything you possibly can to break your code. After all, that's what your customer will (inadvertently or not) be trying to do.

Happy coding!

A lot of developers coming from Java and C# confuse properties with the instance variables that provide their storage. This results in complaints like "Why do I have to type my members three times?" when what they're doing each time is quite different. Furthermore, a lot of such developers wind up exposing a lot more state to clients of a class than they need to, because they think they need properties everywhere.

For example, they are used to accessing instance variables by dereferencing this, e.g. this.foo = bar;. One should not blindly follow this pattern in Objective-C. When you say self.foo = bar; what you are doing is invoking the -setFoo: method, not simply changing the foo instance variable.

A common idiom among experienced Objective-C developers is to name instance variables with a prefix or suffix different from any associated property. This makes it very clear to readers of code when you're working with an instance variable compared to a property (or even a local variable). For example:

@interface TimelineViewController : NSViewController {
@private
    NSCollectionView *_timelineView;
}
@property (readwrite, retain) IBOutlet NSCollectionView *timelineView;
@end

@implementation TimelineViewController
@synthesize timelineView = _timelineView; // associate property with ivar

- (void)dealloc {
    [_timelineView release]; // use ivar, not property, in -dealloc

    [super dealloc];
}
@end

One issue I see with developers coming from other environments is use of incorrect terminology. As a Smalltalk derivative, Objective-C adheres pretty closely to the traditional terminology of object-oriented programming as defined by Smalltalk, in addition to regular C terminology:

• Classes have instance variables, not members.
• Classes have instance methods, not member functions.
• Classes have class methods, not static functions. (And class methods can be overridden in subclasses, unlike C++/Java/C# static methods.)
• Classes have an interface and an implementation.
• Protocols are what other languages refer to as "interfaces."
• Functions and structures are available exactly as they are in C.

There are also a few other oddities I've seen in the terms used by some people coming to Objective-C recently:

• A line of code terminated by a semicolon is a "statement," not a "command." (Why are people calling them commands?)
• A variable holds a reference to an object, it is not the object itself. It is thus senseless to talk of "retaining a variable" or "releasing a variable."

You can't compare NSString's with ==. This is one of the most common mistakes I've seen on SO.

Don't do this:

if (helloString == @"Hello") {

}

Do this:

if ([helloString isEqualToString:@"Hello"]) {

}

Based on the questions I've seen here and on Apple's developer forums:

• UIViews and UIViewControllers are different things and cannot be used interchangeably.
• UIViewController makes some assumptions about its use; read the class' docs and avoid trying to nest view controllers' views until you understand the consequences.
• The UIViewController lifecycle, in particular views being unloaded in response to memory warnings. This usually appears as an app losing data when the developer was counting on the view to store state.
• Not every controller needs to be a UIViewController.
• An array of dictionaries may not be the best model for your app, consider defining actual model classes which can include their own behavior.
• Pointers are not objects.
• Not all values are objects; NSInteger is not an object, you probably didn't want a 'NSInteger *'.
• Singletons and shoving extra properties onto your application delegate are probably not the best way to manage communication or share data between your view controllers.

I think that the most valuable best practice I can suggest would be to learn to write tests. Setting up a testing framework in Xcode is harder than it should be but there are some good alternatives to OCUnit and I think the "if you can't write a test for it then you don't understand it" aspect of TDD would catch most of the mistakes I've seen.

Another thing developers coming to Objective-C need to do:

Mind your history!

Objective-C is a derivative of C and Smalltalk; most of its concepts come from one or the other. It's not a language developed in complete isolation by Apple for the express purpose of iPhone development, so don't act like it is when discussing iPhone development.

In fact, if you've been working in Java (or in a Java clone like C#) most of what you've been using was explicitly derived by its creators from the features of Objective-C. There's a lot more and richer history to the language, the tools, and the platform than many developers new to it seem to give it credit for.

Another common mistake for developers used to other languages: Declaring a new class without a superclass, and assuming it will have a default superclass.

Objective-C uses single-inheritance but does support multiple root classes. Thus if you write

/* has no superclass, don't do this*/
@interface MyClass
@end

you are actually declaring a new root class rather than a subclass of NSObject.

All subclasses of NSObject must declare themselves as such, like so:

/* superclass is NSObject */
@interface MyClass : NSObject
@end

If you don't do this, the compiler will warn you that your class doesn't implement certain required methods such as -methodSignatureForSelector: and -forwardInvocation:.

Mistakes dealing with memory management are probably the most common, especially for former C/C++ programmers. Dereferencing object pointers, instead of using properties comes in at a close second.

I think that there is initially much confusion about object ownership ^[1] and why it truly matters if you name your method +newObject versus +object.

BOOL is not a “real“ boolean type, it is a typedef for a signed char, so don't compare a BOOL variable directly to YES, instead just rely on whether it is zero or non-zero:

BOOL flag = /* obtain from somewhere */;

if (flag)
{

}

Some places are guaranteed to return YES rather than just a non-zero value, for example [NSNumber boolValue] ^[1] as of Mac OS X 10.3, but not everywhere will do the same.

When subclassing an Apple framework class, avoid using the underscore prefix (Apple reserves it).

Avoid the use of the underscore character as a prefix meaning private, especially in methods. Apple reserves the use of this convention. Use by third parties could result in name-space collisions; they might unwittingly override an existing private method with one of their own, with disastrous consequences. See “Private Methods” ^[1] for suggestions on conventions to follow for private API.

(emphasis mine)

See: Coding Guidelines for Cocoa – Typographic Conventions ^[2]

You can't check the value of an int like this:

[person setName:@"Charlie"];
[person setAge:23];
NSLog(@"Name: %@ Age: %@", [person name], [person age]);

Forgetting this has caused me many a crash. Here's how to do it:

NSLog(@"Name: %@ Age: %d", [person name], [person age]);

OK, nobody has put this one explicitly, although several have alluded to it:

failure to understand and follow the Memory Management Rules ^[1]. Too many Stack Overflow questions go along the lines of:

I do this:

myIvar = [foo bar];

and it crashes, or I do this:

[self setMyIvar: [[Foo alloc] init]];

and it leaks.

Also, to reiterate Jonah's sixth point, you see this surprisingly often:

myArray = [[NSMutableArray alloc] init];
myArray = [someOtherArray mutableCopy];

along with the question "where is my leak?"

A really common error for beginners is to access fields of a struct belong to a property with the dot notation.

A common mistake I've been noticing lately is folks who declare properties and then make decidedly non-property-like implementations, rather than using @synthesize and using KVO to ripple out any desired side effects. Apple docs ^[1] tout the following as a "feature" of declared properties:

The property declaration provides a clear, explicit specification of how the accessor methods behave.

The specification implied by the declaration is only as accurate as the implementation is faithful. For instance, if you have a property like this:

@property (nonatomic, copy, readwrite) NSString* dateString;

And then you implement it like this:

@synthesize dateString;

- (NSString*)dateString
{
    if (dateString == nil)
    {
        return [[NSDate date] description];
    }

    return dateString;
}

You've broken the implied commitment that this is a thin, storage-only property with nonatomic, copy, readwrite characteristics. This may not be a big deal when working within your own products, but if you're writing class libraries for others to consume, the declaration may be all consumers have to go on, yet there's this hidden behavior.

Also dangerous is overriding property accessors/mutators in subclasses. Sometimes this is unavoidable, but it's important to try and stay true to the promises made by the initial declaration, since those are the promises that others will have in mind when they polymorphically consume your subclass instance.

Just because you release an object, doesn't mean it goes away. It just means that code won't use it again. It can still be retained by other code you passed it to, the system in a cache or shared object, or the runloop. This is why you need to tell an object you are no longer its delegate before releasing it, or you will/may crash.