# Guideline 2.5.9 - Software Requirements: Overriding Standard System UI Controls

**Guideline:** 2.5.9 · **Store:** Apple App Store · **Severity:** medium · **Fix difficulty:** medium · **Typical turnaround:** 2-8 hours

Canonical URL: https://appstorereject.com/rejections/apple/2/guideline-259-software-requirements-overriding-standard-system-ui-controls

## Description

Apple is rejecting your app because it alters the standard behavior of system-provided UI elements such as the volume up/down buttons, the ringer/silent switch, screen brightness controls, or standard iOS gestures. Apple requires that hardware buttons and system UI controls behave as users expect across all apps. The most common trigger is remapping the volume buttons. Some apps (particularly games and camera apps) try to use volume buttons as shutter triggers, game controls, or other custom functions. While the volume buttons can legitimately trigger a camera shutter (the system Camera app does this), Apple is selective about which apps can repurpose hardware buttons. This also covers: overriding the back swipe gesture in navigation controllers, preventing the system volume HUD from appearing, disabling the status bar pull-down for Control Center, or intercepting system gestures like the home indicator swipe. Apple wants users to have consistent, predictable interactions across all apps.

## Common variations

- App modifies behavior of volume buttons
- App overrides system gesture behavior
- App prevents standard system UI from appearing
- App alters standard function of system-provided switches
- App intercepts or overrides hardware button behavior

## Example rejection email

```
Guideline 2.5.9 - Performance - Software Requirements

Your app alters the standard function of a system-provided UI element. Specifically, your app modifies the behavior of the volume buttons to perform a function other than adjusting volume.

Altering the standard behavior of system-provided controls can lead to a confusing user experience.

Next Steps:
Please revise your app to ensure that all system-provided UI elements, including hardware buttons and system gestures, function as expected. If you believe your use case warrants an exception, please describe it in the Review Notes.
```

## Resolution steps

## Quick Assessment
- **Risk level:** Medium
- **Resolution path:** Fix & Resubmit (or appeal with justification)
- **Typical turnaround:** 2-8 hours

## The Fix

1. **Restore default button behavior** -- Remove any code that observes or intercepts hardware button events for non-standard purposes. For volume buttons, remove `AVAudioSession` route change observers or `MPVolumeView` hacks used to detect presses.

2. **Restore system gestures** -- If you've overridden `preferredScreenEdgesDeferringSystemGestures` or `prefersHomeIndicatorAutoHidden`, remove these unless they're truly necessary for an immersive experience (games in full screen).

3. **Don't hide system UI** -- Ensure the status bar, volume HUD, and Control Center access work normally. If you need to hide the status bar during gameplay, use `prefersStatusBarHidden` properly and restore it outside of gameplay.

4. **Use standard navigation patterns** -- Don't disable the back swipe gesture in UINavigationController. If you have a custom transition, implement `UINavigationControllerDelegate` properly instead of disabling the interactive pop gesture.

5. **Document exceptions in Review Notes** -- If you have a legitimate reason for non-standard behavior (e.g., immersive game, camera app), explain it in review notes with screenshots.

## Prevention
- Follow Apple's Human Interface Guidelines for all system interactions
- Don't repurpose hardware buttons unless it's an established convention in your app category
- Test that all system gestures work correctly in your app
- Get HIG review from someone familiar with Apple's guidelines before submission

## Appeal guidance

If your use of hardware buttons is a well-established pattern in your app category (e.g., volume button as camera shutter in a camera app), explain the precedent and user expectation in the Resolution Center. Apple does grant exceptions for established conventions.

## Before / after examples

**Before:** Document scanner app uses volume-down button to trigger page capture, with hidden MPVolumeView to suppress the volume HUD
**After:** On-screen capture button added with haptic feedback. Volume buttons restored to standard volume control. Optional: Review Notes explain that camera apps like the system Camera use volume buttons as shutter, requesting consideration for the same convention.
**Why it works:** Add an on-screen alternative first, then appeal if the volume button shutter is important to your UX. Always have a fallback.

## Common questions

**Can you appeal a 2.5.9 rejection?**

If your use of hardware buttons is a well-established pattern in your app category (e.g., volume button as camera shutter in a camera app), explain the precedent and user expectation in the Resolution Center. Apple does grant exceptions for established conventions.

**How long does this typically take to fix?**

Typical turnaround is 2-8 hours (difficulty: medium). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-259-software-requirements-overriding-standard-system-ui-controls*