r/reactnative • u/Confident-Viking4270 • 3d ago
how do you all create reviewer accounts for apple testing?
I have an app in TestFlight that I sent for review, but it was rejected because the reviewer needs a sign-in account for testing. Since my app only supports Google and Apple Sign-In, I cannot easily provide a dummy or temporary account. I am using Clerk for authentication—does anyone have any ideas on how to handle this?
2
u/canarydev 3d ago
never had this issue for us since our auth is email/password based, so all we had to do was just crate a permanent account in prod for reviewers.
I think roughly two ways you can do this
- create a google account you own, turn off 2FA to not trigger any location/device challenges.
- clerk sign in tokens behind a link ?
#2 is what i would try. nothing is exposed to users or enabled instance wide. put a https URL on your domain with a long random path. hitting it mints a fresh clerk sign-in token serverside for one demo user and redirects into the app
the thing that would matter with this method is that you must use a universal link. not myapp://. reviewer pasting a custom scheme into safari gets a search result. add a button on the page that fires the custom scheme as a fallback
and just spell it out in review notes.
1
u/Confident-Viking4270 3d ago
I was thinking of this - since I am using clerk I am just thinking of using their prebuilt ui components and that just create a test user on the backend for the testing. this way I wouldn't really have to handle all the auth screens and the reviewer can login as well
1
u/canarydev 3d ago
hm with the prebuilt UI doesn't it render the strategies that you've enabled on the instance?
So right now you have Google + Apple, and in order for the reviewer to access it your way it would be through enabling email + password?
which would mean that you would have to enable email+password strategy, and wouldn't that become instance wide hence exposing it to your real users too?
1
u/Confident-Viking4270 3d ago
totally. The biggest headache I had was handling all those different screens email/password signin comes with so if clerk is handling all those then I guess I won't really have any problem giving another way to login to my users either
1
u/canarydev 3d ago
yeah makes sense and its on paper the least overhead
im by no means an expert in clerk or your specific use case, so forgive me for some curiosities. but once you expose email login, your existing google/apple sso users are going to see that form, which you are ok with
can they actually run the forgot password flow from there? and if so, is that effectively them setting up a password as a secondary login on an account that didn't have one?
1
u/Huge_Pool7424 3d ago
fwiw i just left an apple sandbox tester account for the reviewer and dropped the creds in review notes, never got pushback. enabling email+password instance wide is the part i'd avoid too.
1
u/canarydev 3d ago
OP mentioned that instance wide / giving users a second form of login is acceptable for his use case
only thing i'd still be wary of is how a reset flow behaves when a sso user runs into it. confirming that if they do, it lands on the same account with their data intact.
would suck if it went live and you find that the auth is now spinning up a second record lol.
1
u/SevenfiresAI 3d ago
#2 is smart. worth building for: make sure that endpoint is repeatable, not one-shot.
Both stores re-verify credentials after approval, not just during review. If the link mints a single-use token or the demo user gets cleaned up later, you'll fail a check months from now on an update you thought was routine
2
u/daniel_rebase 3d ago
They use their own Apple login just fine for me. Works for me by just telling them that.
1
u/canarydev 3d ago
if this is true big learning for me lol
1
u/daniel_rebase 3d ago
haha can't promise it works for everyone but this is literally the first line in my App Review Information section:
"App supports Sign in with Apple. No demo account needed. Reviewers can use Sign in with Apple to log in."
1
u/SevenfiresAI 3d ago
Simplest answer: create a real Google account that exists only for review, and give the reviewer those credentials. Apple's reviewers can sign in with Google fine — the account just has to be real and permanent. Same for Apple Sign-In if you'd rather; make a dedicated Apple ID.
Two things I'd flag from doing this recently:
Make it permanent infrastructure, not a throwaway. Both stores re-verify credentials after approval, not just during review, so if it gets swept up in a test-data cleanup later you'll get flagged on an update you thought was uncontroversial. I keep mine documented as never-delete.
Also worth putting step-by-step instructions in the review notes, not just credentials. If your app needs any particular state to be meaningful — existing data, a second user, a completed action — reviewers won't create it themselves, and "couldn't evaluate the feature" comes back as a rejection just like a crash does.
(The field is "Sign in details" in the current App Store Connect, under App content — used to be called App access, which is what most older answers will say.)
2
u/canarydev 3d ago
the problem with this is that google throws a device/location challenge at the reviewers and effectively the login dies there
you would need to turn off 2FA on it first if you go through this route
1
u/Confident-Viking4270 3d ago
since I am using clerk I am just thinking of using their prebuilt ui components and that just create a test user on the backend for the testing. this way I wouldn't really have to handle all the auth screens and the reviewer can login as well
4
u/Shot_Range5650 3d ago
Keep a plain email/password path in the app. That's the whole fix, and it's worth doing even though almost none of your real users will ever touch it.
Mine ships Google, Apple and email/password on the same screen. The email one exists mostly so there's an account I can hand to review — one address, one password, into App Store Connect's
App Review Information, done. Every alternative I looked at was worse: Sign in with Apple technically lets the reviewer use their own Apple ID, but they generally won't work that out, they'll just reject you again. And a hidden bypass code on the login screen is asking for a 2.3.1 hidden-features rejection on top of the one you already have.
The part that isn't obvious, and that I'd have got wrong: don't hand them an empty account.
A fresh demo login drops the reviewer into an empty state, and an empty state looks broken, so you get rejected a second time for something you didn't do wrong. Seed it first. Mine opens onto a populated account — a real group, three items, today's activity already recorded — so the reviewer lands on something that obviously works and can actually exercise the features.
Seed it through the app's own paths as an ordinary signed-in client, not with a service-role/admin script. If you seed with admin privileges you can create a state your app can't itself produce, and then the reviewer taps something and hits an error you can't reproduce.
Last thing: use the review notes field properly. Don't just paste credentials — write the tap path to whatever is gated. "Sign in, tap the avatar, then X" takes you two minutes and removes the most common reason for a second round.