iOS 7: Custom Transitions

Written by: on September 18, 2013

Another “OMG Finally!” type of iOS 7 feature is the ability to create custom transitions between view controllers. Prior to iOS 7, creating custom transition animations between screens required a lot of deep customization. This was never impossible, and it certainly became easier with the addition of things like sub-view controllers in iOS 5, but this new API is going to save a lot of developers a lot of time, and create a lot of potential for great new user interactions.

Before diving in, let’s talk about what these view controller transitions actually look like. The most basic example is the new animation when moving forward and backward in a navigation stack. Whenever you “pop” a view controller from the stack, for example, you get a slightly parallactic animation where the top view slides away and the last view slides in. This is more complex than the pre-iOS 7 animation, but another major difference between this animation and it’s predecessor is that if you pan your finger from the left edge of the screen, the transition animation will track your finger. This concept of an interactive transition is also part of the new API. Collection views have their own take on transitions in the form of layout-to-layout transitions, as seen in the Photos and Calendar apps. These new transitions add a lot of depth the the UI, and give the user an even stronger sense of “place”.

Let’s get acquainted with the new concepts that surround transitions with a basic example. We’re going to implement a simplified form of the iOS 7 homescreen-to-app zoom.

Protocols All the Way Down

In order to give developers freedom to implement animations how they see fit, the view controller transitioning API uses a lot of protocols. You define an object that conforms to the UIViewControllerTransitioningDelegate protocol, and then provide that object as the transition delegate for an incoming view controller. It then provides an transitioning object that conforms to UIViewControllerAnimatedTransitioning (or UIViewControllerInteractiveTransitioning) when asked. That transitioning object will be handed a context object that conforms to UIViewControllerContextTransitioning during an animation. That context object holds all the objects and information involved in the transition. Got all that?

Let’s start with the view controller’s code. Here’s the basic flow for presenting a view controller with a custom transition (for the sake of brevity, just imagine this is occurring in response to some user interaction):

The View Controller

That’s simple enough, so let’s take a look at the implementation of DETransitioningDelegate:

The Delegate

That’s about as simple as it gets. When the view controller is presented, the delegate will be asked for a transitioning object using -animationControllerForPresentedController:presentingController:sourceController. When it’s being dismissed, the delegate will receive -animationControllerForDismissedController:. We could inspect the passed-in view controllers and use their state to infer what type of transition to use. In this case, we’re always using the same transition class, but you’ll notice that in the dismissal, we’re configuring it a little by setting reverse to YES.

So now for the important part. Here’s the implementation of DEAnimatedTransitioning:

The Transitioning

That’s it. These are the two primary methods that have to be implemented for a basic custom transition. The transitionDuration: method is used to help set up the context, and animateTransition: is used to set up, animate, and complete the transition itself. Note the use of the reverse property to determine which direction the animation should go. This allows us to use this same class for both in and out transitions.

The most critical part of this code is the call to the transitionContext’s completeTransition: method. Without this call in the completion block (or wherever your transition ends), the app would hang in this transition state forever.

That transitionContext is kind of like the transition’s model object. It contains all the info and objects you need to complete the transition, including the container view and pointers to the incoming and outgoing view controllers. You can customize this object itself to create your own containment view controllers, but for a transition like this, that’s not necessary.

More Than a Mere Modal

This simple example focuses on modal presentations. The transitioning API would be kind of a bummer if that were the only transition you could customize. Thankfully, each of the base container view controllers has it’s own means of setting the animation controller. The UITabBarControllerDelegate and UINavigationControllerDelegate protocols have been extended with methods to provide both animated and interactive transitioning controllers.

And there’s more. So much more. The above example only shows how to make the simplest of animated transitions. The transitioning API is much deeper, with interactive transitions, layout-to-layout transitions for collection views, and more. We’ve just started scratching the surface here, so look forward to more on transitions soon.

This is the second in an 11-part Developer’s Guide to iOS 7. You can find the full guide here. For more information on how Double Encore can help you prepare your company for the changes in iOS 7, please email us.

Bradford Dillon

Bradford Dillon

Bradford Dillon is a Senior Technical Architect at POSSIBLE Mobile. He’s been building apps for iOS and other touchscreen interfaces for the last ten years, and enjoys writing code that makes writing code more enjoyable. In his spare time he builds skills that are primarily suited to entertaining his kids.

Add your voice to the discussion: