Guideline 2.5.4: Apple rejected your background mode

Guideline 2.5.4 limits background modes to their intended purpose: audio, location, VoIP calls, task completion, local notifications. You get rejected when your Info.plist declares one of these modes and the reviewer can't find any feature that needs it. Remove the key if nothing uses it. Otherwise, show the reviewer the feature in thirty seconds.

I publish my own iOS apps with Expo. Solys, my alarm clock with mini-games, declares the audio mode: I removed it, then put it back for a different reason. This guide is based on Apple's text, on rejections other developers have published and on my own projects. For the big picture on rejection reasons, read why Apple rejects an app.

What does guideline 2.5.4 say?

The rule fits in one sentence, in section 2 "Performance", part 2.5 "Software Requirements" of the App Review Guidelines: "Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc."

In plain terms: a background service is only for what it was built for. Hence the title "Guideline 2.5.4 - Performance - Software Requirements".

By default, an app that goes to the background gets suspended. To keep running, it declares one or more modes in the UIBackgroundModes key of its Info.plist. Apple's documentation on background modes asks you to use them sparingly, because of battery life, and to prefer another solution when one exists. Every mode you declare is a promise the reviewer can check.

Background modes and their intended use

Mode	Key	Intended use
Audio, AirPlay, PiP	audio	Audible background sound
Location	location	Continuous location
Voice over IP	voip	Calls with CallKit
Background fetch	fetch	Regular network content
Background processing	processing	Scheduled tasks
Remote notifications	remote-notification	Push for new content

This table sums up Apple's page. In rejections posted on the forums, audio, location and voip come up the most.

What does the 2.5.4 rejection message mean?

The message names the mode at issue. Two examples posted by developers on Apple's forums:

• Audio: "Your app still declares support for audio in the UIBackgroundModes key in your Info.plist but did not include features that require persistent audio." It goes on to explain that the audio key is meant for apps that play audible content in the background, like a music player. It offers two ways out: add that content or remove the key (forum thread).
• Location: in a December 2024 thread, Apple found no feature other than employee tracking that required persistent location, and wrote that this use alone isn't appropriate.

My take: the reviewer doesn't read your code, they look for a feature. They need to be able to start it, send the app to the background and see that it keeps going.

The opposite case happens too. In a May 2026 thread, a read-aloud app that genuinely used the audio mode was rejected several times: the reviewer couldn't get the audio to start. Another developer writes there that, in his opinion, an attached video unblocked his case. That's a testimonial, not an Apple rule.

Where does the key come from if you didn't add it?

With Expo, config plugins fill in the Info.plist at prebuild. So a background mode can end up in your binary without you deciding it.

The expo-audio plugin, with its default settings

The expo-audio documentation says it: the enableBackgroundPlayback option defaults to true and, on iOS, adds the audio mode. Declaring the plugin in its short form, "expo-audio", is enough to declare the mode.

That's what I found while reviewing TradaZen before its first submission: short UI sounds in the foreground, but a plugin declared in short form. The fix is one line in app.json:

{
  "expo": {
    "plugins": [["expo-audio", { "enableBackgroundPlayback": false }]]
  }
}

Other packages add a mode their own way. The isIosBackgroundLocationEnabled option of expo-location adds location only if you turn it on. expo-background-task, on the other hand, adds processing at prebuild as soon as it's installed.

The ios/ folder that keeps the old key

Second trap, which I hit on Solys in July 2026. I had removed audio from app.json, but the key was still in ios/Solys/Info.plist, generated earlier. A prebuild without --clean modifies that project instead of recreating it, and the plugin adds the key but never removes it. A local build would have shipped it. A cloud EAS build starts from a fresh prebuild when ios/ is ignored by git, which was my case.

Before every build, I check what will actually ship:

npx expo config --type introspect --json | grep -o '"UIBackgroundModes":\[[^]]*\]'
npx expo prebuild --clean --platform ios

The first lists the modes the prebuild will write into the Info.plist. The second recreates the native project for a local build, wiping the ios/ folder. On Solys, the first shows "UIBackgroundModes":["audio"], on TradaZen nothing: both are intentional.

Adding or removing a mode changes the Info.plist, so the binary: you need a new build, an over-the-air update isn't enough. The EAS Update documentation lists these changes among the ones that require a new binary, same as for ITMS-90683.

Solys: an audio mode declared, for a real reason

Solys is an alarm clock, but the audio mode isn't what makes the alarm ring: the ringing goes through AlarmKit, Apple's alarm service available since iOS 26 (AlarmKit documentation). The system rings, even in silent mode, not the app.

The history of the key, because the reasoning matters more than the line:

1. Late July 2026, I removed it. Nothing played sound in the background: the mini-game sound effects stay in the foreground, and the alarm doesn't depend on the app.
2. Two days later, I put it back, with night listening. This option records the sounds of your night with the mic and analyzes them on the iPhone. Recording has to continue with the screen locked, and the expo-audio documentation says the background recording option also adds the audio mode.

