UIImagePickerController has plenty of issues. One of the first to be widely discussed was its memory leak which shows itself when you try to access the PhotoLibrary on the simulator. Fortunately, this leak is limited to the Simulator and does not show up on Device. It has also apparently been fixed in iPhone OS 2.2 - though you obviously need to be aware of it if you are coding for older versions.

There is, however, another more serious problem with the image picker on device1, which shows up when repeatedly capturing images from the camera. If your application uses the camera, you have a choice. You can either hold open an instance of UIImagePickerController all the time, or you can release the controller when you are done using it, and instantiate it next time you want to use it. Surely the latter is better - you should only hold resources open when you need them.

Figure 1, above, shows the problem with that approach when we moved to the device. We experienced frequent crashes in an application that involved many image captures. We eventually narrowed the problem down to repeatedly capturing images, where the application released the UIImagePickerController after every capture. After 7 or 8 (never more) image captures, the application would either exit, or crash. The trace above shows the memory allocation spiking up during every image capture - and never dropping back down after the 7th image capture. The activity spinner froze, and the device locked up requiring a reset. The freeze occurred inside the UIImagePickerController code, not in application code. We also noted a memory leak from core code that was detected between the 3rd and 4th image capture, which is shown in the trace above

Having identified a means of reliably reproducing the crash2, and noting that it was occurring within Apple code, not our own, we tried holding open a UIImagePickerController for the lifetime of the application. We have not since experienced a crash. Airsource therefore recommends that developers using UIImagePickerController use a singleton instance over the life of the application3 rather than creating on demand and then releasing.

All tests run on an iPhone 2G 8GB running OS 2.1 (the bug has not been observed in 2.2) ↩

We validated the test by running it against a 3rd party application called Phanfare which is also dedicated to image capture. We were able to reliably cause Phanfare to crash, by taking a photo, selecting Use Photo, selecting Cancel, and then repeating. ↩

Airsource only ran the test in camera capture mode. According to a post at iPhoneDevSDK.com, the same crash can be experienced in PhotoLibrary mode, albeit with a higher threshold number of image captures. ↩