Understanding the Objective‑C Class Loading Process in dyld and the objc Runtime

Before analyzing the class‑loading process, we first review the overall application launch sequence. After the kernel boots the app, the executable is read, the dynamic linker (dyld) is located, and dyld initializes the environment, loads binary images, resolves dependent libraries, and finally invokes the runtime initialization before calling main() .

During this phase dyld and the Objective‑C runtime cooperate: dyld registers a callback _dyld_objc_notify_register which the runtime uses to receive notifications when images are mapped, initialized, or unmapped.

_objc_init is the entry point of the runtime. Its key steps are shown below:

void _objc_init(void) {
static bool initialized = false;
if (initialized) return;
initialized = true;
// fixme defer initialization until an objc‑using image is found?
environ_init();   // initialize environment variables
tls_init();       // set up thread‑local storage
static_init();   // run C++ static constructors
lock_init();      // no‑op placeholder
exception_init(); // set up libobjc exception handling
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
}

environ_init reads environment variables that affect the runtime, while tls_init prepares thread‑key bindings, and static_init executes C++ static constructors before any Objective‑C +load methods run.

exception_init installs a custom terminate handler that forwards Objective‑C exceptions to the Foundation handler.

The callback registration function _dyld_objc_notify_register stores three function pointers ( _dyld_objc_notify_mapped , _dyld_objc_notify_init , _dyld_objc_notify_unmapped ) in static variables and invokes them at appropriate moments during image processing.

map_images is called by dyld when an image is mapped. It acquires the runtime lock and forwards to map_images_nolock , which eventually calls _read_images to process class tables, selectors, protocols, and other metadata.

Inside _read_images the following major steps occur:

**Done‑once initialization** – creates hash tables for named classes ( gdb_objc_realized_classes ) and allocated classes ( allocatedClasses ).

**Class remapping** – iterates over each class reference, calls readClass , and updates tables via addNamedClass and addClassTableEntry .

**Selector fixing** – registers selector names with sel_registerNameNoLock while holding selLock .

**Protocol handling** – discovers protocols, adds them to the protocol map, and remaps protocol references.

**+load method processing** – load_images is invoked for each image that contains +load methods; it prepares and calls those methods after acquiring the necessary locks.

Key helper functions are shown in the original source snippets, for example:

static void addNamedClass(Class cls, const char *name, Class replacing = nil) {
runtimeLock.assertLocked();
if ((old = getClass(name)) && old != replacing) {
inform_duplicate(name, old, cls);
addNonMetaClass(cls);
} else {
NXMapInsert(gdb_objc_realized_classes, name, cls);
}
}

After all images are processed, the runtime has fully realized non‑lazy classes, fixed selector and protocol references, and executed all +load methods, ensuring the application’s Objective‑C environment is ready before main() runs.

The article concludes that understanding this launch and class‑loading pipeline can help developers optimize startup performance and debug early‑initialization issues.