Question about view/controller/nib class design

Question

Assume you need to make an application with, let's say, 15 different views in total. There are two extreme design choices you can use to implement the app:
1) Every single view has its own view controller and a nib file. Thus you end up with 15 controller classes and 15 nib files (and possibly a bunch of view classes if any of your views needs to be somehow specialized).
2) You have only one controller which manages all the views, and one nib file from which they are loaded.
AFAIK Apple and many books recommend going purely with option #1. However, going with this often results in needless complexity, large amounts of classes (and nib files) to be managed and complicated class dependencies, especially if some of the views (and thus their controllers) interact with each other or share something (something which would be greatly simplified if all these related views were handled by one single controller class).
Option #2 also usually ends up being very complex. The major problem is that the single controller will often end up being enormous, handling tons of different (and usually unrelated) things (which is just outright bad design). This is seldom a good design, unless your application consists of only a few views which are closely related to each other (and thus it makes sense for one single controller class to handle them).
(Option #2 also breaks the strictest interpretation of the MVC pattern, but that's not really something I'm concerned about. I'm concerned about simple design, not about following a programming pattern to the letter.)
A design somewhere in between the two extremes often seems to be the best approach. However, since I don't have decades of Cocoa programming experience, I would like to hear some opinions about this subject matter from people with more experience on that subject. (I do have object-oriented programming experience, but I have only relatively recently started programming for the iPhone and thus Cocoa and its design patterns are relatively new to me, so I'm still learning.)

Answer 1

Somehow I get the feeling that my question was slightly misunderstood.
I was not asking "which one of these two designs do you think is better, option #1 or option #2?" I already said in my original post that option #2 is bad design (unless your application consists of just one or two views). That's not the issue.
The issue is that from my own experience trying to adhere very strictly to the "every single view must have its own view controller and nib file" often results in needless complexity. Of course this is not always the case, but sometimes you end up having controller classes which perform very similar, if not even the exact same actions, resulting in code repetition. (An OO'ish solution to this problem would be to have a common base class for these view controllers where the common functionality has been grouped, but this often just adds to the overall complexity of the class hierarchy rather than alleviating it.)
As an example, let's assume that you have a set of help screens (for example one help screen for each major feature of the app) and a view where you can select which help view to show. Every one of these views has, for example, a button to immediately exit the help system. If you had one single controller class managing these views, this becomes simpler: The controller can switch between any of the views and the buttons of each view (most of them doing the same things) can call back actions on this controller (eg. to return to the help selection or to exit the help screen completely). These help screens don't necessarily have any functionality of their own, so it's questionable what do they would need view controllers of their own. These view controllers would basically be empty because there's nothing special for them to do.
View controllers might make it easy to use the navigation controller class, but the navigation controller is suitable mainly for utility apps but often not for things like games. (And if you need animated transitions between views, that can be implemented using the UIView animation features.)
I also have hard time seeing the advantages of adhering strictly to the MVC pattern. The MVC pattern is useful in things like web servers, where MVC adds flexibility. The controller acts as a mediator between the database and the user interface, and it does so in such an abstract way that either one can be easily changed (eg. the "view", which normally outputs HTML, could be easily changed to a different "view" which outputs a PDF or even plain text, all this without having to touch the controller or the model at all). However, I'm not seeing the advantages of the MVC pattern in an iPhone app. It provides a type of class design, but why is it better than some other class design? It's not like the input and output formats of the app need to be changed on the fly (which is one advantage of a well-designed program using the MVC pattern).