I know about the HIG (which is quite handy!), but what programming practices do you use when writing Objective-C, and more specifically when using Cocoa (or CocoaTouch).

+13  A: 

Golden Rule: If you alloc then you release!

Also if you `copy`, `mutableCopy`, `new` or `retain`.
+161  A: 

There are a few things I have started to do that I do not think are standard:

1) With the advent of properties, I no longer use "_" to prefix "private" class variables. After all, if a variable can be accessed by other classes shouldn't there be a property for it? I always disliked the "_" prefix for making code uglier, and now I can leave it out.

2) Speaking of private things, I prefer to place private method definitions within the .m file in a private category like so:

#import "MyClass.h"

@interface MyClass ()
- (void) someMethod
- (void) someOtherMethod

@implementation MyClass

Why clutter up the .h file with things outsiders should not care about? The empty () works for private categories in the .m file, and issues compile warnings if you do not implement the methods declared.

3) I have taken to putting dealloc at the top of the .m file, just below the @synthesize directives. Shouldn't what you dealloc be at the top of the list of things you want to think about in a class? That is especially true in an environment like the iPhone.

3.5) In table cells, make every element (including the cell itself) opaque for performance. That means setting the appropriate background color in everything.

3.6) When using an NSURLConnection, as a rule you may well want to implement the delegate method:

- (NSCachedURLResponse *)connection:(NSURLConnection *)connection
                  willCacheResponse:(NSCachedURLResponse *)cachedResponse
      return nil;

I find most web calls are very singular and it's more the exception than the rule you'll be wanting responses cached, especially for web service calls. Implementing the method as shown disables caching of responses.

Also of interest, are some good iPhone specific tips from Joseph Mattiello (received in an iPhone mailing list). There are more, but these were the most generally useful I thought (note that a few bits have now been slightly edited from the original to include details offered in responses):

4) Avoid doubles! The iPhone DOES NOT support ANY double-precision calculation natively. These are also emulated using libraries. Only use double precision if you have to, CoreLocation for instance. Make sure you end your constants in 'f' to make gcc store them as floats.

float val = someFloat * 2.2f;

This is mostly important when someFloat may acually be a double, you don't need the mixed-mode math, since you're losing precision in 'val' on storage. EDIT: Things have changed slightly with the 3GS, even more reason to use single precision when possible:

On the older phones supposedly calculations operate at the same speed but you can have more single precision components in registers than doubles, so for many calculations single precision will end up being faster.

5) Set your properties as nonatomic. They're atomic by default and upon synthesis, semaphore code will be created to prevent multi-threading problems. 99% of you probably don't need to worry about this and the code is much less bloated and memory efficient when set to nonatomic.

6) SQLite can be a very, very fast way to cache large data sets. A map application for instance can cache it's tiles into SQLite files. The most expensive part is disk I/O. Avoid many small writes by sending BEGIN; and COMMIT; between large blocks. We use a 2 second timer for instance that resets on each new submit. When it expires, we send COMMIT; , which causes all your writes to go in one large chunk. SQLLite stores transaction data to disk and doing this Begin/End wrapping avoids creation of many transaction files, grouping all of the transactions into one file.

Also, SQL will block your GUI if it's on your main thread. If you have a very long query, It's a good idea to store your queries as static objects, and run your SQL on a separate thread. Make sure to wrap anything that modifies the database for query strings in @synchronize() {} blocks. For short queries just leave things on the main thread for easier convenience.

More SQLLite optimization tips are here, though the document appears out of date many of the points are probably still good;

