Note

The names of the optional AVCapturePhotoCaptureDelegate methods didFinishProcessingPhoto and didFinishProcessingRawPhoto were changed to captureOutput:didFinishProcessingPhotoSampleBuffer:previewPhotoSampleBuffer:resolvedSettings:bracketSettings:error: and captureOutput:didFinishProcessingPhotoSampleBuffer:previewPhotoSampleBuffer:resolvedSettings:bracketSettings:error:, respectively. Code that uses the previous names (such as the WWDC version of the AVCamManual sample project) will continue to compile, but the older delegate callbacks will not execute.

Notes

• Prior to iOS 10, it was possible to override initWithArrangedSubviews:, but this was intended as a convenience initializer and implemented as such. We have now enforced this in the headers. As a result, Swift clients can no longer override this method, because Swift initializer rules prevent the override of a convenience initializer.

• In iOS 10, UIKit has updated and unified background management for UINavigationBar, UITabBar, and UIToolbar. In particular, changes to background properties of these views (such as background or shadow images, or setting the bar style) may kick off a layout pass for the bar to resolve the new background appearance.

  In particular, this means that attempts to change the background appearance of these bars inside of layoutSubviews, -[UIView updateConstraints], viewWillLayoutSubviews, viewDidLayoutSubviews, updateViewConstraints, or any other method that is called in response to layout may result in a layout loop.

  In some cases you can break these layout loops by ensuring that you always use the same object instance when objects (such as UIImage or UIColor) are required. But in general you should avoid doing this.

  Because all appearance parameters are now resolved at one time, there may be some cases where your bar's appearance has changed. In general, best results are obtained by specifying as little as possible for customizing your bar. For example, if you are specifying a barTintColor value and specifying an empty UIImage object for the backgroundImage property (as is the case when you call [UIImage new], for example) then you should get better results by specifying only the barTintColor. Any changes you make to resolve these issues in iOS 10 should also work correctly in iOS 9—if this is not the case, please report bugs with a sample project and a screenshot indicating what the bars should look like.

• In iOS 10, there is a slight UIGestureRecognizer behavior change when removing a currently recognizing (that is, midflight) gesture recognizer from its view. Previously, removing the gesture recognizer midflight would not explicitly cancel the gesture recognizer, allowing you to re-add the gesture recognizer back to the same view or to a different view. In iOS 10, calling removeGestureRecognizer: on the view of a midflight gesture recognizer explicitly cancels the gesture recognizer. If a user desires to change the view of a midflight gesture recognizer, you can simply call addGestureRecognizer: on the view you wish to move the gesture recognizer to.

• Presented view controllers can now affect the status bar appearance even if they were presented from a view controller that did not affect the status bar (for example, a popover). By default, custom view controller presentations are assumed to not affect the status bar; use the modalPresentationCapturesStatusBarAppearance property to allow a presented view controller to participate in status bar appearance.

• It has always been a requirement that UIViewController subclasses call super’s implementation of awakeFromNib from their own overrides. Starting in iOS 10, awakeFromNib is correctly annotated with the NS_REQUIRES_SUPER attribute to detect implementations that fail to obey this requirement. To fix this warning, ensure that all code paths of your override call awakeFromNib.

• When running on iPad, the background color set for a UITableViewCell in a Storyboard is now respected.

• Starting in iOS 10, UITableViewHeaderFooterView supports NSCoding so if a view with this class is in a XIB, it now decodes correctly. The consequence is that apps may exhibit some extra content for these views which did not appear before due to the bug that was fixed.

• For very wide table views where cell layout margins have been automatically increased to follow the readable width, separator insets are now interpreted relative to these left and right margins instead of from the edges of the table view.

• The coalescing of UITouch delivery has been significantly improved, especially in cases where users would both touch the screen and use Apple Pencil at the same time on iPad Pro and the app wasn’t able to process them at the incoming rate. In certain scenarios, events still can come in at a higher rate than the display refreshes. This is expected, and your app should anticipate this and handle accordingly.

• In iOS 10, windows that are not full screen do not affect status bar appearance.

• Sending layoutIfNeeded to a view is not expected to move the view, but in earlier releases, if the view had translatesAutoresizingMaskIntoConstraints set to NO, and if it was being positioned by constraints, layoutIfNeeded would move the view to match the layout engine before sending layout to the subtree.

  These changes correct this behavior, and the receiver’s position and usually its size won’t be affected by layoutIfNeeded.

  Some existing code may be relying on this incorrect behavior that is now corrected. There is no behavior change for binaries linked before iOS 10, but when building on iOS 10 you may need to correct some situations by sending -layoutIfNeeded to a superview of the translatesAutoresizingMaskIntoConstraints view that was the previous receiver, or else positioning and sizing it before (or after, depending on your desired behavior) layoutIfNeeded.

• Third party apps with custom UIView subclasses using Auto Layout that override layoutSubviews and dirty layout on self before calling super are at risk of triggering a layout feedback loop when they rebuild on iOS 10. When they are correctly sent subsequent layoutSubviews calls they must be sure to stop dirtying layout on self at some point (note that this call was skipped in release prior to iOS 10).

• Flippable images work by having two images in an asset, each with a different directionality trait. When you create a derived UIImage object using the imageWith… methods, it is no longer associated with the image asset it came from. To create a flippable template image at runtime, use UIImageAsset.

• The source of the UIContentSizeCategoryDidChangeNotification notification is now UIScreen.main() instead of UIApplication.shared().

Known Issue

For UIImage objects that are created from CIImage objects, the drawing methods drawInRect: and drawAtPoint: always convert to the DeviceRGB color space before drawing. This results in loss of extended color information when drawing into a wide-color graphics context.

Workaround: You can retrieve the underlying CIImage via the CIImage property and render it using a CIContext created with the appropriate color space (Extended sRGB) and pixel format (full-float).

A UIImage object that is created from CGImageRef is not affected, and will draw correctly without loss of color information.