The Animatable Protocol
The Animatable protocol lets a custom SwiftUI view or Shape expose its state as interpolatable data, so SwiftUI can smoothly tween between values across frames instead of snapping, which is how custom shapes and progress indicators get real animation.
Why it exists
SwiftUI is a declarative framework: you describe what the UI looks like for a given state, and SwiftUI figures out how to render it, including how to animate between two states. That only works if SwiftUI has a generic way to compute what the state halfway between old and new looks like for arbitrary custom types, not just the built-in modifiers like offset or opacity. The Animatable protocol exists to give any custom view or Shape that same interpolation contract.
The mental model
Think of Animatable as handing SwiftUI a single knob instead of a finished picture. You do not tell SwiftUI how to draw each intermediate animation frame yourself, you just expose your view's state as one numeric value, or a pair of them, that supports addition, subtraction, and scaling. SwiftUI turns that knob smoothly from the old value to the new one, calling your view's body once per frame with whatever intermediate value the knob currently reads.
How it works
A conforming type implements animatableData as a computed property of some type conforming to VectorArithmetic, which itself builds on AdditiveArithmetic. When a state change triggers an animation, SwiftUI computes an interpolated animatableData value for each frame between the old and new value, sets that value on your view, and re-renders. If your shape needs more than one animatable number, AnimatablePair bundles two animatableData values, or nests further for more. Common numeric types like Double and CGFloat already conform out of the box, and Shape already refines Animatable, which is why custom shapes are the most common place to implement it.
When it matters
It matters whenever you build a custom Shape or view modifier that needs to morph smoothly, a progress ring, a custom polygon, a wave. The footgun is forgetting the conformance entirely: only the property mapped to animatableData gets interpolated, so any other stored property changes just snap instantly on the next frame, silently breaking an animation that looks fine in isolation but jumps the moment two properties change together.
A concrete example
A custom circular progress ring Shape stores a progress value of type Double. Conforming to Animatable and mapping animatableData to progress lets an animation modifier tied to that value sweep the ring smoothly from 40 percent to 75 percent over its duration, instead of the ring jumping instantly from one arc length to the other.
Interview question
A custom SwiftUI Shape has a stored property called cornerCount that changes when state updates, but the shape conforms to Animatable with animatableData mapped only to a different property, sideLength. What happens when cornerCount changes?
- a.The shape stops rendering until animatableData is updated to include cornerCount
- b.SwiftUI throws a runtime error because every stored property on an Animatable type must be included in animatableData
- c.The corner count animates smoothly alongside sideLength because both are stored properties of the same Shape
- d.The shape's corner count changes instantly on the next frame instead of animating, because only animatableData gets interpolatedCorrect
Why? this is the answer
SwiftUI only interpolates whatever is exposed through animatableData, so any other stored property, like cornerCount here, simply snaps to its new value on the next frame with no runtime error and no smooth transition. It does not crash, does not animate for free, and does not stop rendering, it just changes abruptly.
Just read this? Test yourself on what you have been reading.
Read the original → developer.apple.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles