SwiftUI Animation: Composable Architecture

This is starting to show the power behind explicit animations. They allow you to be far more targeted in what you want to animate and how you want to animate.

It’s also worth noting that SwiftUI used to more heavily lean on implicit animations. For example, it used to be that if you ever made a change to the data source powering a List view then those changes would automatically animate. That would cause rows to animate into place or slide away when removed. That made for a really nice demo since you could get animation basically for free, but also meant that a lot of really strong opinions were hardcoded directly in SwiftUI’s foundational components, which seems strange. However, in iOS 14 and Xcode 12 that behavior was changed so that you had to start using explicit animations in order to animate a List view. So it appears that SwiftUI is heading more towards favoring explicit animations over implicit animations.

So, that’s the basics of SwiftUI animations. They come in two major flavors: implicit and explicit. Implicit is heavily state driven, in that whenever state changes it will automatically animate all changes to the view based on that state change. You don’t have the ability to perform animations when an event occurs, it only happens when state changes. This is why it was so hard to prevent animations when the reset button was tapped. Because that is an event and implicit animations don’t handle events well.

On the other hand, explicit animations are far more targeted and more event driven. This means that when events occur we can tell SwiftUI to animate a state change. This is why it was so easy to opt in or out of animation when the animation button was tapped.