CALayer

Why it exists

UIKit needs to draw pixels every frame while also handling touches, layout, and gestures. Tangling both jobs into one object would make each harder to reason about. CALayer exists to own the actual visual representation, bitmap content, transforms, and animations, so UIView can stay focused on layout and event handling and delegate all drawing to its layer.

The mental model

Picture a UIView as a stage manager and its CALayer as the painted backdrop on stage. The manager decides where things go and responds to the audience, meaning touches, but the backdrop itself, its color, shadow, and any motion, is a separate object that a stagehand crew, the render server, can move and light independently once the manager has set the scene.

How it works

Every UIView automatically creates and owns one CALayer, accessible through view.layer, and the view acts as that layer's delegate for custom drawing. Layers form a tree mirroring the view hierarchy, but extra CALayer or CAShapeLayer instances can be added directly as sublayers with no backing UIView, useful for cheap custom graphics. When a property animates, Core Animation does not update the model value synchronously, it builds a presentation layer holding interpolated values and hands the animation to a separate render server, which is why animations keep running smoothly even if the main thread briefly stalls afterward.

When it matters

Layer level control matters anywhere performance is tight: scrolling lists, custom transitions, complex visual effects. It also matters when debugging animation state, since reading layer.frame mid animation returns the final model value, not what is currently on screen, a common source of confusion. The classic footgun is setting both cornerRadius and a shadow on the same layer, since masksToBounds plus a shadow forces Core Animation to rasterize that layer offscreen every frame.

A concrete example

A chat app rounds a user avatar and adds a drop shadow directly on imageView.layer inside a table view cell. Scrolling immediately drops frames because every visible cell now triggers an offscreen render pass. The fix is splitting the two effects across two layers, clipping the image view for the corner radius while applying the shadow with an explicit shadowPath on the containing cell layer, avoiding the expensive offscreen pass entirely.