Is it advisable to add a UIViewController's view to another UIViewController's view?

Question

Is it advisable to add a UIViewController's view to another UIViewController's view?

Please explain why it is a good practice or a bad practice.

Answer 1

Apple and thus most people following Apple's guidelines will tell you it's bad practice and that Apple added ViewController containment (childViewControllers) for that reason. Unfortunately, most people blindly follow that and won't tell you why it is bad practice. And I'm glad that you do ask that.

The truth is, in a model-view-controller architecture, views should be reuseable regardless of the content they contain, thus the view and the object controlling the view's content should not be the same. Which is exactly what a UIViewController does yet prior to iOS5 Apple discouraged you to use them in multiples while it's a very logical thing to do. Ofcourse this was confusing, many people ignored the guidelines and did it anyway, myself included, apps worked fine and passed app store validation which caused even more confusion. The result is that to this day people still ask questions about this even more than a year after Apple caved and gave us custom container ViewControllers. I've seen people respond to this question often with complex answers as far as recreating UIViewController as a class that inherits from NSObject for very simple issues. Just because Apple discourages using UIViewControllers and without even knowing why.

Since adding a ViewController's view as a subview will often work perfectly and ViewController containment is not available in iOS4 which many still support, too many people don't bother using ViewController containment. It is the cleaner solution and when you feel like using ViewControllers in ViewControllers, you should use it when possible. If not, in most situations you should be able to simply add a ViewController's view as a subview, you just have to know in which situations.

Here's what you can expect if you just add a ViewController's view to another view:

• View callback methods are not guaranteed to get called. Methods like viewWillAppear, viewDidAppear, viewWillDisappear and viewDidDisappear may or may not get called. It will largely depend on the OS version, in iOS4 they won't ever get called, in iOS5 and above they'll mostly get called. So you can't override these methods because you can't rely on them, you have no control over when, if or how many times they'll get called.
• The only view callback method that will always get called correctly is viewDidLoad.
• Rotation callbacks won't get called. Depending on your situation this may be a big deal or not matter at all. If the view's autoresizingmask is enough to reposition and rescale it then you're fine. If not, you can always do a custom implementation when the superview's ViewController's rotation callbacks get called.
• You have to keep a reference to the ViewController yourself, otherwise it'll get released immediately while its view will still be retained by its superview.

I definitely wouldn't encourage it but I don't discourage it either. It's situational and if you don't have to support iOS4 anymore then you can mostly avoid it. But if you keep the above list in mind then it won't cause any harm either and your app will work fine.

Answer 2

Sometimes it's ok, and sometimes it's not. It's hard to give a better answer than that without showing some diagrams and explaining the relationship between the view controller hierarchy and the view hierarchy.

Fortunately, Apple has already done that. Watch the “Implementing UIViewController Containment” video from WWDC 2011 for a detailed explanation of when it's ok and when it's not.