View source for IPhone development tips

{{lowercase title}}
*Distinction between calling [self.property release] and self.property = nil
:The latter will allow you to assign the variable later and should generally be used when you want to "clear" a variable for memory saving purposes but will have a need to assign a value to it again sometime in the future. <tt>release</tt> will completely invalidate the object and attempting to call ''anything'' on it afterwards will result in a EXC_BAD_ACCESS error every time. What does this mean in the grand scheme of things? You will most likely use <tt>release</tt> in only one place in your code – the object's <tt>dealloc</tt> method.
*Watching out for deallocation and unloading of views
:Keep in mind that if a bunch of view controllers nested one above the other, there's a bunch of unloading and deallocating happening when these views disappear (hopefully, as you should be keeping your memory usage to a minimum). In one of my view controllers, I was overfreeing controller properties because I attempted to free them inside both <tt>viewDidUnload:</tt> and <tt>dealloc</tt> methods. Just remember that a view should only be getting dealloc'ed after it's been unloaded, so you only need to free most things in <tt>viewDidUnload:</tt>.
*Passing viewWillLoad/viewDidLoad/viewWillAppear/viewDidAppear/etc methods to child view controllers
:Say you have a view controller which manages a child view controller. The child view controller's viewWillAppear and related notification methods will *not* be called automatically by the OS for you. Your parent view controller needs to call those methods manually.
*Xcode is unable to connect to your device for some reason
:Sometimes Xcode will show your phone as being connected but will be unable to initialize it for development purpose for some bizarre reason. Simply restart your phone to fix the problem.
*GPS shuts off when user locks the screen manually or the device auto-locks
:You can use <tt>[UIApplication sharedApplication].idleTimerDisabled = YES;</tt> to keep the screen on, but this is bad for the screen itself and takes a nice toll on battery life. Instead, set up an <tt>AVAudioSession</tt> with the <tt>AVAudioSessionCategoryPlayback</tt> category, then set the <tt>kAudioSessionProperty_OverrideCategoryMixWithOthers</tt> property (so that the user's iPod can keep playing) and a more aggressive I/O buffer using <tt>kAudioSessionProperty_PreferredHardwareIOBufferDuration</tt>. Then, use <tt>AVAudioPlayer</tt> to play a "recording" of total silence on endless loop for when you need to keep GPS running. <em>Note</em>: accelerometer and WiFi still shut off when the screen is locked.
:Note also that to test this properly, you *must* untether your device, as when your device is connected to power, it never enters low-power mode (WiFi and GPS stay on, even if you don't play any sound).
*Calling <tt>[[AVAudioSession sharedInstance] setPreferredIOBufferDuration:</tt> always errors, regardless of what value you use!
:See [http://stackoverflow.com/questions/1714507/recording-audio-on-iphone-error-with-setpreferrediobufferduration/2530737#2530737 my response on StackOverflow]. Basically this is a bug in the interface and you '''have''' to use the plain C method instead of the Objective-C one to get this to work.