Animation Basics for Your iOS App

By Jesse Feiler

Fortunately, most of what you need to do as far as iOS animation is concerned is already built into the framework. Some view properties can be animated, which means that you just need to tell the view where to start and where to end its move, and a few other optional parameters, and you’re done. The view itself (in the UIVIew base class) has the functionality to animate the move.

To give you some context in which to understand how animation on the iPhone and iPad works, however, you need to understand what goes on under the hood when a framework takes care of the animation chores for you. More specifically, you need to delve a bit deeper into views, their properties, and the coordinate systems on the iPad.

View geometry and coordinate systems

The default coordinate system in UIKit places its origin in the top-left corner and has axes that extend down and to the right from the origin point. Coordinate values are represented using floating-point numbers, and you don’t have to worry about the screen resolution; the frameworks take care of that automatically.

In addition to the screen coordinate system, views define their own local coordinate systems that allow you to specify coordinates relative to the view instead of relative to the screen. In practice, you often do both depending on what you’re trying to do.

Because every view and window defines its own local coordinate system, whenever you’re drawing or dealing with coordinates, you’ll need to pay attention to which coordinate system you’re using. That sounds ominous, but it’s really not that big a deal after you get into the rhythm of working with the coordinate systems.

Points versus pixels

Okay, so where does the high-resolution Retina display come in?

All coordinate values and distances are specified using floating-point values in units referred to as points. The main thing to understand about points is that they provide a fixed frame of reference for drawing. That fixed frame of reference is derived from the fact that a point is 1/72 of an inch. (This was set for the original Macintosh and LaserWriter. A point is a commonly accepted unit of length.)

The original Macintosh had a screen resolution of 72 pixels per inch (PPI). This meant that points and pixels were identical. However, over time, technology has advanced and now the pixel size and density (PPI) have changed. No longer do most devices actually have 72 PPI, but because pixels and points have been used interchangeably, the arrival of high-density displays such as the Retina display has caused confusion.

When you are talking about size or location, you are probably talking in points. If you are talking about the resolution of the image you will place on an object with a certain size or location, you are probably talking in pixels. On a Retina display, your image will have twice the pixels that you have on a non-Retina display, and you probably use a separate .png file.

Keep this distinction in mind, particularly when you are looking at old (pre-2013) documentation. You have to sort out when “pixel” means pixel and when it means point. Some developers use as a basic rule of thumb, “Xcode=points and Photoshop=pixels.” That’s a generalization and it’s not true in all cases, but as generalizations go, it’s generally right.

A view’s size and position

A view object’s location in a coordinate system is determined using either its frame or its center property:

  • The frame property contains the frame rectangle, which specifies the size and location of the view in its superview’s coordinate system.

  • The center property contains the known center point of the view in its superview’s coordinate system.

In your wanderings, you may someday encounter the bounds property. It’s tied up with the bounds rectangle, which specifies the size of the view (and its content origin) in the view’s own local coordinate system.

The view coordinates you set for your view’s location in Interface Builder are in points. The coordinates start from 0,0 in the top left and increase as you go down and to the right. You usually place your objects below the 20-point status bar, but with iOS 7, views can appear through a navigation or toolbar, so you may place them even lower if you don’t want them showing through.

Working with data structures

In addition to knowing what goes where, you’ll need to understand how data structures impact how you work with views.

The frame is a CGRect — a struct (a C language type that aggregates conceptually related variables into a single type) with an origin and a size that are comprised of CGPoints. CG here stands for Core Graphics, one of the frameworks included by the Xcode when you selected the Single-View Application template. The following code shows the CGRect struct:

struct CGRect {
 CGPoint origin;
 CGSize size;
};

An origin is a CGPoint with an x and y value, and a CGSize is a CGPoint with a width and height value. The following code shows the CGPoint struct:

struct CGPoint {
 CGFloat x;
 CGFloat y;
};
struct CGSize {
 CGFloat width;
 CGFloat height;
};

Similarly, the center property is a CGPoint. And that’s all you need to know about the data structures you’ll be using.