Skip to main content
An app that keeps data per person needs accounts. Someone signs in, and from then on the app knows whose notes, orders, or photos to show. Rork has two ways to do that, and you pick one before the agent writes any of it. A magic link is the email that signs a person in when they tap it, with no password to remember.
One project uses one of them, never both. Each hands out its own kind of user ID. Your data rules read only one kind. Put both in one app and you get two sets of users in the same tables, so people start seeing empty screens. You can change your mind later, but anyone who already signed in has to sign up again.

​
Add Google and Apple sign-in

1

Ask for it in the chat

2

Let the agent build it

It creates the keys, adds the sign-in screen, and writes the part that keeps a person signed in between visits. It asks you for nothing, because there is nothing only you can provide.
3

Try it yourself

Sign in with your own Google or Apple account, right in the preview next to the chat. Sign-in works in the preview, in the simulator, and on a real phone.In the iOS simulator the Google or Apple window opens in your own browser, not inside the phone screen. The app then carries on as normal. On a real device everything stays inside the app.
4

Ask for what comes after sign-in

Four things people expect to do here, and do not:
  • You do not create a Google sign-in client in the Google Cloud console.
  • You do not configure Sign in with Apple in the Apple Developer portal.
  • You do not run a backend. Your app talks to Rork’s sign-in service directly.
  • You do not store passwords. Google and Apple check the person, so your app never sees one.
After sign-in, the app holds a pass that proves who the person is. It lasts one hour, and the app quietly gets a new one, so nobody is thrown out mid-task. The pass is kept in the safest place each platform has: The session survives deleting and reinstalling the app. So while you test, use the sign out button in your own app. Deleting the app does not sign you out.

​
Three Apple rules that are easy to break

Apple reviews the look and behaviour of Sign in with Apple, and rejects apps that get it wrong. Two of the three are things you might ask the agent for without knowing:
  • Do not ask for the name and the email again after somebody signs in with Apple. Apple already handed them to your app. A “complete your profile” screen that asks for them is a rejection.
  • Accept hidden emails. Apple lets people hide their real address and gives your app a relay address that ends in @privaterelay.appleid.com. If your app refuses that as invalid, it is a rejection.
  • Keep the Apple button as prominent as the Google one. Hide it below the fold, or style it as a small link, and Apple rejects that too.
The AI App Store Reviewer checks your build for these before Apple does. Run it before you submit.

​
What Rork Auth cannot do

  • Google and Apple only. No email and password, no magic links, no phone codes, no other providers.
  • No extra questions inside the sign-in itself. Collect anything else on a screen of your own, after sign-in. Mind the Apple rule above about the name and the email.
  • No way to move accounts across from another sign-in system.

​
The variables it adds

You never type these in. They are listed here so the project’s Secrets panel makes sense when you open it: Rork creates all five itself. The private key never appears in the panel, and the agent never asks you for any of them. Treat any request for these values as a mistake. See API keys and environment variables.

​
Email and password with Supabase Auth

Pick this one when Google and Apple are not enough, for example when your users are staff who have no Google account. It needs a Supabase backend on the project, see How to add a Supabase backend to Rork.
The agent connects the backend, adds the sign-up and sign-in screens, and handles the session.
Supabase sends the confirmation email itself, from a generic address, and it limits how many go out. That is fine while you test. Before real users arrive, set your own mail sender in the Supabase dashboard. Or ask the agent to switch confirmation off while you build.
Other providers, like Facebook or GitHub, also go through Supabase Auth rather than Rork Auth.

​
Why each person sees only their own data

A database on its own hands out any row to anybody who asks. What stops that is a set of rules on each table, which say “you may read this row only if it is yours”. Those rules need a way to say who is asking, and the name differs by model: The agent knows which one your project uses, and Rork rejects a database change that uses the wrong one. You never write this by hand. It is still worth knowing, because it explains the strangest bug in this area. A person signs in, everything looks fine, and every screen is empty. That is a rule asking for the wrong kind of user, so no row matches. Tell the agent what you see. Ask it to check the rules against the project’s sign-in model.

​
Change your mind later

Ask the agent, and name the model you want:
It turns the old one off, rewrites the data rules, and replaces the sign-in screens. Accounts do not move across, so do this before you have users, or tell them they need to sign up again.

​
FAQ

Not with Rork Auth. Google and Apple sign-in works with no backend and no database. You need a backend once you want to store what those people do in your app, see Do You Need a Backend for Your App?.
Not to build it or to test it. You need the $99 / year Apple Developer membership to publish the app at all, see Create your Apple Developer Account.
With Rork Auth, the sign-in runs on Rork’s service and your app receives the person’s ID and profile. Anything else you want to keep about them goes in your own database, under your own rules.
No. A project uses one model. If you need both kinds of sign-in, pick Supabase Auth and ask the agent to add Google there.
Yes. Sign in with your own account in the preview next to the chat, in the simulator, or on a real phone.
Yes. In a web app the sign-in happens in the browser and the session lives in localStorage. One project can hold an iPhone app, an Android app, and a web app, see Convert your app between iOS, Android, and web.
Yes. Add sign-in the same way, then keep each person’s rows behind the rules above. See What is Rork Cloud.
Almost always the data rules name the wrong kind of user, so every row is filtered out. Ask the agent to check the rules against the project’s sign-in model.

​
Next steps

Do you need a backend?

What accounts imply for your data, before you build.

Rork Cloud

A managed database and server functions inside Rork.

Supabase backend

Bring your own Supabase project, and its sign-in methods.

AI App Store Reviewer

Catch the Sign in with Apple mistakes before Apple does.