Post

Replies

Boosts

Views

Activity

Recurring Guideline 2.5.4 rejection despite confirmed-working background audio on physical device — looking for community experience
Hi everyone, Looking for guidance on a stalled review. My app, Nubi, has been rejected twice under Guideline 2.5.4 for the audio background mode, both citing inability to locate/trigger a feature requiring persistent audio. What the app does: Nubi lets a parent record themselves telling a bedtime story; the app transcribes it, illustrates it page-by-page, and plays it back narrated in the parent's own voice. The "audio" UIBackgroundMode is declared so that once playback starts, it continues if the screen locks or the parent switches apps — the same category of use as Audible, Spotify, or Apple Podcasts: a child listens to the story and falls asleep without the phone needing to stay unlocked. What we've done across submissions: Confirmed background playback works correctly on a physical iPhone: start narration, lock the device, Lock Screen Now Playing shows playback continuing. Identified and fixed a real configuration gap (a missing expo-audio config plugin option) that meant background audio genuinely didn't work on earlier builds — confirmed via direct inspection of the compiled binary. Attached a screen recording of the lock-and-continue flow to the Resolution Center reply. Detailed App Review notes explaining the use case. The most recent rejection (reviewed on a physical iPad) again says the reviewer is "unable to locate any features that require persistent audio," despite the above. This is not reproducible on any device we've tested. Has anyone resolved a recurring 2.5.4 rejection like this? Specifically: Did attaching the recording directly to the Resolution Center reply (vs. only the App Review Information Notes field) make a difference for anyone? Any experience with reviewers backgrounding via force-quit from the app switcher rather than locking/Home, which iOS deliberately terminates background audio for, by design? Any luck reaching App Review directly for a case like this? Appreciate any pointers — happy to share more detail.
1
0
107
1w
Recurring Guideline 2.5.4 rejection despite confirmed-working background audio on physical device — looking for community experience
Hi everyone, Looking for guidance on a stalled review. My app, Nubi, has been rejected twice under Guideline 2.5.4 for the audio background mode, both citing inability to locate/trigger a feature requiring persistent audio. What the app does: Nubi lets a parent record themselves telling a bedtime story; the app transcribes it, illustrates it page-by-page, and plays it back narrated in the parent's own voice. The "audio" UIBackgroundMode is declared so that once playback starts, it continues if the screen locks or the parent switches apps — the same category of use as Audible, Spotify, or Apple Podcasts: a child listens to the story and falls asleep without the phone needing to stay unlocked. What we've done across submissions: Confirmed background playback works correctly on a physical iPhone: start narration, lock the device, Lock Screen Now Playing shows playback continuing. Identified and fixed a real configuration gap (a missing expo-audio config plugin option) that meant background audio genuinely didn't work on earlier builds — confirmed via direct inspection of the compiled binary. Attached a screen recording of the lock-and-continue flow to the Resolution Center reply. Detailed App Review notes explaining the use case. The most recent rejection (reviewed on a physical iPad) again says the reviewer is "unable to locate any features that require persistent audio," despite the above. This is not reproducible on any device we've tested. Has anyone resolved a recurring 2.5.4 rejection like this? Specifically: Did attaching the recording directly to the Resolution Center reply (vs. only the App Review Information Notes field) make a difference for anyone? Any experience with reviewers backgrounding via force-quit from the app switcher rather than locking/Home, which iOS deliberately terminates background audio for, by design? Any luck reaching App Review directly for a case like this? Appreciate any pointers — happy to share more detail.
Replies
1
Boosts
0
Views
107
Activity
1w