Kendall Helmstetter Gelner
Wow what a great list. Thanks for the post!
Nice tip-off about the double arithmetic.
Adam Ernst
You've made my day ) Thanks!
Class extensions are now the preferred way for private methods:
Your advice about doubles on the iPhone is out of date
Wow, I'm just getting started on iPhone dev and this is incredible!
Tejaswi Yerukalapudi
Casebash - thanks for the link, although the info was out of date with the 3Gs it appears you have even more reason to use single precision FP than ever before! I updated that section of the answer.
Kendall Helmstetter Gelner
Not out of date; entirely wrong: the original iPhone supported floats and doubles in hardware at approximately the same speed. SQLite also doesn't keep transactions in memory; they're journaled on disk. Only long queries block your UI; it's less messy to run everything in the main thread and use faster queries.
@tc: I corrected the SQL item about transactions, note that I myself did not write those last four or so items. I also clarified the part about moving queries to the background was for very long queries only (sometimes you just can't get them shorter). But to call the whole thing "wrong" because of a few points is I feel rather extreme. Also, the answer above already stated: "On the older phones supposedly calculations operate at the same speed" but note the part about the greater number of single precision registers making them still preferable.
Kendall Helmstetter Gelner
The bit about nonatomic properties is premature optimisation. It's better to leave them as default and change them to nonatomic if profiling demonstrates a significant performance improvement can be obtained.
That optimization is not premature at all. There is no benefit to leaving them atomic and in fact presents a potential danger with deadlock if you don't know what you are doing and actually use them multi-threaded. It's a common technique recommended by many experienced ObjC developers and the default on applications like Accessorizer that generate property settings.
Kendall Helmstetter Gelner
+37  A: 


Instead of:

@interface MyClass (private)
- (void) someMethod
- (void) someOtherMethod


@interface MyClass ()
- (void) someMethod
- (void) someOtherMethod

New in Objective-C 2.0.

Class extensions are described in Apple's Objc 2 Reference.

"Class extensions allow you to declare additional required API for a class in locations other than within the primary class @interface block"

So they're part of the actual class - and NOT a (private) category in addition to the class. Subtle but important difference.

You could do that but I like to label it explicitly as a "private" section (more documentation than functional) though of course that's already plenty obvious from it being located in the .m file...
Kendall Helmstetter Gelner
Except there _is_ a difference between private categories and class extensions:"Class extensions allow you to declare additional required API for a class in locations other than within the primary class @interface block, as illustrated in the following example:"See link in edit.
I agree there is a difference where the compiler will warn you when you have not implemented CE methods - but I do not find that aspect very important when all the methods are in the same file, and all private. I still prefer the maintainability aspect of marking the forward reference block private
Kendall Helmstetter Gelner
I can see arguing it's more maintainable to have the compiler keep the CE block in alignment with your code, but that seems to me to happen naturally through compiler warnings as methods change and method declarations do not. I can see others preferring CE, it's obviously meant for this use.
Kendall Helmstetter Gelner
I really don't see (Private) as any more maintainable than (). If you're that worried then a good dose of comments might help.But obviously live and let live. YMMV etc.
There is a rather important advantage to use `()` instead of `(Private)` (or some other category name): You can redeclare properties as readwrite while to the public they are only readonly. :)
+6  A: 

Clean up in dealloc.

This is one of the easiest things to forget - esp. when coding at 150mph. Always, always, always clean up your attributes/member variables in dealloc.

I like to use Objc 2 attributes - with the new dot notation - so this makes the cleanup painless. Often as simple as:

- (void)dealloc
self.someAttribute = NULL;
[super dealloc];

This will take care of the release for you and set the attribute to NULL (which I consider defensive programming - in case another method further down in dealloc accesses the member variable again - rare but could happen).

With GC turned on in 10.5, this isn't needed so much any more - but you might still need to clean up others resources you create, you can do that in the finalize method instead.

In general you should *not* use accessor methods in dealloc (or init).
When using garbage collection, you are strongly discouraged from implementing a finalize method -- you should find other opportunities to clean up resources.
Apart from performance reasons (accessors are slightly slower than direct access) why shouldn't I use accessors in dealloc or init?
(a) Performance reasons are perfectly adequate a reason in themselves (especially if your accessors are atomic). (b) You should avoid any side-effects that accessors may have. The latter is particularly an issue if your class may be subclassed.
I'll note that if you are running on the modern runtime with synthesized ivars you *must* use accessors in dealloc. A lot of modern runtime code is GC, but not all of it.
Louis Gerbarg
A more extended view on wether or not to use accessor methods/properties in `-init` and `-dealloc` methods can be found here:
Johan Kool
+31  A: 

This is subtle one but handy one. If you're passing yourself as a delegate to another object, reset that object's delegate before you dealloc.