The justification changed in nature: the mode is for recording, not playing. Three safeguards, visible in the app:

• listening is an option, off by default, that you turn on from settings or the evening ritual;
• it has its own consent screen, as rule 2.5.14 requires for any recording, and nothing leaves the phone;
• the mic closes ten minutes before the alarm, so listening and ringing never get in each other's way.

I can't guarantee a reviewer will always accept this declaration. I can say, for each piece, what it's for and where to see it.

Alarm apps that kept themselves awake

Before AlarmKit, a third-party alarm app couldn't ring like Apple's alarm. So some libraries kept the app awake: the docs for the Flutter package alarm2 describe a silent audio player running until the alarm. But silent audio makes nothing audible. Since iOS 26, AlarmKit makes this workaround unnecessary.

Keep or remove the mode: the decision grid

Your situation	What to do
Short foreground sounds	Remove audio
Music or audiobook	Keep it, show it
Long recording	Keep + consent
Alarm or timer	AlarmKit (iOS 26)
Occasional location	Significant changes
Non-urgent sync	fetch or processing
Audio or video calls	voip with CallKit

For location, Apple's page cites the significant-change location service as an alternative to the location mode.

The other parts of 2.5: 2.5.1 and 2.5.2

2.5.1: public APIs and frameworks used for their purpose

"Apps may only use public APIs and must run on the currently shipping OS." The app uses only public APIs, runs on the current OS version and drops anything deprecated. As with 2.5.4, each framework serves its intended purpose, mentioned in the description: HealthKit for health, HomeKit for the smart home. If a library calls a private API, your app takes the rejection.

2.5.2: no downloaded code that changes the app

The app stays self-contained in its bundle. It may not "download, install, or execute code which introduces or changes features or functionality of the app". Only educational apps that teach coding get a limited exception, with code that's fully visible and editable by the user.

With Expo, this affects EAS Update, whose documentation reminds you that updates must follow App Store rules. Keep over-the-air updates for fixes, never to ship a feature the reviewer hasn't seen. A review-related fix goes through a new build, as I explain in the guideline 2.1 guide.

How do you reply to a 2.5.4 rejection?

The conversation happens in your app's App Review section, where you reply to the App Review message. Two cases:

• The mode does nothing: remove it, rebuild, check the introspection, then reply in two sentences.
• The mode serves a real feature: reply with the exact path and a short video, then reuse that text in the review notes of every version.

The template I'd use, to adapt (drop the alarm sentence if your app doesn't have one):

Hello,

The "audio" background mode is used only by [feature], an
optional feature that [records / plays] audio while the
device is locked. It is off by default.

How to test:
1. Open [screen] and turn on [feature].
2. Accept the microphone permission if asked.
3. Tap [button], then lock the device.
   [What the reviewer will hear or see.]

Our alarm does not use this mode: it is scheduled with
AlarmKit and rings through the system.

Attached: a short screen recording of these steps.

Best regards,

The 2.5.4 checklist before submitting

• Expo introspection shows only the modes you want, and you can name the feature behind each one.
• No plugin is declared in short form if it adds a mode by default, like expo-audio.
• Your local ios/ folder keeps no old key, or you build from a clean prebuild.
• The feature starts quickly, with no hidden setting, and the review notes say which mode does what and how to test it.
• Any recording asks for explicit consent and shows a visible indicator. The rules on permission requests are in the guideline 5.1.1 guide.
• For an alarm clock, the ringing goes through AlarmKit, not a sound played from the app.

Check your submission before sending it

The Review Kit bundles my pre-submission checklist, templates for reviewer notes and Claude Code skills that review your project. For a human eye, book an hour with me: we go through Apple's message and your Info.plist together over video. The full process is on the app rejected by Apple page.

Getting ready for your first release? Take the free diagnostic: it puts the steps in order and sends you my Apple anti-rejection checklist.

Nobody can guarantee Apple will accept your app. A well-justified background mode, though, can be defended in thirty seconds.

Frequently asked questions

What does "Guideline 2.5.4 - Performance - Software Requirements" mean?

It's the rejection title when Apple thinks a background mode in your Info.plist isn't used for its intended purpose. The message names the mode and suggests showing the feature that uses it or removing the key.

Do you need a new build after a 2.5.4 rejection?

If you remove or change a mode, yes: the key is in the Info.plist, so in the binary. If the mode is justified, a reply with the exact path and a video may be enough.

Can you keep the audio mode for a few UI sounds?

No. Short sounds played in the foreground don't need it. With Expo, set enableBackgroundPlayback to false in the expo-audio plugin.

Does an alarm clock app need the audio mode?

Not to ring, if it relies on AlarmKit, available since iOS 26: the system plays the alarm. On Solys, the audio mode is used for night listening, which records with the screen locked.

Why does Apple cite 2.5.4 when I didn't declare anything?

A plugin may have done it for you: expo-audio adds the audio mode by default, and an old ios/ folder can keep a key you removed from your config. Check with npx expo config --type introspect.