Open Radar

 
Summary:
UISplitViewController's most direct interface for its two managed child view controllers is the viewControllers property, which is readwrite. Applications generally set up two view controllers in this property for the split view controller to manage, and can in theory change them at any time.

In certain horizontally regular environments (such as an iPad in portrait orientation), the split view controller can display one view controller atop another in the "primary overlay" display mode. However, the view controller displayed in this mode disregards any calls to -setViewControllers: sent to the split view controller after its containing window has become key and visible – the original primary view controller in the split view controller will still be presented, even though the updated view controllers are correctly displayed in other situations (e.g. when rotating the iPad to landscape).

UISplitViewController should correctly update the view controller presented in its internal UIPopoverController for the primary overlay display mode when it receives -setViewControllers:, regardless of the timing of that call.

Steps to Reproduce:
1. Run the attached sample app on an iPad in portrait orientation.
2. Swipe from the left edge of the screen inward to present the primary view controller in primary overlay mode.

Expected Results:
The primary controller has a blue background (implying the new view controller installed after -makeKeyAndVisible is presented, discarding the old view controller).

Actual Results:
The primary controller has a red background (implying the old view controller installed before -makeKeyAndVisible is persisted).

Version:
iOS 8.1 (12B411)

Notes:


Configuration:
iPad Air Simulator

Attachments:
'PrimaryOverlayReplacementTest.zip' was successfully uploaded.