- (void)dealloc
self.someObject.delegate = NULL;
self.someObject = NULL;
[super dealloc];

By doing this you're ensuring that no more delegate methods will get sent. As you're about to dealloc and disappear into the ether you want to make sure that nothing can send you any more messages by accident. Remember self.someObject could be retained by another object (it could be a singleton or on the autorelease pool or whatever) and until you tell it "stop sending me messages!", it thinks your just-about-to-be-dealloced object is fair game.

Getting into this habit will save you from lots of weird crashes that are a pain to debug.

The same principal applies to Key Value Observation, and NSNotifications too.


Even more defensive, change:

self.someObject.delegate = NULL;


if (self.someObject.delegate == self)
    self.someObject.delegate = NULL;
There's nothing subtle about this, the documentation clearly says that you are required to do this. From `Memory Management Programming Guide for Cocoa`:`Additional cases of weak references in Cocoa include, but are not restricted to, table data sources, outline view items, notification observers, and miscellaneous targets and delegates. In most cases, the weak-referenced object is aware of the other object’s weak reference to it, as is the case for circular references, and is responsible for notifying the other object when it deallocates.`
+16  A: 

Try to avoid what I have now decided to call Newbiecategoryaholism. When newcomers to Objective-C discover categories they often go hog wild, adding useful little categories to every class in existence ("What? i can add a method to convert a number to roman numerals to NSNumber rock on!").

Don't do this.

Your code will be more portable and easier to understand with out dozens of little category methods sprinkled on top of two dozen foundation classes.

Most of the time when you really think you need a category method to help streamline some code you'll find you never end up reusing the method.

There are other dangers too, unless you're namespacing your category methods (and who besides the utterly insane ddribin is?) there is a chance that Apple, or a plugin, or something else running in your address apce will also define the same category method with the same name with a slightly different side effect....

OK. Now that you've been warned, ignore the "don't do this part". But exercise extreme restraint.

I like your answer, my advice would by do not use a category to store utility code unless you are about to replicate some code in more than one place and the code clearly belongs with the class you are about to categorfy...
Kendall Helmstetter Gelner
I'd just like to pipe in and voice my support for namespacing category methods. It just seems like the right thing to do.
Michael Buckley
+1 if only for the roman numerals. I'd totally do that!
Brian Postow
Counter-point: For the past year and a half I've followed the exact opposite policy: "If it can be implemented in a category, do so." As a result my code is much more concise, more expressive, and easier to read than the verbose sample code that Apple provides. I've lost a total of about 10 minutes to one namespace conflict, and I've probably gained man-months from the efficiencies I've created for myself. To each their own, but I adopted this policy knowing the risks, and I'm extremely glad that I did.
+5  A: 

Also, semi-related topic (with room for more responses!):

What are those little Xcode tips & tricks you wish you knew about 2 years ago?.

+28  A: 

Write unit tests. You can test a lot of things in Cocoa that might be harder in other frameworks. For example, with UI code, you can generally verify that things are connected as they should be and trust that they'll work when used. And you can set up state & invoke delegate methods easily to test them.

You also don't have public vs. protected vs. private method visibility getting in the way of writing tests for your internals.

Chris Hanson
What test frameworks do you recommend?
Xcode includes OCUnit, an Objective-C unit testing framework, and support for running bundles of unit tests as part of your build process.
Chris Hanson
+18  A: 

Resist subclassing the world. In Cocoa a lot is done through delegation and use of the underlying runtime that in other frameworks is done through subclassing.

For example, in Java you use instances of anonymous *Listener subclasses a lot and in .NET you use your EventArgs subclasses a lot. In Cocoa, you don't do either — the target-action is used instead.

Chris Hanson
+23  A: 

Don't write Objective-C as if it were Java/C#/C++/etc.

I once saw a team used to writing J2EE web applications try to write a Cocoa desktop application. As if it was a J2EE web application. There was a lot of AbstractFooFactory and FooFactory and IFoo and Foo flying around when all they really needed was a Foo class and possibly a Fooable interface.

Part of ensuring you don't do this is truly understanding the differences in the language. For example, you don't need the abstract factory and factory classes above because Objective-C class methods are dispatched just as dynamically as instance methods, and can be overridden in subclasses.

