Empty new Cocoa Mac OS X application has 14799 items "still living" when the application has terminated. Are they leaks?

Question

When I create a brand new Cocoa (Mac OS X) application using XCode 4.5, turning off "document based" options, and turning on "Automatic reference counting", build, without changing anything, and run using the Profiler using the "Leaks" template, I see 19.76 megs of transitory memory usage, and 2.23 megabytes in "live bytes", including 3132 CFStrings, 1371 CFBasicHash, and a few hundred odd mallocs(), including 192 kb still allocated by CoreGraphics even when the program has terminated. I see all this in the "Allocations" timeline, but no output in the "Leaks" timeline. I find this disparity confusing.

I would like to know, for example, with a simple Cocoa base reference application, if possible, and if not, then I would like to know what the reference technique is to know which leaks are mine, and which are expected.

Note that with a Foundation-framework linked command line tool, the number of "out of the box leaks" is much simpler, only about 18 mallocs(), totalling 1.06 kb, so it seems that AppKit (Cocoa) is the origin of most of the default "live objects still on the heap at the end of the program, that are somehow, not leaks".

Is there some way to make a simple non-leaking Cocoa base reference application or does the framework itself leak so much (perhaps intentionally) that in fact, this is impossible?

Yes, I am aware of static analysis. Yes, I am aware of garbage collection. If someone wants to not use garbage collection, but only ARC, and wants to really see at runtime what has leaked, can that person do so, without having to ignore 14799 or so leaks in the foundation and frameworks?

Update: Source #1 of my own confusion is, as suggested, that I'm looking at the wrong timeline... However, in my own defense (or to explain my confusion), I have always considered any object which is still allocated on the heap at the end of program execution as a leak, a rule which is commonly observed in the Pascal (Delphi) and C++ world, and indeed on most non-garbage-collected languages on Linux and Windows. Maybe that's not a "leak" in the Objective-C world at all? Is a "living item" in the memory timeline still "active on the heap", and how is that different from a leak? The fact that my AppController is never told to "dealloc" was surprising to me too, but is "to be expected", I'm told.

Answer 1

Those look like objects that are "Created and still living." These are NOT leaks, but simply objects that have not finished their life cycle. Since the application is still running, there will always be a set of objects that are still living, but still have pointers to them.

A leak is an object that still lives, but has no pointers to it. Without a pointer, you cannot return that portion of memory to the OS.

To see actual leaks, look at the Leaks timeline in the upper portion of Instruments. When a leak occurs, you will see a red bar in this timeline. Set the inspection range around this bar to view details about the leak below