The first versions of my classes where filled with sprawling methods and definitions for anything that class implemented. Maintaining it was hell. All of my methods were getting lost. They were organized by #pragma marks, but the .m file was just to big. A lot of my methods would be half commented out with new functionality I would think of adding at one point but change my mind halfway through. It was way too much mental overhead.
I rewrote the code to have a view subclass that did the basic layout and management of my subviews (some of which were also custom views.) I kept the functionality really small and started subclassing my custom view for additional functionalities. I ended up with stuff like MenuedCustomView, OverlayCustomView, GradientCustomView. This was a huge improvement.
First, I could go back to the base sub class and really refine it's respoinsibilities and make it super tightly architected. Second, testing out new functionality was easy and clean. I would make a subclass add the functionality, then change a #define symbol in my controller to, say, TestCustomView or back to GradientCustomView or whatever. This Class swapping was a tiny bit unwieldy, but certainly worked better than when I was just working in the same class definition, adding functionality, trying them, reverting them, all in the same .m file. I have subclasses that have stubs of additional functionality I would like to add in the future, I'm just not including them in my Controller class. When I feel like working no them it's super easy to add to my project.
A little bit after I started subclassing everything I learned that this maybe isn't always the best practice in Objective-C and cocoa. I switched to adding categories for a lot of additional functionality I wanted to add to a class. Of course categories only add methods and not properties, so some of the functionality I was adding was only possible in a subclass. Now, I've now got a mixture of subclasses and categories to define my objects in a mostly manageable and easy to read/maintain file/class hierarchy.
I've wondered how Apple maintains a class like NSString. Is it one large .m file? Do they have a bunch of ProtoString classes that each add separate functionality and then they inherit them into the one NSString class? Or is it a base set of functions and then a bunch of categories?
I've still got a bunch to learn on the high level architecture of a good cocoa app, just thought I'd share my progression.