Chris Hanson
As a Java developer who has written an abstract factory in Objective-C I find this intriguing. Would you mind explaining a little more how this works - perhaps with an example?
Do you still believe we don't need abstract factory classes after all the time that's past since you posted this answer?
+48  A: 

Use standard Cocoa naming and formatting conventions and terminology rather than whatever you're used to from another environment. There are lots of Cocoa developers out there, and when another one of them starts working with your code, it'll be much more approachable if it looks and feels similar to other Cocoa code.

Examples of what to do and what not to do:

  • Don't declare id m_something; in an object's interface and call it a member variable or field; use something or _something for its name and call it an instance variable.
  • Don't name a getter -getSomething; the proper Cocoa name is just -something.
  • Don't name a setter -something:; it should be -setSomething:
  • The method name is interspersed with the arguments and includes colons; it's -[NSObject performSelector:withObject:], not NSObject::performSelector.
  • Use inter-caps (CamelCase) in method names, parameters, variables, class names, etc. rather than underbars (underscores).
  • Class names start with an upper-case letter, variable and method names with lower-case.

Whatever else you do, don't use Win16/Win32-style Hungarian notation. Even Microsoft gave up on that with the move to the .NET platform.

Chris Hanson
I would argue, don't use setSomething:/something at all - instead use properties. At this point there are few people that really need to target Tiger (the only reason not to use properties)
Kendall Helmstetter Gelner
Properties still generate accessor methods for you, and the getter=/setter= attributes on the property let you specify the names of the methods. In addition, you can use [foo something] syntax instead of foo.something syntax with properties. So accessor naming is still relevant.
Chris Hanson
This is a great reference for someone comming from C++, where I did most of the things you advise against.
Clinton Blackmore
Sometimes it is not possible to use the standard setters/getters. I had a case where the setter had to also save something to file/database etc... So the advice still stands for handcrafted setters/getters.
John Smith
A setter should not be causing something to be saved to the database. There's a reason Core Data has a -save: method on NSManagedObjectContext, rather than have setters generate immediate updates.
Chris Hanson
it was not an option in my case. The core data method could not possibly work. Sometimes textbook advice must be overridden.
John Smith
I doubt it wasn't an option, it may have required revisiting your app architecture however. (To be clear: I'm not saying "You should have used Core Data." I'm saying "Setters shouldn't save to database.") Having a context to manage an object graph, rather than saving individual objects in it, is virtually always both possible and a better solution.
Chris Hanson
I'll just chime in here and mention that anything Chris says about Core Data should be taken as authoritative. He was one of the engineers who wrote it.
+3  A: 

I know I overlooked this when first getting into Cocoa programming.

Make sure you understand memory management responsibilities regarding NIB files. You are responsible for releasing the top-level objects in any NIB file you load. Read Apple's Documentation on the subject.

This is not true. Whether or not you are responsible for releasing top-level objects depends on what class you inherit from and what platform you are using. See amongst others.
+22  A: 

Make sure you bookmark the Debugging Magic page. This should be your first stop when banging your head against a wall while trying to find the source of a Cocoa bug.

For example, it will tell you how to find the method where you first allocated memory that later is causing crashes (like during app termination).

+10  A: 

If you're using Leopard (Mac OS X 10.5) or later, you can use the Instruments application to find and track memory leaks. After building your program in Xcode, select Run > Start with Performance Tool > Leaks.

