I have a couple third-party libraries (not using cocoapods) in my iOS project, and when I dug into the files of each, I discovered that 4 of these libraries had their own versions of the UIImage+ImageEffects
category. So I was about to merge them into one single file, but that got kind of messy:
For instance, one of the libraries, SCLAlertView, has a custom method inside its version of UIImage+ImageEffects
which refers back to one of SCLAlertView's classes to access a variable. So if I import that class into the merged file, It would make the new UIImage+ImageEffects
dependent on SCLAlertView. I dont feel comfortable about that, and its not pretty. So I need your guys thoughts on this :
What is the best approach to go about this? Should I just go ahead and merge them or keep them as separate files in their respective libraries?
Does having multiple, slightly different, versions of the same category in a project really matter? does it give rise to any issues/conflicts?
i often see this :
Class _NSZombie_OS_dispatch_group is implemented in both ?? and ?? ...
in my console. is this by any chance caused by the above thing?
Thanks in advance.
Note: I didnt give the question a generalized name like "multiple versions of same category in one project" because UIImage+ImageEffects
is used by lots of libraries for blur effects and has the most chance of ending up as multiple slightly different versions in your project
Answering 2 will drive the answer to 1 (and 3 sounds like a bug in the system, you should file it :) ):
Does having multiple, slightly different, versions of the same category in a project really matter? does it give rise to any issues/conflicts?
As long as all method names are unique, there isn't a problem outside of the issue that categories on system classes are awful for the long term maintainability of a codebase.
If, however, the categories all have methods of the same name -- which they likely do -- then only one of them will be used and which one is indeterminate.
Thus, yes, you'll need to merge them. Or, better yet, eliminate them entirely by refactoring them into a helper class or something (then file a bug against the original codebase and have 'em pull the changes).