What Your App Should Do When Someone Turns On Reduce Motion — A Motion-Respecting Layer in Expo

"Turn everything off" is not the right answer

This is the part I most want to land. Setting every animation to duration: 0 for someone who enabled Reduce Motion looks considerate but is actually a blunt response.

Apple's Human Interface Guidelines recommend replacing motion rather than removing it. Large spatial effects like parallax and zoom are a burden, but an opacity cross-fade actually communicates a state change gently. If you erase even the motion that carries meaning — "this appeared," "the screen changed" — transitions become abrupt and create a different kind of confusion.

Here is the decision framework I actually settled on across my apps.

The goal, then, is to reduce the total amount of motion and reroute the high-displacement effects to a gentler alternative. That's a different design instinct from zeroing everything with one switch.

Tuning per animation

Since v3.5, Reanimated lets you pass reduceMotion in an animation function's config. Specifying ReduceMotion.System automatically suppresses motion according to the device setting.

import Animated, {
  useAnimatedStyle,
  useSharedValue,
  withTiming,
  ReduceMotion,
} from 'react-native-reanimated';
 
const offset = useSharedValue(40);
 
// System: follow device / Never: always animate / Always: always suppress
const style = useAnimatedStyle(() => ({
  transform: [
    {
      translateY: withTiming(offset.value, {
        duration: 320,
        reduceMotion: ReduceMotion.System,
      }),
    },
  ],
}));

It's handy, but this is for suppressing a given motion, not for swapping it for a different one. When you want to replace a slide-in with a cross-fade, branching on the hook expresses the intent better.

function Slide({ index, active }: { index: number; active: number }) {
  const reduced = useReducedMotion();
  const progress = useSharedValue(0);
 
  useEffect(() => {
    progress.value = withTiming(active === index ? 1 : 0, { duration: 300 });
  }, [active, index]);
 
  const style = useAnimatedStyle(() => {
    if (reduced) {
      // Drop the movement, switch with opacity alone
      return { opacity: progress.value };
    }
    // Normally pair the fade with a small horizontal move
    return {
      opacity: progress.value,
      transform: [{ translateX: (1 - progress.value) * 24 }],
    };
  });
 
  return <Animated.View style={[styles.slide, style]}>{/* ... */}</Animated.View>;
}

When reduced is true we never build the translateX and return opacity only. The total motion drops, yet the fact that "the slide changed" still comes across. It felt like I could finally give that reviewer a proper answer.

Run the same judgment through screen transitions

Extend the same thinking beyond individual components to screen transitions. If you use Expo Router / React Navigation, dropping slide transitions to a fade under Reduce Motion is natural.

import { Stack } from 'expo-router';
import { useReducedMotion } from '../hooks/useReducedMotion';
 
export default function Layout() {
  const reduced = useReducedMotion();
  return (
    <Stack
      screenOptions={{
        animation: reduced ? 'fade' : 'slide_from_right',
      }}
    />
  );
}

It's a one-line branch, but it changes how the whole app feels. A screen that slid in from the side now quietly fades up under Reduce Motion. You end up honoring the user's setting through the app's most visible motion.

Reproducing the "setting on" state in tests

Once it's built, confirm the behavior really changes between off and on. The manual paths are these.

On the iOS Simulator: Settings → Accessibility → Motion → Reduce Motion. On the Android emulator: Settings → Accessibility → Remove animations, or set the animation scale to 0 in Developer options. In both cases, toggle and return to the app to check that the subscription kicks in and updates immediately.

In unit tests, mock AccessibilityInfo to confirm the hook returns the value.

import { AccessibilityInfo } from 'react-native';
import { renderHook, waitFor } from '@testing-library/react-native';
import { useReducedMotion } from '../hooks/useReducedMotion';
 
it('returns true when the setting is on', async () => {
  jest
    .spyOn(AccessibilityInfo, 'isReduceMotionEnabled')
    .mockResolvedValue(true);
  jest
    .spyOn(AccessibilityInfo, 'addEventListener')
    .mockReturnValue({ remove: jest.fn() } as never);
 
  const { result } = renderHook(() => useReducedMotion());
  await waitFor(() => expect(result.current).toBe(true));
});

Because the value arrives asynchronously, note that we wait for resolution with waitFor. A synchronous expect would catch the initial false and fail. That's the flip side of isReduceMotionEnabled() returning a Promise, and understanding it removes any guesswork from how you write the test.

To close

Supporting Reduce Motion is not a flashy feature. But for someone who has the setting on, it quietly draws the line between an app that notices their state and one that doesn't.

As a next step, pick the single screen with the most motion — usually onboarding or a content switcher — and run useReducedMotion through it. Don't try to fix everything; reroute the most burdensome effect to a gentler alternative first. That alone genuinely changes the impression your app leaves on users you weren't reaching before.

I hope this helps anyone facing the settings they can't see from their own device.