Even if your app doesn't show any leaks, you may be keeping objects around too long. In Instruments, you can use the ObjectAlloc instrument for this. Select the ObjectAlloc instrument in your Instruments document, and bring up the instrument's detail (if it isn't already showing) by choosing View > Detail (it should have a check mark next to it). Under "Allocation Lifespan" in the ObjectAlloc detail, make sure you choose the radio button next to "Created & Still Living".

Now whenever you stop recording your application, selecting the ObjectAlloc tool will show you how many references there are to each still-living object in your application in the "# Net" column. Make sure you not only look at your own classes, but also the classes of your NIB files' top-level objects. For example, if you have no windows on the screen, and you see references to a still-living NSWindow, you may have not released it in your code.

+5  A: 

Don't forget that NSWindowController and NSViewController will release the top-level objects of the NIB files they govern.

If you manually load a NIB file, you are responsible for releasing that NIB's top-level objects when you are done with them.

+49  A: 


Historically, memory management of outlets has been poor. Current best practice is to declare outlets as properties:

@interface MyClass :NSObject {
    NSTextField *textField;
@property (nonatomic, retain) IBOutlet NSTextField *textField;

Using properties makes the memory management semantics clear; it also provides a consistent pattern if you use instance variable synthesis.

wouldn't loading of nib retain it twice then? (once in nib, second by assignment to property). Am I supposed to release those in dealloc?
You have to nil the outlets in viewDidUnload (iPhone OS 3.0+) or in a custom setView: method to avoid leaks. Obviously you should release in dealloc as well.
Frank Szczerba
Keep in mind that not everyone agrees with this style:
This is the way Apple does things too. "Beginning iPhone 3 development" mentions this change from previous versions too.
I mentioned this in another comment, but should have placed it here: Once dynamic ivar synthesis starts happening for iOS apps (if/when?), you'll be glad you put IBOutlet on the property vs. the ivar!
Joe D'Andrea
+12  A: 

Declared Properties

You should typically use the Objective-C 2 Declared Properties feature for all your properties. If they are not public, add them in a class extension. Using declared properties makes the memory management semantics immediately clear, and makes it easier for you to check your dealloc method -- if you group your property declarations together you can quickly scan them and compare with the implementation of your dealloc method.

You should think hard before not marking properties as 'nonatomic'. As The Objective C Programming Language Guide notes, properties are atomic by default, and incur considerable overhead. Moreover, simply making all your properties atomic does not make your application thread-safe. Also note, of course, that if you don't specify 'nonatomic' and implement your own accessor methods (rather than synthesising them), you must implement them in an atomic fashion.

+47  A: 

Use the LLVM/Clang Static Analyzer

You use the Clang Static Analyzer to -- unsurprisingly -- analyse your C and Objective-C code (no C++ yet) on Mac OS X 10.5. It's trivial to install and use:

  1. Download the latest version from this page.
  2. From the command-line, cd to your project directory.
  3. Execute scan-build -k -V xcodebuild.

(There are some additional constraints etc., in particular you should analyze a project in its "Debug" configuration -- see for details -- the but that's more-or-less what it boils down to.)

The analyser then produces a set of web pages for you that shows likely memory management and other basic problems that the compiler is unable to detect.

I had some trouble getting this to work until I followed these instructions:
In XCode 3.2.1 on Snow Leopard, it is already built in. You can either run it manually, using *Run -> Build and Analyze*, or you can enable it for all builds via the "Run Static Analyzer" build setting.Note that this tool presently only supports C and Objective-C, but not C++ / Objective-C++.
+46  A: 

Don't use unknown strings as format strings

When methods or functions take a format string argument, you should make sure that you have control over the content of the format string.

For example, when logging strings, it is tempting to pass the string variable as the sole argument to NSLog:

    NSString *aString = // get a string from somewhere;

The problem with this is that the string may contain characters that are interpreted as format strings. This can lead to erroneous output, crashes, and security problems. Instead, you should substitute the string variable into a format string:

    NSLog(@"aString: %@", aString);
I've been bitten by this one before.
Adam Ernst
+18  A: 

Sort strings as the user wants

When you sort strings to present to the user, you should not use the simple compare: method. Instead, you should always use localized comparison methods such as localizedCompare: or localizedCaseInsensitiveCompare:.

For more details, see Searching, Comparing, and Sorting Strings.

+34  A: 

Avoid autorelease

Since you typically(1) don't have direct control over their lifetime, autoreleased objects can persist for a comparatively long time and unnecessarily increase the memory footprint of your application. Whilst on the desktop this may be of little consequence, on more constrained platforms this can be a significant issue. On all platforms, therefore, and especially on more constrained platforms, it is considered best practice to avoid using methods that would lead to autoreleased objects and instead you are encouraged to use the alloc/init pattern.

Thus, rather than:

aVariable = [AClass convenienceMethod];

where able, you should instead use:

aVariable = [[AClass alloc] init];
// do things with aVariable
[aVariable release];

When you're writing your own methods that return a newly-created object, you can take advantage of Cocoa's naming convention to flag to the receiver that it must be released by prepending the method name with "new".

Thus, instead of:

- (MyClass *)convenienceMethod {
    MyClass *instance = [[[self alloc] init] autorelease];
    // configure instance
    return instance;

you could write:

- (MyClass *)newInstance {
    MyClass *instance = [[self alloc] init];
    // configure instance
    return instance;

Since the method name begins with "new", consumers of your API know that they're responsible for releasing the received object (see, for example, NSObjectController's newObject method).

(1) You can take control by using your own local autorelease pools. For more on this, see Autorelease Pools.

Looks like the link for "Cocoa's naming convention" has moved. Try
These autorelease bugs have bitten me many, many times in my short iPhone development career. Consciously avoiding the situations would have mitigated considerably.
I find the benefits of _not_ using autorelease outweighs its costs (i.e. more memory leak bugs). Code on the main thread should be fairly short-running anyway (or otherwise you'll freeze up the UI) and for longer-running, memory-intensive background code, you can always wrap the memory-intensive portions in local autorelease pools.
I disagree. You should use autoreleased objects whenever possible. If they increase the memory footprint by too much you should use another `NSAutoreleasePool`. But only after you confirmed that this really is an issue. Premature optimization and all that...
+10  A: 

Think about nil values

As this question notes, messages to nil are valid in Objective-C. Whilst this is frequently an advantage -- leading to cleaner and more natural code -- the feature can occasionally lead to peculiar and difficult-to-track-down bugs if you get a nil value when you weren't expecting it.

+26  A: 

Some of these have already been mentioned, but here's what I can think of off the top of my head:

  • Follow KVO naming rules. Even if you don't use KVO now, in my experience often times it's still beneficial in the future. And if you are using KVO or bindings, you need to know things are going work the way they are supposed to. This covers not just accessor methods and instance variables, but to-many relationships, validation, auto-notifying dependent keys, and so on.
  • Put private methods in a category. Not just the interface, but the implementation as well. It's good to have some distance conceptually between private and non-private methods. I include everything in my .m file.
  • Put background thread methods in a category. Same as above. I've found it's good to keep a clear conceptual barrier when you're thinking about what's on the main thread and what's not.
  • Use #pragma mark [section]. Usually I group by my own methods, each subclass's overrides, and any information or formal protocols. This makes it a lot easier to jump to exactly what I'm looking for. On the same topic, group similar methods (like a table view's delegate methods) together, don't just stick them anywhere.
  • Prefix private methods & ivars with _. I like the way it looks, and I'm less likely to use an ivar when I mean a property by accident.
  • Don't use mutator methods / properties in init & dealloc. I've never had anything bad happen because of it, but I can see the logic if you change the method to do something that depends on the state of your object.
  • Put IBOutlets in properties. I actually just read this one here, but I'm going to start doing it. Regardless of any memory benefits, it seems better stylistically (at least to me).
  • Avoid writing code you don't absolutely need. This really covers a lot of things, like making ivars when a #define will do, or caching an array instead of sorting it each time the data is needed. There's a lot I could say about this, but the bottom line is don't write code until you need it, or the profiler tells you to. It makes things a lot easier to maintain in the long run.
  • Finish what you start. Having a lot of half-finished, buggy code is the fastest way to kill a project dead. If you need a stub method that's fine, just indicate it by putting NSLog( @"stub" ) inside, or however you want to keep track of things.
Marc Charbonneau
I'd suggest that you should put private methods in a class continuation. (i.e. @interface MyClass () ... @end in your .m)
Jason Medeiros
Instead of #PRAGMA you can use a comment // Mark: [Section] which is more portable and works identically.
Unless there's a special syntax I'm missing, // Mark: does not add a label in Xcode's functions drop down menu, which is really half the reason of using it.
Marc Charbonneau
You need to use uppercase, "// MARK: ...", to get it to show up in the drop down.
In regards to `Finish what you start` you can also use `// TODO:` to mark code for completion which will show up in the drop down.
Once ivars are dynamically synthesized down the road (for iOS apps), you'll be glad you put IBOutlets in properties!
Joe D'Andrea
+8  A: 

All these comments are great, but I'm really surprised nobody mentioned Google's Objective-C Style Guide that was published a while back. I think they have done a very thorough job.

Hmm, the first example is already full of bullshit. Never document language idioms. If I'd find those kinds of comments in a header file, I wouldn't bother reading on.
Stephan Eggermont
+8  A: 

Use NSAssert and friends. I use nil as valid object all the time ... especially sending messages to nil is perfectly valid in Obj-C. However if I really want to make sure about the state of a variable, I use NSAssert and NSParameterAssert, which helps to track down problems easily.

More info here: here:
Dave Gallagher

One of the answers here states that "the most expensive part [of SQLite] is disk I/O." Normally, this is true, but on the iPhone, there is no disk. That makes the SQLite database, while not quite as fast as direct memory access, a lot faster than a disk based SQLite. Having a RAM based SQL database is a wonderful asset for persistant data - not only do you get near instant access to your data, but you can use it to push big ticket data out of your application's memory space and bring it back in really fast.

Owen Hartnett
It's still expensive on iPhone - writing to flash requires much more battery power than RAM or reading from flash. Especially wear-levelled small writes may cause multiple blocks to be needlessly rewritten.
Really? IME, slow flash is slooooooooow.
+2  A: 

The Apple-provided samples I saw treated the App delegate as a global data store, a data manager of sorts. That's wrongheaded. Create a singleton and maybe instantiate it in the App delegate, but stay away from using the App delegate as anything more than application-level event handling. I heartily second the recommendations in this blog entry. This thread tipped me off.

Have you ever heard anyone tell you that the singleton is an anti-pattern? There is a reason for this....I'm disappointed that singletons are still viewed as the answer to all ills by cocoa programmers.
-1. The singleton is definitely an anti-pattern when you decide that your app needs more than one database (sync, multiple users, ...).
+4  A: 

Turn on all GCC warnings, then turn off those that are regularly caused by Apple's headers to reduce noise.

Also run Clang static analysis frequently; you can enable it for all builds via the "Run Static Analyzer" build setting.

Write unit tests and run them with each build.

And, if you can, turn on “Treat Warnings as Errors”. Allow no warning to exist.
Peter Hosey
A handy script to setup your project with recommended warnings is available here:
Johan Kool
+3  A: 

One rather obvious one for a beginner to use: utilize XCode's auto-indentation feature for your code. Even if you are copy/pasting from another source, once you have pasted the code, you can select the entire block of code, right click on it, and then choose the option to re-indent everything within that block.

XCode will actually parse through that section and indent it based on brackets, loops, etc. It's a lot more efficient than hitting the space bar or tab key for each and every line.

You can even set Tab to indent and then do Cmd-A and Tab.
+7  A: 

Simple but oft-forgotten one. According to spec:

In general, methods in different classes that have the same selector (the same name) must also share the same return and argument types. This constraint is imposed by the compiler to allow dynamic binding.

in which case all the same named selectors, even if in different classes, will be regarded as to have identical return/argument types. Here is a simple example.

@interface FooInt:NSObject{}
-(int) print;

@implementation FooInt
-(int) print{
    return 5;

@interface FooFloat:NSObject{}
-(float) print;

@implementation FooFloat
-(float) print{
    return 3.3;

int main (int argc, const char * argv[]) {

    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];    
    id f1=[[FooFloat alloc]init];
    //prints 0, runtime considers [f1 print] to return int, as f1's type is "id" and FooInt precedes FooBar
    NSLog(@"%f",[f1 print]);

    FooFloat* f2=[[FooFloat alloc]init];
    //prints 3.3 expectedly as the static type is FooFloat
    NSLog(@"%f",[f2 print]);

    [f1 release];
    [f2 release]
    [pool drain];

    return 0;
it's an easy one to forget. Important nonetheless
Brock Woolf
This is only a concern when refraining from static typing. If the compiler knows the type, argument and return types can differ without problems. Personnaly, I find this not often to be a problem. Apple also has a lot of methods that have the same name but differ in return types. Finally, there's a compiler flag to warn you in ambiguous cases.
Nikolai Ruhe