I tend to agree with Joe Conway’s and Aaron Hillegass’s analysis, as reported today by Ole Begemann in http://oleb.net/blog/2012/01/initWithNibName-bundle-breaks-encapsulation/
Basically, they state that the NIB's filename is an implementation detail of the corresponding UIViewController class, and that it is not the business of the calling class to pass in the NIB's filename in the init method.
I was wondering if there was any particular reason for this design choice from the creators of AppKit/UIKit, or if it is merely a mistake — and, in the latter case, why it wasn't corrected when UIKit came out, which would have been a good opportunity.
If any Objective-C old-timer could provide the historical background to this, that would be nice to get a better understanding of the framework we use every day.
I suspect it was done this way so that a UIViewController could have basic functionality as a controller without requiring any subclassing. For example, if you're just pushing a "Credits" view on a navigation controller, and the view has nothing but static text, you could get away with not creating a UIViewController subclass. You could simply create a UIViewController directly and pass it the nib that contains your static text.
Most of the time, of course, you're going to want some level of interaction with the presented content, in which case a custom controller is necessary. But in theory, it's not always required.
It has come to my mind today that maybe Storyboards are precisely a response to that issue. Because Storyboards are defined at application-level, there is no more violation of encapsulation, merely a change of level. UIViewController subclasses become the detail implementation of the Storyboard as a whole.
It still doesn't explain the historical reasons behind the original design, but at least they have done something to address the issue — and, as often with Apple, in a very elegant way.
来源：https://stackoverflow.com/questions/8976873/uiviewcontrollers-initwithnibname-a-reason-behind-this-design