We’re seeing some really strange behavior with the demo account we provide to App Review, and I’m trying to understand what could be causing it.
Our iOS app uses passwordless email sign-in with a one-time code. In App Store Connect, under App Review Information, we provide a demo email account with a fixed code so reviewers don’t need access to an actual mailbox.
The demo email we provide has the local part test.
The problem is that what reaches our sign-in API is often not test.
For example, today we received tst. Same domain, but with one character missing.
We’ve checked the App Review Information multiple times and the email entered there is correct, so something appears to be changing the value between App Store Connect and the device entering it.
Over the last 10 days, our API has logged the following attempts from Apple-owned IP ranges (139.178.130.x / 139.178.131.x):
Aug 2 build 82 "隐藏邮件地址test"
Aug 4 build 78 "tt"
Aug 8 build 66 "test" correct
Aug 9 build 90 "tst"
Aug 9 build 82 "tst"
Aug 9 build 68 "tst"
Aug 9 build 87 "tst"
Every one of these should have been test. Six out of seven were not.
There are a few things that make this especially confusing.
We currently have no submission under review. The latest version has already been approved and is live.
These sessions also appear to be fresh installs of different historical builds. We’re seeing versions 1.2.0, 1.4.0, and 1.5.0. On Aug 9 alone, four different builds were launched. These aren’t builds a normal user could currently install from the App Store.
Even stranger, all four Aug 9 sessions submitted exactly the same incorrect value: tst.
The address itself also isn’t something that should be guessable. It’s a variation of a credential that, as far as we know, only exists inside the App Review Information field.
The Aug 2 request is probably the strangest one. The submitted value contained 隐藏邮件地址, which is the Chinese iOS label for “Hide My Email,” immediately followed by test. That looks a lot like an AutoFill suggestion or label being inserted into the text field instead of just the email address.
The behavior after that is also very consistent.
Each session goes through onboarding, opens the sign-in sheet, chooses email sign-in, requests a code, returns to the sheet, tries once more, then gives up and enters our guest mode to browse the app.
Because the submitted email address is wrong, the account doesn’t exist and the code can never be received. The second attempt then hits our own 60-second resend lockout, so none of these sessions ever reaches an authenticated account.
I’m trying to understand a few things:
-
What Apple process would install previously uploaded builds and exercise the App Review demo credentials when there is no active submission under review? Could this be automated scanning, TestFlight beta review, or something else?
-
Has anyone seen App Review demo credentials arrive corrupted like this? Is there a known issue involving iOS AutoFill, copying credentials to the review device, or the way App Review Information is stored or passed to reviewers?
-
Since App Review Information is attached to an app version, what happens if the field is edited after that version has already been submitted? Does the submitted version retain the value that existed at submission time, or does it use whatever value is currently in App Store Connect?
-
Is there any supported way to determine which App Review credential or version of the credential a particular uploaded build is associated with?
I’m happy to share timestamped API/request logs if that would help identify what’s happening.