Introduction

Method swizzling in Objective-C swaps the implementations of two methods at runtime using the Objective-C runtime API. While powerful for debugging, analytics, and AOP (aspect-oriented programming), it introduces serious risks: hard-to-debug crashes, undefined behavior when swizzling framework methods, ordering dependencies between swizzles, and breakage across OS updates. Apple's private implementation details can change at any time, making swizzled system methods a ticking time bomb. Prefer first-class alternatives like subclassing, delegation, and protocol extensions wherever possible.

How Swizzling Works

1#import <objc/runtime.h>
2
3@implementation UIViewController (Tracking)
4
5+ (void)load {
6    static dispatch_once_t onceToken;
7    dispatch_once(&onceToken, ^{
8        Class class = [self class];
9
10        SEL originalSelector = @selector(viewDidAppear:);
11        SEL swizzledSelector = @selector(tracked_viewDidAppear:);
12
13        Method originalMethod = class_getInstanceMethod(class, originalSelector);
14        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
15
16        BOOL didAddMethod = class_addMethod(class,
17            originalSelector,
18            method_getImplementation(swizzledMethod),
19            method_getTypeEncoding(swizzledMethod));
20
21        if (didAddMethod) {
22            class_replaceMethod(class,
23                swizzledSelector,
24                method_getImplementation(originalMethod),
25                method_getTypeEncoding(originalMethod));
26        } else {
27            method_exchangeImplementations(originalMethod, swizzledMethod);
28        }
29    });
30}
31
32- (void)tracked_viewDidAppear:(BOOL)animated {
33    // This actually calls the original viewDidAppear: (implementations are swapped)
34    [self tracked_viewDidAppear:animated];
35    NSLog(@"View appeared: %@", NSStringFromClass([self class]));
36}
37
38@end

After swizzling, calling viewDidAppear: executes tracked_viewDidAppear:, and calling tracked_viewDidAppear: executes the original viewDidAppear:. The recursive-looking call is actually calling the original.

Danger 1: Hard-to-Debug Crashes

1// If the swizzled method signature doesn't match the original,
2// arguments get corrupted silently
3- (void)tracked_viewDidAppear:(BOOL)animated {
4    [self tracked_viewDidAppear:animated];
5    // If this method's signature differs from viewDidAppear:,
6    // 'animated' may contain garbage data
7}

When a swizzled method crashes, the stack trace shows the swizzled selector name, not the original. Developers unfamiliar with the swizzle see tracked_viewDidAppear: in the crash log and cannot find it in the obvious code path. Debugging becomes a puzzle of indirection.

Danger 2: Ordering Dependencies

1// Library A swizzles viewDidAppear: in +load
2// Library B also swizzles viewDidAppear: in +load
3// The order depends on which library loads first — undefined
4
5// If A swizzles first:
6// viewDidAppear → A_tracked → original
7// Then B swizzles:
8// viewDidAppear → B_tracked → A_tracked → original
9
10// If B swizzles first:
11// viewDidAppear → A_tracked → B_tracked → original
12
13// Different behavior depending on load order!

Multiple libraries swizzling the same method create a fragile chain. If one library is removed or updated, the chain breaks, causing crashes in unrelated code.

Danger 3: Breaking Across OS Updates

1// You swizzle a UIKit internal method in iOS 17
2// Apple changes the implementation in iOS 18
3// Your swizzle either:
4// 1. Calls the old implementation that no longer exists → crash
5// 2. Passes wrong arguments to the new implementation → data corruption
6// 3. Skips critical new behavior → subtle bugs

Apple does not guarantee private implementation stability. Even public methods can have their internal behavior change in ways that break swizzled code.

Danger 4: Thread Safety Issues

1// Swizzling is NOT atomic
2// If Thread A is calling viewDidAppear: while Thread B swizzles it:
3// Thread A may call a half-swizzled method → crash or undefined behavior
4
5// Always swizzle in +load (runs on main thread before app starts)
6// and use dispatch_once to ensure single execution
7+ (void)load {
8    static dispatch_once_t onceToken;
9    dispatch_once(&onceToken, ^{
10        // Swizzle here — guaranteed to run once, before any instance methods
11    });
12}

Danger 5: Subclass Complications

1// If you swizzle a method on UIViewController,
2// and a subclass overrides that method WITHOUT calling super:
3// The swizzled behavior is silently skipped
4
5// MyViewController overrides viewDidAppear: without [super viewDidAppear:]
6// The swizzled tracking code never runs for MyViewController

Safer Alternatives

1// 1. Subclassing
2@interface TrackingViewController : UIViewController
3@end
4
5@implementation TrackingViewController
6- (void)viewDidAppear:(BOOL)animated {
7    [super viewDidAppear:animated];
8    [Analytics trackScreenView:NSStringFromClass([self class])];
9}
10@end
11
12// 2. Delegation / Protocol
13@protocol ScreenTracker <NSObject>
14- (void)trackScreenAppearance;
15@end
16
17// 3. Method forwarding with NSProxy
18// 4. KVO for property observation
19// 5. Notification Center for decoupled events

When Swizzling Is Acceptable

• Analytics/logging: Adding screen view tracking across all view controllers when you cannot modify each one
• Debugging in development: Temporarily swizzling to inspect method calls
• Testing: Swizzling to inject test doubles in legacy code without dependency injection
• Bug workarounds: Patching known Apple bugs until the next OS update fixes them

Even in these cases, document the swizzle extensively and add assertions to detect when the swizzled method's signature or behavior changes.

Common Pitfalls

• Not using dispatch_once in +load: Without dispatch_once, the swizzle may execute multiple times if the category is loaded more than once, double-swapping the methods back to their original implementations. This silently undoes the swizzle and the behavior appears to work — until it randomly does not.
• Swizzling in +initialize instead of +load: +initialize runs lazily when the class is first messaged, which may be too late or may run on a background thread. +load runs before main() on the main thread, providing a deterministic, thread-safe swizzle point.
• Forgetting class_addMethod before method_exchangeImplementations: If the class inherits the method from a superclass but does not implement it directly, method_exchangeImplementations swizzles the superclass method, affecting all subclasses. Always call class_addMethod first to ensure the method exists on the target class specifically.
• Swizzling methods with different type encodings: If the swizzled method's argument types or return type do not match the original, the runtime silently passes corrupted data. Always verify that the replacement method has the exact same signature (method_getTypeEncoding) as the original.
• Relying on swizzled Apple methods across iOS versions: Apple's internal implementations change without notice. A method you swizzled in iOS 16 may have a different call graph, different arguments, or different side effects in iOS 17. Test swizzled code against every new OS version and have a fallback plan.

Summary

• Method swizzling swaps method implementations at runtime using the Objective-C runtime
• Risks include ordering dependencies, hard-to-debug crashes, thread safety issues, and breakage across OS updates
• Always swizzle in +load with dispatch_once, never in +initialize
• Use class_addMethod before method_exchangeImplementations to avoid affecting superclasses
• Prefer subclassing, delegation, protocols, and KVO over swizzling whenever possible