Is NSObject class a part of the Objective-C runtime library today (instead of being a Foundation component)?

Question

Looking at the Mac OS X 10.8's version of the Objective-C runtime library source code, I noticed that it's got a NSObject.mm file. As its name suggests, it's got the NSObject class implementation, as well as built-in autorelease pool and retain count implementations.

However, versions of the ObjC runtime library prior to Mountain Lion's one didn't implement the NSObject class (they didn't have a NSObject.mm file, as you can see at the Mac OS X 10.7's Objective-C runtime library source code, for example).

So does this really mean that the NSObject class is now part of the Objective-C runtime library instead of being a Foundation library component? If yes, why? Is it to avoid one linking against the whole Foundation library (with -framework Foundation) when subclassing NSObject?

Answer 1

You can see what's part of any particular library using the nm(1) tool.

If you run this on libobjc, you'll find that NSObject is, in fact, provided by libobjc:

% nm /usr/lib/libobjc.dylib | grep -F NSObject
⋮
0000000000021688 t +[NSObject _isDeallocating]
0000000000021674 t +[NSObject _tryRetain]
0000000000021780 t +[NSObject allocWithZone:]
000000000002176e t +[NSObject alloc]
0000000000021699 t +[NSObject allowsWeakReference]
0000000000021712 t +[NSObject autorelease]
0000000000020fa6 t +[NSObject class]
000000000002115a t +[NSObject conformsToProtocol:]
00000000000217ea t +[NSObject copyWithZone:]
00000000000217e6 t +[NSObject copy]
000000000002178d t +[NSObject dealloc]
⋮

(“t” means that the symbol is provided by this library; “u” means that the symbol is undefined, meaning that this library uses it but it must come from somewhere else.)

This isn't the first time they've moved NSObject's implementation; in Lion, you'll find it in CoreFoundation.framework.

I've got no clue why they've moved it around. At any rate, it's an implementation detail; officially, NSObject is still part of Foundation.