Rather than wait till the end to use Instruments to determine how many leaks you have I suggest that you build and tune/test your app in pieces. The current app we’re working on has tons of views and is very interconnected between the views. The next app I make will have some solid glue code, and the various views will be much more disposable. This will allow me to bring down the high watermark for memory, and also allow me to develop the app more carefully by tuning/testing each view at a time to make sure it has no leaks and no memory issues before moving on to the next thing. If you wait till the end it’s very difficult to figure out what’s going on in Instruments just because there’s SO much going on at once. It’s very difficult to filter out the “noise” of allocations that are OK from the bad allocations.
This is all common sense, and I’m sure when you read it you’re saying to yourself “Well duh. Retard.” Well, you get crunched for time and your good intentions slip away. So what I’m advising here is no matter how tempting it is to save time by cramming it in, you will save time by doing it right. I’ve learned now that this applies to all things Cocoa programming. If you don’t do things the “right” way, it’s very difficult to code your way out of the binds you get yourself into. Take the time to plan out your classes, your program’s flow and data model. No matter how much you hate it I promise it’s worth it.
