I have quite a large app out on the app store called Ambiance and have been developing it off and on for about two and a half years now. In the beginning, I used to run Instruments religiously to ensure not one memory leak got through the cracks, it was my obsession. I simply would not ship if I had a memory leak at all. At one point, I even hired a guy to help me find and fix memory related issues. That first version of Ambiance, a simple UIPicker app, was able to be scrubbed in less than an hour. Each iteration started increasing the time it took to fully squash memory leaks, culminating in a more recent version of Ambiance taking a full week to locate them all.
Well, I am hereby announcing that I will no longer be eliminating all leaks from my apps. Before you label me as and evil developer let me explain. I will still be hunting down the leaks I consider to be important. These include the large (in size) leaks, the leaks that are only a few bytes but are in the thousands and the easy leaks found by “Build and Analyze”. What I will not be tracking down are the more obscure leaks, the small one-time leaks that I cant find within a few minutes, the Apple framework leaks that I can’t do anything about anyway.
So why am I doing this? Modern devices are not really RAM limited. I know that is subjective, but as devices evolve, the RAM is increasing with it. This growing available RAM is increasing much faster than my apps’ memory needs. Thus, the need to eliminate each and every minute leak is unnecessary and a waste of time. There are not too many iPhone 1G’s hitting my server anymore.
As mentioned in the opening paragraph, each of these leak cycles takes a considerable amount of time. It is not that I write bad code — it is that I don’t write perfect code and you probably don’t either. Maybe somewhere along the line I added a retain somewhere where I was supposed to autorelease. Maybe somewhere along the line I have a retain cycle. I can say that even though I am not a perfect-code robot, i do write good code and most of the time, I do the right thing when it comes to properly eliminating the source of leaks. The leaks that slip through the cracks are usually obscure and not triggered very often, if at all. Instead of taking the multiple hours to track down these minor leaks, I am now leaving them in as it is just not worth my time to hunt them down.
What does this mean? Well, this decision might affect a small population of you heavily: The customer who is using an older, dusty device and also never reboots their device. Based on my App Analytics, this is a very, very small population and really is not worth the weeks per year tracking down these minute issues. The bottom line is that my apps now ship with minor leaks in them. So do many of the other apps you use on your device. I think that in the end, you (the customer) will care more about the extra time I was able to spend perfecting new features and working on new apps than the invisible, minute leaks my app leaves behind.