Scenario: I have a set of objects. I wish to display them using a UITableView when the device is in Portrait mode, and in UICollectionView when it is in landscape. To accomplish this, I want to use a UIViewController as a container, and give it two child view controllers (one each for the UICollectionViewController and UITableViewController). I expect the orientation to change often, resulting in the parent swapping back and forth between the two child controllers.
In the View Controller Programming Guide for iOS (2012-12-13), on pages 117 and 118 where they are talking about the transitions between children, they remove the child view controller from the parent whenever the child's view is removed from the view hierarchy. (See Listing 14-3 in particular.)
Is this necessary for memory or whatever other reasons, or is it ok to keep both child view controllers associated with the parent, and just flip back and forth between the views? Are there performance advantages to either technique?
There is no problem with having both view controllers as children, you just need to ensure that appropriate resources are either shared between them (I.e. don't have 2 copies of your objects to display) or released when the views are shown and hidden.
In your case, the two view controllers are displaying the same data, so I assume that when you switch between the two you will update the scrolled position based on what happened in the other view. If this is the case then there isn't a lot of benefit to keeping the other view controller allocated and as a child. The only thing it would save is the previously allocated cells cached inside the view. So to be most memory efficient you should remove the view controller which isn't on display. This costs a little more at runtime but should not be noticeable.