Keep Audio Playing in the Background and Add Lock Screen Controls in a Rork App

2. Put the audio session into a background-playing mode

Call setAudioModeAsync once at app launch (before you play anything) to set the session's character. What matters here is shouldPlayInBackground: true and, to make lock screen controls work, interruptionMode: 'doNotMix'.

// audioSession.ts — call once at app launch
import { setAudioModeAsync } from 'expo-audio';
 
export async function configureAudioSession() {
  await setAudioModeAsync({
    // Play even with the silent (mute) switch on — essential for healing/music apps
    playsInSilentMode: true,
    // Keep playing in the background and on the lock screen
    shouldPlayInBackground: true,
    // Do not mix with other apps' audio. Without this, lock screen controls
    // won't bind to your player
    interruptionMode: 'doNotMix',
    // Android: pause when another app starts playing, leaving room to resume
    interruptionModeAndroid: 'doNotMix',
  });
}

Leave interruptionMode at its default (equivalent to 'mixWithOthers') and the sound plays, but the lock screen transport controls bind to no player, so the buttons do nothing. The "audio plays in the background but only the lock screen buttons don't respond" symptom is almost always caused by this one line.

3. Create the player and subscribe to playback state

In expo-audio you create a player with useAudioPlayer and subscribe to playback state with useAudioPlayerStatus. Unlike the old expo-av Audio.Sound, the hook handles releasing on unmount for you, so the manual unloadAsync that used to be a memory-leak hotspot is gone.

// SoundScreen.tsx
import { useEffect } from 'react';
import { View, Text, Pressable } from 'react-native';
import { useAudioPlayer, useAudioPlayerStatus } from 'expo-audio';
import { configureAudioSession } from './audioSession';
 
const SOURCE = require('../assets/audio/rain-loop.mp3');
 
export default function SoundScreen() {
  const player = useAudioPlayer(SOURCE);
  const status = useAudioPlayerStatus(player);
 
  useEffect(() => {
    configureAudioSession();
    // Loop playback (common for ambient/healing use)
    player.loop = true;
  }, [player]);
 
  const toggle = () => {
    if (status.playing) {
      player.pause();
    } else {
      player.play();
    }
  };
 
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Text>{status.isLoaded ? 'Ready' : 'Loading…'}</Text>
      <Pressable onPress={toggle}>
        <Text>{status.playing ? 'Pause' : 'Play'}</Text>
      </Pressable>
    </View>
  );
}

Gating the button on status.isLoaded quietly pays off. If you call play() before the source finishes loading, the first tap does nothing, which tends to turn into "the button doesn't work" one-star reviews.

4. Surface info on the lock screen and Control Center

This is the heart of it. Even once it plays in the background, if no track title or play button appears on the lock screen, the user has no choice but to wake the screen and reopen the app. Pass metadata to setActiveForLockScreen to light up the lock screen media controls.

import { useAudioPlayer, useAudioPlayerStatus } from 'expo-audio';
 
async function startWithLockScreen(player) {
  player.play();
 
  // ⚠️ Call it slightly after playback starts.
  // Called before playback, the session isn't active yet, so the
  // lock screen controls sometimes fail to appear
  setTimeout(() => {
    player.setActiveForLockScreen(true, {
      title: 'Rain - 8 Hour Loop',
      artist: 'Relaxing Healing',
      albumTitle: 'Sleep Sounds',
      artworkUrl: 'https://example.com/artwork/rain.jpg',
      // Whether to show seek (fast-forward/rewind). false is natural for ambient loops
      showSeekForward: false,
      showSeekBackward: false,
    });
  }, 250);
}

Pass artworkUrl either a remote URL or a path resolved from a local asset via Asset.fromModule().localUri. Leave it empty and the lock screen thumbnail falls back to the default icon, breaking the mood you worked for. For ambient loops, dropping the seek buttons and keeping only play/pause reduces operational hesitation.

And on Android, unless you call setActiveForLockScreen to post this media notification, the OS stops the background audio after about three minutes. iOS keeps playing with just shouldPlayInBackground: true, but on Android showing the lock screen notification and continuing background playback are linked — this is where you absorb that asymmetry.

The iOS/Android behavior gap on one page

Here are just the differences that directly drive implementation decisions.

Recovering from interruptions (calls, other apps' audio)

Leave a sleep app running all night and a call, an alarm, or another app's audio will inevitably interrupt it midway. During the interruption it auto-pauses, and when it ends you decide whether to resume based on your own playback policy. For healing use, "auto-resume once the interruption ends" is usually closer to user expectations.

import { useEffect, useRef } from 'react';
import { AppState } from 'react-native';
 
function useResumeAfterInterruption(player, status) {
  // Flag recording whether the user intentionally stopped playback
  const shouldAutoResume = useRef(true);
 
  useEffect(() => {
    const sub = AppState.addEventListener('change', (next) => {
      // On returning to foreground, resume if the user didn't stop it
      if (next === 'active' && !status.playing && shouldAutoResume.current) {
        player.play();
      }
    });
    return () => sub.remove();
  }, [player, status.playing]);
 
  return shouldAutoResume;
}

The thing to watch here is not confusing "a pause the user intended" with "a pause caused by an interruption." I once implemented auto-resume without tracking this distinction with a flag, which produced the disappointing behavior of restarting every time the app came back even though the user had stopped it. It is safer to always record the reason playback stopped with an explicit flag like shouldAutoResume.

Pitfalls easy to hit before release

Finally, here are the points beyond what I covered above that tend to trip you up at real-device release.

Deciding "it stops in the background" from Expo Go without making a dev build is the most common way to burn time. Neither UIBackgroundModes nor the Android foreground service is honored in Expo Go. Always verify with an eas build dev build or a production build.

The other is calling setActiveForLockScreen even after the player has been released, leaving lock screen controls lingering as debris on every navigation. Calling setActiveForLockScreen(false) to explicitly tear it down when you leave a screen keeps the display from crossing wires even in an app that switches between multiple sources.

Background playback is less about "making sound" and more about "making the right promise to the OS." Only once the three pieces — declaring the background mode, characterizing the session, and posting the lock screen notification — are all in place does it become an app where users can keep the screen off and fall asleep without worry. Start by getting a single sound file to keep playing after the screen locks, today.