Open Radar

 
Summary:
On iOS 9.1, when I call UIView.snapshotViewAfterScreenUpdates inside a UIView-based animation, the snapshot is erroneously displayed on-screen until the enclosing animation transaction is committed. On iPhone in landscape orientation, the duplicate layer is rotated/scaled to upside-down portrait orientation, then gradually animated in place until it is removed from screen. 

Animation blocks usually finish quickly; however, the bogus layer is often still displayed for a single frame, which, when combined with the landscape animation, leads to visible (and highly unexpected) flickering.

I expect screen contents not to change as a side effect of calling UIView.snapshotViewAfterScreenUpdates at all.

Steps to Reproduce:
1. Run the attached sample project (on device or in simulator)
2. Rotate the device to landscape orientation.
3. Press the on-screen button. The button’s action runs the following code:

UIView.animateWithDuration(1) {
    view.snapshotViewAfterScreenUpdates(true)
    sleep(1)
}

Expected Results:
The app freezes for one second with no animation.

Actual Results:
The view’s contents are duplicated; the duplicate layer is displayed squished in an upside-down portrait orientation, then slowly animated into landscape. This is entirely unexpected.

Removing the sleep(1) call does not fully eliminate the animation; often the first frame is still displayed, leading to highly annoying flickering that is quite hard to track down.

Regression:
Tested in Xcode 7.1 on iOS 9.1 (iPhone 6s device, various iPhone simulators).

Notes:
- It is not always obvious that snapshotViewAfterScreenUpdates is called inside an animation block; sometimes a caller sets up the animation further up the call stack.
- Always creating snapshots inside a UIView.performWithoutAnimation block works around the issue.