Is there a limit on the amount of categories for an Objective-C Class?

Question

Is there a limit on the amount of categories for an Objective-C Class? I am making a bunch to make my class less lengthy and was just wondering if there was a limit on the amount of them you could have. Thanks.

Answer 1

There is no limit. They are an effective way of keeping long codes clean. Make sure to name them appropriately to avoid duplicates.

Answer 2

No there is not such a limit. Just try to prefix your Categories to avoid duplicates.

Answer 3

As has already been answered, no, there is no such limit, at least not that anyone here is aware of. There might be some theoretical limit, but it's unlikely that you would encounter it.

I felt I should post an answer to better answer what you asked in the comments. You wanted to know about how best to go about having different implementations for iPhone and iPad for your methods, and there are a few different options:

• You could simply have if statements in each method that executes the appropriate code depending on whether it is iPhone or iPad.

• You could have separate methods suffixed with "_iphone" or "_ipad", and then from the main methods you could call the appropriate one based on an if statement.

• You could have separate methods suffixed with "_iphone" or "_ipad", and then use method swizzling to replace the implementations of the main methods with the appropriate ones at app launch. This would reduce the overhead of the if statements every time you call a method.

If performance is critical, the last option would have the best performance, if you were calling it many many times. However the last option also requires digging into the Objective-C runtime. The first and second options both involve checking which device it is every single time a method is called. However, if performance isn't super important, the first option is easiest to set up. Also the first option would allow you to have some code in common between the two without duplicating it in separate methods, so it might be ideal if this is the case. Also many times it is nice to be able to look in one place to find all of the logic for handling a particular action, and would make things easiest if somebody else needed to maintain your code.