Search code examples
iosobjective-cobjective-c-category

multiple UIImage+ImageEffects files in one project


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 :

  1. 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?

  2. Does having multiple, slightly different, versions of the same category in a project really matter? does it give rise to any issues/conflicts?

  3. 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


Solution

  • 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).