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.

Answer 2

NSObject has always been, and still is, a Foundation class. It was only with this iteration of the runtime that the implementation for it was open sourced (don't ask me why, the big fruit works in mysterious ways). Your original assumption of not linking against the entirety of foundation is flawed, considering NSObject is deeply rooted in the C aspect of Objective-C and the runtime library, which are linked implicitly, and Foundation provides the root of a lot of classes that also interact with the C-side of things and the runtime. Think of Foundation as the bridge between C and ObjC, rather than an extra framework to be linked against.

NSObject, as Peter said, is still officially a foundation class, however, it was recently moved into the runtime library to allow the libDispatch/libXPC guys to focus more on the ObjC side of things (because they do use ObjC types in those libraries), instead of having to patch up Core Foundation every time they needed to add something to their respective frameworks.

(via @Catfish_Man)