Be iOS developer, I’m pretty sure that most of you have ever heard somewhere about Swizzling. I also like to talk about this topic. Not gonna say all things about Swizzling, definition, what, why, blah blah,… Just share the main ideas, some applying in practice from my experience.
In Swift/Objective-C, it provides a kind many functions to work with metadata at runtime. 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, and this is called Swizzling
I categorize swizzling into 2 main categories: Method Swizzling and isa Swizzling:
- Method Swizzling: Basically this changes a method’s implementation. We can do swizzling on a single separated function, or on a class/instance method.
- Isa Swizzling: This way changes the body of an instance. We might apply this to a very specified instance. The instance’s interface is similar, but its instance methods 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 implementation to entire app. But the side-effect is quite big 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, it damages something accidentally. 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
From my point of view, I would not recommend applying this to something from Apple’s frameworks. Because it can damage something entirely app accidentally, and put your App at risk.
- Append a custom business logic to the existing one
So far We’ve had many many thousands methods/functions from Apple’s frameworks, 3rd parties libraries. I guess some of them are obsolete or not suiting with your application somehow at some points.
In some situations, due to the new requirement, you might have to upgrade them in several ways. Such as keep writing in the existing code, create a new subclass, add new utility methods. Belongs to that, you might have to inform others about the changes, educate them to use the new one if needed. Sometimes lacking understands the approach can screw up the app.
So using swizzling can be a better choice. Minimize code changes, minimize efforts.
Can be a good idea to apply to your will. Basically, I think of write a logging method then append it to a target function.
We also can keep it in Debug mode only by putting it in MACRO, The release build totally doesn’t contain any swizzling code
- Unit testing Framework
Writing UT is not my favorite, but on the other side, We might consider applying swizzling for Unit testing at least for injecting the mock object.
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)
Just remind you that, You can’t use Apple private classes for a serious 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 main idea of Swizzling, some applications of it. I’m not saying Swizzling is good or bad. It depends on how, when, where and what you’re gonna do. Depend on the scenarios. You shouldn’t use either 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.