SwiftUI Series 09｜Introduction to SwiftUI Animation: Use of animation and withAnimation

SwiftUI animation is most likely to give people a “seemingly simple” feeling:

• Add .animation
• Or pack withAnimation

The page starts moving.

But in real projects, the most common problem with animation is exactly here:

• It’s moving here too.
• Things moved where they shouldn’t have moved.
• There is no animation for a certain state change
• The animation is particularly weird when the list is refreshed

This shows that many times we don’t figure it out first:

Should this animation be attached to a certain state change, or should it only wrap up a specific change process?

1. The core of SwiftUI animation is to “let state changes be interpolated and presented”

This is particularly important.

If you still use UIKit ideas to understand animation, it is easy to default to:

• I want to make a certain control move

SwiftUI is more like doing:

• When the state changes from A to B, use animation to express the change process

This means that animations naturally rely on state changes. So what really needs to be judged is:

• Which state changes deserve to be animated?
• How big should the scope of animation be?

2. The difference between .animation and withAnimation is not just the writing method, but the control granularity.

A more practical understanding is:

• .animation is more like attaching animation to certain types of state changes.
• withAnimation is more like explicitly wrapping a specific state modification

So when using .animation, it’s more like saying:

This view should have animation reactions by default for certain state changes.

And withAnimation is more like saying:

I am going to make this state change now, and I want this change to be animated.

This distinction is critical because it directly affects the controllability of the animation.

3. Many page animations will “move together inexplicably”

The most common reason is that the scope of action is not closed.

For example, I originally only wanted an expanded block to animate, but the result is:

• Other texts on the same layer also move accordingly
• The height change of the parent container causes the entire area to animate
• Some irrelevant layouts also began to transition

This is usually when the animation is attached to a state change or view hierarchy that is too large.

So when the animation is messed up, what I most often go back to check is:

• What changes is this layer currently responsible for?
• Is the animation tied to a view that is too large?
• Does the status change affect too many layout results at the same time?

4. Many “animations are not good-looking” because the state modeling is unclear.

Some animations look awkward and are:

• The state itself is not clearly designed
• One change changes too many values at the same time
• The page layout level is unstable

For example, a click triggers at the same time:

• Expand
• Copywriting switching
• Altitude changes
• List rearrangement

That ends up looking messy, often with too many different semantic changes squeezed into the same state transition.

5. When is it more suitable to use withAnimation

I prefer to use it in these scenarios:

• A user action triggers an explicit state switch
• I just want the state change to be animated this time
• I want to explicitly control “whether this change should be moved or not”

For example:

• Expand/Collapse
• Insert/delete a partial block
• Switch a certain presentation state after clicking

The advantage is that the semantics are clearer: Know that the animation is directly bound to this action.

6. When is .animation likely to be more dangerous?

.animation is particularly easy to cause the page to “move slightly everywhere” when the scope of influence of the status is not clearly thought out first.

Especially in complex layouts, if a state change affects:

• Dimensions
• Alignment
• copywriting
• Container hierarchy

Hanging the animation directly on it can easily cause the entire area to transition.

So .animation is more suitable for those:

• The scope of influence is relatively clear
• Simple semantics of state changes
• Local area stability

scene.

7. A more practical judgment: Is this animation expressing “an action” or modifying “a type of change” by default?

If you are expressing an explicit action:

• Click to open
• close
• Insert
• Delete

Then I usually consider withAnimation first.

If you are modifying a stable local state change, it is easier to consider .animation.

This judgment is very useful because it allows you not to just focus on the API name, but to truly return to the “animation semantics” itself.

8. Conclusion: What really needs to be distinguished in SwiftUI animation is the boundary of state changes and the boundary of animation effects.

To put it in shorter form, I would say:

The most important thing about SwiftUI animation is to first distinguish: whether this animation is expressing a specific action, or whether it is adding a transition effect to some type of local state change.

Once these two boundaries are clear, the animation will be more controllable; If the boundaries are unclear, the page can easily become “moving everywhere, but no one place is moving particularly right”.