Test logins hardcoded outside test targets
Hardcoded test credentials outside a test target ship to users. They are readable in the binary, they usually indicate a development shortcut still wired into the app, and unlike an API key there is no version of this that belongs in a shipped build.
Why it matters
These are added to skip the login screen during development and then not removed, often sitting behind a flag that is supposed to be off in Release and is not.
The credential itself is usually low value, but what it unlocks is not: a test account often has elevated access, or points at a staging environment that is less protected than production.
It also tends to travel with the code that auto-fills the login screen, which is visible to a reviewer and reads as an unfinished build.
How to fix it
- Remove the credentials and the auto-fill path from the shipping target.
- If you want the convenience during development, put it in a test target or behind a compile-time condition that genuinely cannot be true in Release, and confirm the Release configuration does not define it.
- Rotate the test account’s password if it has any access worth having.
- Check what the account can reach. A test login pointing at staging is a smaller problem than one that works against production, and you want to know which you have.
The guidelines behind it
Read from Apple’s App Review Guidelines as last updated October 16, 2026.
What ReviewAhead checks
Test credentials in source. Hardcoded test logins outside test targets ship to users.
- Hardcoded login pairs in source, outside test targets, where a test login is exactly what belongs.
- Masks the matched value before it becomes evidence, so the report does not become a second place the credential exists.
- Excludes matches inside test targets, where a test login is exactly what belongs.
Apple’s own documentation for this requirement: developer.apple.com. Where this page and Apple disagree, Apple is right and this page is a bug.