Guideline 2.5 software requirements review checklist

Audit APIs and platform assumptions

Inventory private APIs, deprecated APIs, background execution, downloaded code, web content, external executables, device identifiers, sensors, and entitlement-gated frameworks. The final build should use supported platform paths for the features it exposes.

A feature hidden behind a flag can still create risk if the binary includes unsupported behavior that App Review can trigger or inspect.

Test supported device conditions

• Older supported devices, small screens, low storage, low memory, and slow network.
• iPad, orientation, multitasking, external display, keyboard, or accessibility states where claimed.
• Denied permissions, disabled services, airplane mode, and missing hardware.
• Battery, CPU, network, and storage use for long-running tasks.
• Server responses when app version, OS version, or locale changes.

Control resource and network behavior

Large downloads, caches, streaming, model files, media processing, or sync loops should have user-visible controls and failure states. The app should not appear to hang, overheat, or consume resources without clear value.

AppReviewReady interpretation: performance issues can become review issues when they make core functionality incomplete or unsafe on supported devices.

Add a software requirements gate

1. Run static checks for private or forbidden APIs.
2. Install the App Store archive on the oldest supported OS and device class available.
3. Exercise background, networking, storage, and permission edge states.
4. Remove debug menus, test endpoints, and hidden controls not intended for users.
5. Document any hardware, OS, or region limitations in review notes and metadata.

2.5 runtime matrix

The matrix connects engineering QA to App Review readiness. It is especially useful for apps with AI models, media processing, network extensions, background work, or hardware integrations.

After launch, compare crash, memory, and network errors with supported device lists. If older devices struggle, update minimum requirements or feature fallbacks before review sees the same weakness.

For apps that download models, scripts, templates, or configuration, document what changes after review. The binary should not become a different app because remote content swaps the core experience.

If the app depends on long-running background work, create a user-visible stop or pause control. Reviewers and users should understand why the app continues using network, location, audio, Bluetooth, or processing resources.

When using third-party SDKs, audit them after updates. A library can introduce private API references, aggressive background work, or device fingerprinting behavior that the app team did not write directly.

For apps with device-specific features, provide an alternate review explanation when hardware is absent. The app should fail informatively instead of exposing internal diagnostics.

Runtime matrix:
Feature: [name]
API/framework: [list]
Supported devices: [list]
Resource risk: [network/storage/cpu]
Failure states: [tested]
Review limitation: [none/list]
Owner: [team]