Method Swizzling

What Method Swizzling Does

Method swizzling is a runtime mechanism that changes which implementation is executed when an object receives a method call. Instead of recompiling the application, the programme alters dispatch mapping in memory so a selector or method name resolves to different code. It is powerful because it can redirect behaviour dynamically, but that same flexibility makes it easy to lose predictability.

In practice, swizzling is used to intercept existing behaviour, extend it, or substitute instrumentation at runtime. That can be helpful for analytics, compatibility fixes, feature gating, and testing, but it also means the final behaviour of the application is no longer fully visible from the original source code alone.

How Method Swizzling Changes Application Behaviour

The key idea is late binding. A method call is not always tied permanently to one code path; the runtime can swap the target implementation associated with a method entry. As a result, the same call site may execute different logic depending on when and how the swizzle occurs, which object lifecycle stage it affects, and whether multiple libraries modify the same dispatch path.

That makes swizzling especially sensitive in large applications and ecosystems with plug-ins, SDKs, or multiple instrumentation layers. If two components try to alter the same method, the order of operations can determine the outcome. A swizzle can also affect inherited methods, subclasses, and framework behaviour in ways that are not obvious to the developer reading only the original class definition.

Why Developers Use It

Swizzling exists because runtime modification can solve real engineering problems without forking framework code. It can add logging, intercept network or UI events, patch framework behaviour temporarily, or adapt third-party code that is otherwise difficult to change. In mature codebases, it is often treated as a sharp tool for narrow use cases rather than a default design pattern.

The benefit is flexibility, but the trade-off is weak local reasoning. Once behaviour can be replaced dynamically, code review and static analysis explain less of the final execution path. Teams need to know not only what the source says, but also what gets rewritten by initialisation order, library loading, or framework hooks at runtime.

Security and Reliability Implications

Method swizzling can create hidden control-flow changes that matter to security, observability, and correctness. If security checks, audit logging, or validation routines are swizzled, the application may behave differently from what developers and reviewers expect. That can weaken trust in telemetry, break invariants, or make abuse harder to detect. It can also complicate debugging because the code that runs is not always the code that appears to be called.

Because swizzling changes dispatch rather than source text, it can be used legitimately for instrumentation, but it can also be abused by malicious code already running in the process. A compromised library, injected module, or unauthorised extension that can alter method resolution may redirect sensitive flows, suppress security checks, or tamper with monitoring. The risk is not the technique itself, but the power it gives to anything that can execute inside the process.

Practitioner Guidance

Why practitioners should care: Treat method swizzling as a runtime control-plane change, not a cosmetic refactor. It can alter security-relevant paths such as authentication handling, logging, and enforcement logic, so ownership and review need to be explicit.

What to watch for: Pay close attention to initialisation order, framework upgrades, and libraries that silently modify shared methods. These are the situations where behaviour drift, test flakiness, and hard-to-trace security regressions are most likely to appear.

Practitioner takeaway: Use swizzling sparingly, document every occurrence, and verify the post-load behaviour of the process rather than assuming source-level inspection is enough.

Related resources from NHI Mgmt Group

• Objective-C Method Swizzling
• When does a phishing-resistant login method still leave organisations exposed?
• What breaks if an EUDI wallet is treated like a generic login method?
• What breaks when Java auth is added without method-level authorization?