ios-animation-implementation（iOS animation 实现）

iOS Animation Implementation

Write animation code that uses Apple's frameworks directly. Third-party animation libraries add dependency risk and often lag behind new OS releases — Apple's APIs are well-optimized for the render pipeline and get free improvements with each iOS version.

Before Writing Custom Animation

Check whether the system already handles the motion you need. Apple's HIG: "Many system components automatically include motion, letting you offer familiar and consistent experiences throughout your app." System components also automatically adjust for accessibility settings and input methods — Liquid Glass (iOS 26) responds with greater emphasis to direct touch and produces subdued effects for trackpad. Custom animation can't match this adaptiveness for free, so prefer system-provided motion when it exists.

Skip custom animation when:

• Standard navigation transitions cover your case (push, pop, sheet, fullScreenCover)
• SF Symbol .symbolEffect provides the feedback you need
• .contentTransition(.numericText) handles your data change
• The system's default spring on withAnimation is sufficient

Write custom animation when:

• The system doesn't provide the spatial relationship you need (hero transitions, custom gestures)
• You need coordinated multi-property choreography
• The animation is a signature moment that defines the app's identity
• Gesture-driven interaction requires custom progress mapping

API Selection

Choose the right API for the job. Start with SwiftUI animations (simplest, most declarative), drop to UIKit when you need interactive control, and reach for Core Animation only when you need layer-level precision.

Implementation by Category

Detailed patterns and code examples live in the reference files. Load the one that matches your task:

When to Load References

• Writing withAnimation, spring parameters, PhaseAnimator, or KeyframeAnimator → swiftui-animations.md
• Building navigation transitions, modal presentations, matchedGeometryEffect, or custom Transition → transitions.md
• Implementing drag-to-dismiss, swipe actions, pinch/rotate, or scroll-linked effects → gesture-animations.md
• Working with CABasicAnimation, UIViewPropertyAnimator, layer animations, or bridging SwiftUI↔UIKit → core-animation.md

Spring Parameters Quick Reference

Springs are the default animation type in modern SwiftUI. Use duration and bounce — not mass/stiffness/damping unless bridging to UIKit/CA.

Accessibility & Multimodal Feedback

Apple's HIG: "Make motion optional" and "supplement visual feedback by also using alternatives like haptics and audio to communicate." Every animation must handle Reduce Motion, and important state changes should use multiple feedback channels — not animation alone.

@Environment(\.accessibilityReduceMotion) private var reduceMotion

// Pattern 1: Conditional animation
withAnimation(reduceMotion ? .none : .spring()) {
    isExpanded.toggle()
}

// Pattern 2: Simplified alternative
.animation(reduceMotion ? .easeOut(duration: 0.15) : .spring(duration: 0.5, bounce: 0.3), value: isActive)

// Pattern 3: Skip entirely
if !reduceMotion {
    view.phaseAnimator(phases) { /* ... */ }
}

Reduce Motion fallback options (from most to least graceful):

1. Crossfade — replace motion with opacity transition
2. Shortened — same animation, much faster (0.1–0.15s), no bounce
3. Instant — .animation(.none) or skip the animation block entirely

Cancellation & Interruptibility

Apple's HIG: "Don't make people wait for an animation to complete before they can do anything, especially if they have to experience the animation more than once." Every animation must be interruptible.

• Spring animations retarget automatically — this is the default and almost always what you want
• For gesture-driven animations, the user is always in control — let them cancel mid-flight
• For sequenced animations (KeyframeAnimator, PhaseAnimator with trigger), ensure the UI remains interactive during playback
• Never disable user interaction during an animation unless there's a critical reason (e.g., destructive action confirmation)

Performance Checklist

• Animate on the render server when possible — Core Animation runs off the main thread, SwiftUI's drawingGroup() moves rendering to Metal
• Avoid animating view identity changes (.id() modifier) — this destroys and recreates the view
• Use geometryGroup() when parent geometry changes cause child layout anomalies during animation
• Provide explicit shadowPath when animating shadows — without it, the system recalculates the path every frame
• In lists and scroll views, avoid per-item blur/shadow animations — these cause offscreen rendering for each cell
• Keep PhaseAnimator and looping animations lightweight — they run continuously
• For frequent interactions, prefer system-provided animation over custom motion — Apple's HIG: "generally avoid adding motion to UI interactions that occur frequently"
• Profile with Instruments → "Animation Hitches" template to find frame drops

Gates (before marking work complete)

Run in order; satisfy each Pass before treating the task as done.

1. API fit — Choose the mechanism from the API Selection table for this task. Pass: You can state in one sentence which “Need” row and API you applied (not a different layer “just because”).
2. Reduce Motion — Custom timing must follow Accessibility & Multimodal Feedback. Pass: Non-trivial motion branches on accessibilityReduceMotion (or you only used system defaults / no custom timing).
3. Interruptibility — Matches Cancellation & Interruptibility. Pass: No blanket allowsHitTesting(false) for the whole animation unless the task explicitly requires it and a short comment says why.
4. Heavy or continuous motion — Loops, PhaseAnimator always-on, per-cell blur/shadow, or other Performance Checklist red flags. Pass: You ran Instruments (Animation Hitches) and captured a note or path to the trace, or you simplified the pattern first and can point to the change.