3

We have some code in objective-c categories which we want to share between projects. There are (at least) two approaches we can take:

  1. Put them in one category per class, called something like UIView+SGBExtensions
  2. Put then in a number of different categories by use, e.g. UIView+SGBLayout, UIView+SGBDrawing, etc..

My instinct is to go with the latter, as it will be more descriptive and we can cherry-pick. However, most of our apps will include most of the shared code, so I'm a little concerned that having a lot of categories might impact performance or app size. Is there a drawback to having many objective-c categories?

Simon
  • 25,468
  • 44
  • 152
  • 266

2 Answers2

3

I think the difference would be negligible. During loading, it may involve more steps to iterate over the categories and add their methods, rather than adding methods from a single category. Likewise, if the categories have +load methods, that's several method calls rather than a single one. Like I said, negligible.

Ken Thomases
  • 88,520
  • 7
  • 116
  • 154
2

My instinct is the same as yours. Segregating the code out your way is more maintainable.

I don't think you should worry about size and performance until your application has been demonstrated to have a problem in those respects. Even then, don't assume, measure. For what it's worth, I'm pretty sure that the performance and size impact will be close to zero.

JeremyP
  • 84,577
  • 15
  • 123
  • 161