Your Animation Keeps Running After You Leave the Screen — Focus-Aware Battery Savings in a Rork (Expo) App

Combine focus and app state into one hook

There are two conditions to stop on: "is this screen in front (focus)" and "is the app itself in front (AppState)." Run the animation only when both are true, and stop the moment either turns false.

Combine React Navigation's useIsFocused and React Native's AppState into a single hook.

import { useEffect, useState } from 'react';
import { AppState, AppStateStatus } from 'react-native';
import { useIsFocused } from '@react-navigation/native';
 
/**
 * Returns true only when the screen is in front AND the app is active.
 * Use it to centralize starting and stopping animations.
 */
export function useShouldAnimate(): boolean {
  const isFocused = useIsFocused();
  const [appActive, setAppActive] = useState(
    AppState.currentState === 'active'
  );
 
  useEffect(() => {
    const sub = AppState.addEventListener('change', (state: AppStateStatus) => {
      setAppActive(state === 'active');
    });
    return () => sub.remove();
  }, []);
 
  return isFocused && appActive;
}

AppState's 'active' means the app is in front and interactive; 'background' is when you've gone home or locked; 'inactive' is the transition (the instant a call arrives or you pull down Control Center). Pausing briefly during a transition does no visible harm, so here I treat anything other than 'active' as a stop.

Stop a Reanimated loop reliably

Start withRepeat when useShouldAnimate is true and stop it with cancelAnimation when it goes false. There's one implementation trap here.

import { useEffect } from 'react';
import Animated, {
  useSharedValue,
  useAnimatedStyle,
  withRepeat,
  withTiming,
  cancelAnimation,
  Easing,
} from 'react-native-reanimated';
 
export function BreathingGlow() {
  const shouldAnimate = useShouldAnimate();
  const progress = useSharedValue(0);
 
  useEffect(() => {
    if (shouldAnimate) {
      progress.value = withRepeat(
        withTiming(1, { duration: 4000, easing: Easing.inOut(Easing.ease) }),
        -1,    // infinite
        true   // reverse
      );
    } else {
      cancelAnimation(progress);
      // Trap: cancelAnimation freezes at "the value at that instant."
      // Don't let it stick at a half scale — ease back to rest.
      progress.value = withTiming(0, { duration: 300 });
    }
    return () => cancelAnimation(progress);
  }, [shouldAnimate]);
 
  const style = useAnimatedStyle(() => ({
    transform: [{ scale: 1 + progress.value * 0.06 }],
    opacity: 0.7 + progress.value * 0.3,
  }));
 
  return <Animated.View style={[styles.glow, style]} />;
}

cancelAnimation isn't "stop," it's "freeze at the current value." If you leave the screen while the breathing animation is mid-expansion, it can stay frozen at an awkward size when you return. So on stop, follow cancelAnimation with a short withTiming back to rest (here, 0). Don't forget the cancelAnimation in the cleanup function, either — without it, a quick re-focus can double-start the loop and burn more battery than before.

Make cleanup reliable with useFocusEffect

Instead of watching useIsFocused inside a useEffect, React Navigation's useFocusEffect guarantees that cleanup runs the moment focus is lost, which makes double-starts easier to avoid. It suits anything controlled through a ref, like Lottie or video.

import { useRef, useCallback } from 'react';
import { useFocusEffect } from '@react-navigation/native';
import LottieView from 'lottie-react-native';
 
export function AmbientLottie() {
  const ref = useRef<LottieView>(null);
 
  useFocusEffect(
    useCallback(() => {
      ref.current?.play();
      return () => ref.current?.pause(); // always stops when focus is lost
    }, [])
  );
 
  // No autoPlay. Keep playback control in one place: useFocusEffect.
  return <LottieView ref={ref} source={require('../assets/ambient.json')} loop />;
}

The key is leaving off autoPlay. If you control playback from both autoPlay and useFocusEffect, they both fire on first mount and the control flow gets hard to read. Keep a single source of truth for "play."

Video follows the same idea — just pause() the expo-video player. Unless you specifically want audio to continue in the background, stopping on focus loss is the kinder choice for both battery and data.

Thin out always-on loops in a list with visibility

In a wallpaper gallery where each cell carries a small loop (a sparkle or shimmer), FlatList virtualization alone leaves cells near the edges running. Playing only the cells that are actually visible, via onViewableItemsChanged, keeps the number of concurrent loops bounded.

const visibleIds = useSharedValue<string[]>([]);
 
const onViewableItemsChanged = useRef(({ viewableItems }) => {
  visibleIds.value = viewableItems.map((v) => v.item.id);
}).current;
 
const viewabilityConfig = useRef({
  itemVisiblePercentThreshold: 50, // visible once half is on screen
}).current;
 
// In each cell, toggle the loop based on whether its id is in visibleIds.

Now "only the few cells on screen animate, and they stop once scrolled out of view." In my wallpaper apps, CPU usage during scrolling dropped noticeably after adding this thinning.

How to confirm it's actually working

Once the design is in, verify it with numbers instead of assumptions. Three ways, easiest first.

First, add a dev-only log to the stop logic and watch the console confirm shouldAnimate flips to false — and the animation stops — on every navigation and lock. Establish the logic before anything else.

Second, in Xcode's Debug Navigator, check whether CPU usage falls to idle while you're away from the screen. If it doesn't, a loop is surviving somewhere.

Third, use Instruments' Energy Log, or simply unplug a real device, leave it for a while, and look at your app's "background" share in the Settings battery breakdown. Comparing before and after shows how much of the silent loop you cut.

The order to roll it out

Changing everything at once makes isolation hard. I'd add it in this order: build one useShouldAnimate hook; wire up just the most constantly running animation first (a full-screen background loop or the breathing animation) and confirm CPU drops to idle when you leave; move Lottie and video to the useFocusEffect pattern; and finally add list visibility gating. Check the battery breakdown on a real device once per stage, and you'll have a record of which fix mattered.

The finish line is simple: only what's visible while the app is open should animate, and everything else should be still. Leaving no unseen loops behind — that, I've come to think, is what "lightweight" really means.

Thank you for reading. I hope it gives a useful thread to pull on if you're wrestling with battery life too.