View Hierarchy and Layer Tree Relationship

Core Animation: The Engine Under the Hood

You might assume from its name that Core Animation is just for, well, animation. But its role is much broader. It is a powerful compositing engine responsible for assembling all the visual content of your app and displaying it on screen as quickly as possible.

To understand its role, let's watch a brief introduction.

As the video highlighted, even when you aren't explicitly creating an animation, Core Animation is at work, rendering everything you see. The core abstraction it uses to manage all this visual content is the layer.

Let's dig into the primary text for this lesson, which comes from the definitive book on this topic, iOS Core Animation: Advanced Techniques.

The Parallel Hierarchies: UIView and CALayer

You construct your app's UI by creating a hierarchy of UIView objects. What you may not realize is that as you build this view hierarchy, UIKit is building a parallel layer tree behind the scenes.

Every UIView has a backing CALayer instance that it manages. The view is responsible for the "what" (e.g., displaying an image, receiving a tap), while the layer is responsible for the "where and how" on screen (e.g., its position, size, and visual properties).

UIView is essentially a high-level wrapper around CALayer. This raises a key architectural question: why have two parallel hierarchies? Why not just one that does everything? The reason is a clean separation of responsibilities.

Let's read the key sections that explain this relationship.

To summarize the key points from the reading:

• UIView: Handles user interaction. It's a subclass of UIResponder and participates in the responder chain, allowing it to handle touch events and gestures. It provides a high-level, iOS-specific interface.
• CALayer: Handles all rendering, layout, and animation. It is unaware of the responder chain. It's part of the QuartzCore framework, which is shared between iOS and macOS, allowing Apple to share rendering code across platforms.

This separation is why you can do many things directly with a layer's properties that are not directly exposed on the UIView class. Some examples include:

• shadowColor, shadowOpacity, shadowOffset, shadowRadius (for drop shadows)
• borderColor, borderWidth
• cornerRadius
• 3D transforms via the transform property (which takes a CATransform3D)

The Three Trees: Model, Presentation, and Render

So far, we've discussed the layer tree that your code interacts with. This is technically called the model layer tree, because it holds the "model" values of all properties—the final state you want your views to be in.

However, to handle animations smoothly, Core Animation actually maintains two other trees. This is one of the most common sources of confusion when working with animations, and understanding it is vital.

Let's read a clear explanation from the article "Behind the scenes of UI."

Here is a summary of the three trees:

1. Model Layer Tree: This is the tree your app code interacts with. When you set myView.alpha = 0.5, you are changing a property on the model layer. It reflects the final state of your UI. You can access it via view.layer.
2. Presentation Tree: This tree contains the "in-flight" values for any running animations. If you animate a view's position from point A to point B, the model layer's position property will immediately be updated to B, but the presentation layer's position will reflect the view's current position on screen during the animation. You should only ever read from this tree, never write to it. You can access it via view.layer.presentation().
3. Render Tree: This is a private tree used by the Render Server (a separate process) to perform the actual rendering with the GPU. You cannot access this tree directly.

Have you ever seen an animation run and then abruptly snap back to its original state? This happens because you changed a property in a CAAnimation but forgot to also update the property on the model layer. The animation runs on the presentation layer, but once it completes, the presentation layer is discarded and the layer reverts to showing what's in the model layer.

Let's watch a video that demonstrates this exact problem and its solution.

Conclusion

In this lesson, we've established the foundational relationship that powers all visuals in an iOS app. By understanding this structure, you're no longer just moving views around; you're directing a sophisticated rendering engine.

Key Takeaways:

• Parallel Hierarchies: Every UIView is backed by a CALayer. Your view hierarchy for handling user interaction has a parallel layer tree for rendering and animation.
• Separation of Concerns: UIView is a UIResponder that handles touches. CALayer is a model object that manages visual properties and geometry, and its code is shared across iOS and macOS.
• The Power of Layers: To access advanced features like shadows, borders, 3D transforms, and custom-shaped layers, you interact directly with CALayer properties and subclasses.
• The Three Trees: Core Animation uses a model tree (the final state you set), a presentation tree (the in-flight state during animations), and a private render tree. For an animation to persist, you must update the model layer to match the animation's final state.

Preview of the Next Lesson:

Now that you understand the "what" and "why" of the view/layer relationship, we can start putting it into practice. In the next lesson, we will learn how to create basic property animations (position, opacity, transform) using UIView.animate(withDuration:). You'll see how this simple, high-level API is actually a convenient way to tell the underlying Core Animation engine to animate the properties of a view's backing layer.