Objective‑C categories omitted in release builds due to dead‑code stripping

Resolution

To prevent the linker from stripping Objective-C categories from static libraries in release builds, add the -ObjC flag to the Other Linker Flags (OTHER_LDFLAGS) of your main application target. This instructs the linker to load all Objective-C classes and categories from all linked static libraries, regardless of whether they are explicitly referenced in the code.

Explanation of Linker Behavior

In Objective-C, categories are added to classes at runtime. Because the static linker only sees references to the base class (e.g., NSString) and not the category methods, it identifies the object files containing those categories as "unreferenced" and strips them to reduce binary size during release builds.

Comparing -ObjC vs. -force_load

Depending on the size of your dependencies, you may choose between a global or selective approach:

Flag	Scope	Trade-off
-ObjC	Global (All static libs)	Simplest configuration; may increase binary size by including unused Objective-C code from all libraries.
-force_load [path]	Selective (Specific lib)	Prevents bloat from other libraries; requires maintaining absolute or relative paths to specific .a files.

Implementation Steps

1. Open your project in Xcode.
2. Select the Application Target (not the library target).
3. Navigate to Build Settings.
4. Search for Other Linker Flags.
5. Add -ObjC to the Release configuration.

Build-Time Verification

To ensure categories are present before shipping, you can verify the binary using the nm tool. Run the following command in a terminal against your release build product:

nm -arch arm64 "${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}" | grep "yourCategoryMethodName"

If the command returns no output, the category was stripped. Alternatively, enable Write Link Map File in Build Settings and search the resulting .txt file for the category's object file name to confirm it was included in the final link.

Diagnostic Note: Are you linking these categories via a static library (.a) or a dynamic framework? If using a dynamic framework, this stripping behavior typically does not occur, and the issue may lie in the framework's own internal linking.