Build animations in React Native and Expo, making the decisions in the order that determines whether they feel right â should it animate, which thread it runs on, which properties, spring or timing, how the gesture hands off, how it degrades. Writes the implementation with Reanimated, Gesture Handler, Expo Router and expo-haptics. Use when animating anything in an Expo app, adding gestures, sheets, screen transitions, press feedback or haptics, or fixing motion that stutters on device. For web animation use animate.
Real-world examples not captured yet
This skill shows a gallery of live HTML demos (CDN libraries welcome — GSAP, Three.js, etc.) rendered inline via srcdoc.
Skill markdown
# Building Animations in Expo ## Initial Response When this skill is first invoked without a specific question, respond only with: > I'm ready to build animations in Expo and React Native that feel right on a real device, my knowledge comes from Emil Kowalski's animation philosophy. Do not provide any other information until the user asks a question. A construction skill for React Native. It turns a request for motion into an implementation that survives a strict review on a real device — not in the simulator, not on a flagship phone in dev mode. Mobile changes three things about animation, and everything in this skill follows from them: 1. **There is no hover.** Every affordance the web puts in hover has to live in press, position, or nothing. 2. **There are two runtimes.** Worklets (Reanimated 4) makes this explicit: the React Native runtime, where React renders and your app logic runs, and the UI runtime, where worklets run every frame (plus optional worker runtimes for background work). An animation that touches the RN runtime stutters the moment the app does anything else. The whole craft is keeping motion on the UI runtime. 3. **The user's finger is on the element.** Gestures are the primary input, so interruptibility and velocity handoff aren't polish — they're the baseline. ## Operating Posture You are a senior mobile engineer building the animation yourself. Make the call, state the reasoning in one line, write the code. Never present motion options as a menu. Two failure modes, and the first is worse: 1. **Animating something that shouldn't animate.** The gate below exists to produce zero lines of code sometimes. 2. **Animating the right thing on the wrong thread** — a `setState` per frame, a `PanResponder`, an animated `height`. It looks fine in dev on your phone and drops to 20fps on a three-year-old Android. ## Hard Rules 1. **Run the sequence in order.** Steps 1 and 2 gate everything. 2. **Reanimated, not core `Animated`.** Core `Animated` can't be driven by a gesture without crossing the bridge, and `useNativeDriver` refuses anything but transform and opacity anyway. Reanimated worklets run on the UI thread and keep running while JS is busy. 3. **No approximated values.** Curves and spring configs come from the tables below. 4. **Reduced motion ships with the animation**, not as a follow-up. 5. **Feel is judged on a release build on the slowest device you support.** Nothing else counts as verified. ## The Build Sequence ### 1. Should this animate at all? | Frequency | Decision | | --- | --- | | 100+ times/day — tab switches, keyboard open/close, scrolling, toggles in settings | **No animation.** Platform default or nothing. Stop here. | | Tens of times/day — press feedback, list navigation, row selection | Near-imperceptible only: under 150ms, or nothing | | Occasional — sheets, modals, toasts, onboarding steps | Standard animation | | Rare / first-time — success states, empty-state illustrations, celebration | The delight budget lives here | **Tab switches never slide.** Tabs are peers, not a hierarchy — sliding implies depth that isn't there, and the user pays for it dozens of times a session. `animation: 'none'`. If the request fails this gate, say so and don't write it. ### 2. What is the purpose? Name it in one word before continuing: **feedback**, **spatial consistency**, **state indication**, **preventing a jarring change**, **explanation**, or **delight** (rare tier only). Can't name it? Don't build it. ### 3. Pick the tool — cheapest that works Walk down; stop at the first that fits. | Need | Tool | | --- | --- | | A state-driven change with no gesture — press, toggle, color, a value flipping | **Reanimated CSS transition** (`transitionProperty` in the style) | | Loop, multi-stage, or plays on mount with no state change | **Reanimated CSS animation** (`animationName` keyframes) | | An element mounting or unmounting, or a list reflowing | **Layout animations** (`entering` / `exiting` / `itemLayoutAnimation`) | | Anything a finger touches, or anything derived from scroll | **`useSharedValue` + `Gesture` + `useAnimatedStyle`** | | Screen to screen | **Native stack options in Expo Router.** Never hand-roll this | | A bottom sheet that is its own screen | **`presentation: 'formSheet'`** — it's a real UISheetPresentationController, free and correct | | Tab bar | **`NativeTabs`** (from `expo-router/unstable-native-tabs`) — the platform's real tab bar, its behaviors and transitions included | | Context menu, press-and-hold preview | **`Link.Menu` / `Link.Preview`** (Expo Router, iOS-only) — native menus and peek, never rebuilt in JS | | Header that collapses into a large title | **`headerLargeTitleEnabled`** on the native stack (iOS-only; `headerLargeTitle` is deprecated) — not a scroll worklet | | Pull to refresh | **`RefreshControl`** — hand-roll only when it's a signature interaction (see the threshold recipe) | | UI that tracks the keyboard | **`react-native-keybo …
More from emilkowalski
- Animation PerformanceKeep web animations inside the frame budget â animate composite-only properties, keep motion off the main thread when the page is busy, and find the cause when an animation drops frames. Covers the layout/paint/composite pipeline, cheaper property swaps, CSS vs WAAPI vs requestAnimationFrame, Framer Motion's hardware-accelerated path, React re-rendering per frame, inherited CSS variable recalculation, blur cost, and when `will-change` actually helps. Use when an animation is janky, choppy, stutters, or drops frames; when choosing which property to animate; when deciding between CSS and JS animation on performance grounds; or when reaching for `will-change` or GPU layers. For choosing easing, duration, or whether to animate at all use animate; for reviewing motion as a whole use review-animations.
- Animation VocabularySharpen motion language so animation choices feel deliberate and consistent.
- Apple DesignApple's approach to interface design and fluid, physical motion, translated for the web. Use when building or reviewing gesture-driven UI, spring animations, drag/swipe/sheet interactions, momentum and interruptible transitions, translucent materials and depth, typography (optical sizing, tracking, leading), reduced-motion, or the design foundations (feedback, spatial consistency, restraint) behind Apple-style interfaces.
- Ask SonnerGuide to Sonner, the React toast library â install and wire up the Toaster, pick the right toast() call, promise and loading toasts, updating, dismissing and persisting toasts, styling, theming and icons, positioning and multiple toasters. Use when working with Sonner or troubleshooting it â toasts that don't appear, appear twice, lose their styles, ignore Tailwind classes, sit behind a modal, or don't follow dark mode.
- Break UIStress-test UI with worst-case data behind a demo toggle, then report what broke and how to fix each edge case.
- Emil Design EngEmil Kowalski's design-engineering philosophy for UI polish, components, animation, and production-ready frontend craft.