AFAIK view controller classes should be used for managing their views, IBActions, IBOutlets and other view-screen related stuff only. This means that view controller class should be as lightweight as possible, only concerning about managing its root and inner views. However, sometimes we are tempted to leave the code inside view controller class and not to move to other custom class.
Currently, I always create custom classes for models(database tables or custom objects), parser wrappers, heavy computations and for other logic that is more or less big and might be considered as a separate class. However, very frequently, I’m leaving some relative small computations, simple checking, simple download and other small code stuff inside view controller classes, because I’m lazy (and who is not?) and I’m not comfortable with having a bunch of tiny classes just because, theoretically, some several code statements does not belong to some view controller class. I understand that those tiny classes might evolve to bigger and real classes later, during other versions of an app, but however, might not.
IMHO, if you will be very concerned about the 100% pureness and cleanness you will spend more time (well, at least during initial versions of the app), but you will never know if the product will evolve or if it will be abandoned. There’s always some trade-offs the developers are facing with.
It would be interesting to hear, what in-house rules do you use for designing your classes.
Two questions really that when/where you should do something which is whether you’ve stuck to the pattern or not.
And how
How is much less clear cut, particularly when practicality and pragmatism start getting in your face.
We tend to go for a static class for simple stuff e.g. a DateUtility class for parsing and formating dates in different formats.
And Aggregation for larger stuff, i.e. a downloader.
If you want reuse, decouple is the basic rule, so just because something was big wouldn’t necessarily mean a different class.