As an iOS developer, I’m pretty sure that most of you have ever sometimes heard about Swizzling. I gonna talk about this. Not gonna say all things about Swizzling, definition, what, why, blah blah,… Just share the main ideas, some uses in practice from my experience.
In Swift/Objective-C, the language provides some tools to work with metadata at runtime. Hence you’re able to retrieve metadata from any classes, objects, properties, methods, method’s implementations, and frameworks at your will. We are able to alternate the metadata, change their values. We also able to swap something for another one. It is method swizzling.
I categorize swizzling into 2 main categories: Method Swizzling and isa Swizzling:
- Method Swizzling: Basically this swaps a method’s implementation to another one. We can do swizzling on a separated function, or on a class/instance method.
- Isa Swizzling: This swaps the bodies of 2 instances. The instances’ interface should be similar. Its instance methods’ body can be alternated at your will.
Doing Method swizzling on a class/instance method will result in impacting entirely app.
It could be useful in some cases which you need to apply your custom business logic to the entire app. But the side-effect is potential if you do wrong.
For example, We swizzle the present method of UIViewController to do something. Because UIViewController has been used in most of the frameworks, library and even the developing app, it would definitely impact all those stuff. Some cases, the app works unexpectedly. If you aren’t aware of what you’re gonna do, you screw it up.
In my experience, I’m listing out some applying with swizzling:
- Replace the existing business logic
But I would not recommend applying the technique to Apple’s frameworks. Because the change affects globally. It can put your App at risk.
- Append a custom business logic to the existing one
There are thousands methods/functions from Apple’s frameworks. There are some external 3rd-party libraries required to use.
I pretend that some of them are obsolete or not accommodating with your application somehow at some points, and due to the distinct requirement, We have to change the way it works. The habitually way We do is create a subclass, override the base’s methods, add up the new logic, sometimes invent new functions. According to the change, you might have to talk to others about the changes, tutor them to use the new one to avoid doing wrong. Therefore doing swizzling can be a better choice. The code change is minimal.
It’s good to apply at your will. We can do something like measure code execution length, embed debug log into some certain methods.
Keep the code it in MACRO if needed. The release build be totally clean since no swizzling code included in there
- Unit testing Framework
Writing UT can benefit the app, improve the code quality and reliability. We can apply the swizzling technique for Unit testing, at least for injecting the mock object. An instance of these would be OC Mock framework.
I have seen some genius guys in Raywenderlich do some interesting things with Apple private classes, and Swizzling must help them a lot. (Learn more)
(Keep in mind that You can’t use Apple private classes, methods for an app which you’re going to release in App Store)
Those are some applying for swizzling which I have learned so far. Hopefully, this information can be a helpful resource for you guys.
Keep that in mind, I’m just sharing the principal idea of Swizzling, some uses of it. I’m not saying Swizzling is good or bad. It depends on how, when, where and what you’re gonna do. Depending on the scenarios. You shouldn’t use any of them if you don’t know their side effect. Because it could result in App failure, rejected.
I keep doing some posts on swizzling next time. Please subscribe, share and contribute your idea if possible. Any feedbacks are welcome.
(Recently updated on Jul 05, 2018)