Animation is an integral part of the technology for presenting user interfaces in both iOS and OS X. It is also considered an integral part of the user experience for these platforms. In simple terms, animation is the illusion of motion or transformation through the display of a series of images in rapid sequence, with each image differing slightly from the previous one. Although animation enhances the user experience, it is far from mere “eye candy.” Animations give users feedback or context for what is happening in the user interface. For example, in an iOS productivity application, when a user touches a row in a table view, that view typically slides out of view to the left and a new view slides in from the right to take its place; these animations visually reinforce the connection between the listed item and the detailed presentation of it. iOS and OS X automatically support many of the animations you see, but you can also create animations for other parts of your application’s user interface.
Core Animation Powers Animations in the User Interface
The main source of animation capabilities on both platforms is Core Animation. Core Animation is a high-speed, 2D layering engine with Objective-C interfaces for accessing that engine. With Core Animation, after an animation is set up, the execution of that animation is completely automatic. You don’t have to install any loops or timers, you don’t have to draw frame by frame, and you don’t have to track the current state of your animation.
The key technology of Core Animation is the layer. Layers are lightweight objects (
CALayer) that, though similar to views, are actually model objects assigned to views. They encapsulate geometry, timing, and visual properties for a view that displays content based on those factors. All you must do is set the layer content, configure the animation properties, and then let Core Animation do its part.
Animations Must Have a Target, a Type, and Timing Details
For all animations you must specify a target object: a visible object with a property that can be animated (such as its frame). You must also specify what type of animation to perform—for example, whether to move the target, resize or scale it, or fade it in or out. Finally, all animations require timing information, which can involve several factors, including duration of the animation, whether it repeats, and its pacing—that is, whether it slows down or speeds up at either the beginning or end of the animation.
Implicit Versus Explicit Animations
Every view in iOS or OS X is (or can be) backed by a layer object that optimizes compositing and animation operations for the view. Several layer-backed properties of views, including the view’s frame, color, and opacity, are inherently capable of animation. When you change their values, Core Animation animates the transition from old value to new value. These implicit animations require that you give minimal instructions to the UIKit or AppKit frameworks, but after they receive these instructions, they automatically run the animations.
Even when a view’s properties cannot be animated, you can still explicitly animate the view through those properties. For explicit animations, you must more actively manage the animation and the rendered contents using the facilities of Core Animation.
The Platforms Integrate Views and Core Animation Differently
Core Animation is integrated with the
UIView class of the UIKit framework and
NSView class of the AppKit framework, but the nature of that integration is different. A major difference is that UIKit integrates Core Animation into the heart of the view rendering implementation, whereas AppKit requires that you request Core Animation capabilities.
In UIKit, each view (
UIView object) is backed by a
CALayer object that the
UIView class automatically creates when the view is initialized. Because the layer is so closely paired with the view, you can access Core Animation through the methods and properties of the
UIView class. You can access the layer object directly through the view’s
layer property, but you cannot change the layer after the view is created.
In AppKit, the
NSView class is integrated with Core Animation and layers in two ways, both of which require explicit action on your part.
Layer-backed viewsare views that use Core Animation layers as their backing store. For this, the application must send a
setWantsLayer:message to the view with an argument of
Layer hosting. In this approach, the application sets a Core Animation layer tree that mirrors the views in a view hierarchy or some part of that hierarchy. The application must manipulate the layers directly to interact with the layer content. You request layer-hosted views by setting the view’s root layer object explicitly (
setLayer:) followed by a
The AppKit framework also supports animation proxies, which provide easy-to-use animation support that avoids the need to manipulate layer objects directly. It also offers the
NSAnimation class and its subclass
NSViewAnimation for generalized animation support and for the capability for linking multiple animations and animating multiple windows and views.