Before asking Rork for Apple and Google sign-in, I went looking for steps that weren't mine to take

When I wanted to add sign-in to an app, I nearly opened the Apple Developer portal and the Google Cloud console first. Sign in with Apple needs a Services ID, Google needs an OAuth client — that was my memory from wiring it by hand as an indie developer. Before I had both tabs side by side, I stopped and wondered whether asking Rork would be enough.

Here's the short answer: in Rork's official docs, nothing in Apple Developer or Google Cloud is listed as your job for Google and Apple sign-in. That doesn't mean there's nothing left for you, though — there are decisions to make and things to check before review.

One caveat. This article rests on reading the official Rork Auth page. I haven't shipped a production app with it. What I did run myself is the duplicate-model check near the end, on a mock project.

What Rork takes care of

According to the docs, Rork Auth adds Google and Apple sign-in with no setup and no backend. When you ask in chat, the agent:

• creates the keys and adds the sign-in screen
• persists the session (Keychain for Swift, SecureStore for Expo, localStorage for web)
• adds five environment variables: EXPO_PUBLIC_RORK_APP_KEY, EXPO_PUBLIC_RORK_AUTH_URL, EXPO_PUBLIC_PROJECT_ID, RORK_AUTH_URL and RORK_AUTH_SECRET_KEY

The page states you don't create a Google client in Google Cloud, configure Sign in with Apple in the Apple Developer portal, or run a backend. My urge to open those consoles was a habit from another approach.

What stays with you

Choose one model

The docs say a project uses one of them, never both. Mixing them leaves users in two sets of tables, and switching later means existing users sign up again.

Rork Auth supports only Google and Apple, with no extra questions inside sign-in and no account migration. For email and password, magic links or phone codes, you want Supabase Auth — and there you should set your own mail sender before real users arrive, since Supabase's default confirmation emails come from a generic address with limited volume.

Three things reviewers look at

The docs list: don't ask for the name and email again after Apple sign-in, accept hidden emails such as @privaterelay.appleid.com, and keep the Apple button as prominent as the Google one. Check the generated screen for all three before publishing.

Testing notes

Sessions survive app reinstalls, so use the in-app sign-out button while testing.

Check you haven't mixed two models

If a project already has Supabase email sign-in and you add Google/Apple on top, two models end up side by side. The docs mention that empty screens after sign-in usually come from data rules written for the wrong user model (user_id() versus auth.uid()).

This script lists where each model's traces appear in a project folder:

import pathlib, re, sys
 
root = pathlib.Path(sys.argv[1])
rork_pat = re.compile(r"RORK_AUTH_URL|RORK_AUTH_SECRET_KEY|EXPO_PUBLIC_RORK_APP_KEY")
supa_pat = re.compile(r"supabase\.auth\.(signUp|signInWithPassword|signInWithOtp|signInWithOAuth)|auth\.uid\(\)")
hits = {"rork": [], "supabase": []}
 
for p in root.rglob("*"):
    if p.suffix not in {".ts", ".tsx", ".js", ".sql", ".env", ".swift"} or "node_modules" in p.parts:
        continue
    text = p.read_text(errors="ignore")
    if rork_pat.search(text):
        hits["rork"].append(str(p.relative_to(root)))
    if supa_pat.search(text):
        hits["supabase"].append(str(p.relative_to(root)))
 
print("Rork Auth traces    :", hits["rork"] or "none")
print("Supabase Auth traces:", hits["supabase"] or "none")
if hits["rork"] and hits["supabase"]:
    print("WARNING: both present. Check whether users are split across two tables")

On a mock project with one file reading the Rork Auth variable and another calling signInWithPassword, it printed the warning. Treat the output as a prompt to decide which model to keep, not a verdict.

A starting prompt

Add Google and Apple sign-in with Rork Auth.
Do not use email and password sign-in.
After sign-in, build a profile screen with a sign-out button.

The second line leaves the agent less room to add another method.

Say out loud which one auth model you're using before you ask. That's the rule I'm trying to keep ahead of opening any console.

For the hand-built Supabase route, I wrote up the details in the Sign in with Apple implementation guide. And the next time you add sign-in, run the script once on the project folder before sending the request.