How to add user login to your app.
Email, Google, and Apple.
Learning how to add user login to your app usually means working through JWTs, refresh tokens, password resets, social OAuth, and secure storage. With Newly you describe it in a sentence: “add login with email and Google.” You get email and password, Google, and native Apple Sign In running on Better Auth and Liquid Backend, with the React Native code in your project.
The five steps
How to add user login to your app, start to finish.
One prompt from you, four moves from Newly. You describe the login you want; the client, the hook, the backend, the secure storage, and the gate around your protected screens follow. Here is the sequence in order.
- 1
Prompt the AI for the login you want
There's no config screen to open. You type a sentence. Something like “add login with email and Google” is enough for Newly to scaffold auth into your project. That is what learning how to add user login to your app comes down to here: you describe the behavior and the AI assembles the libraries. Want Apple next to Google? Say so. Only email and password for now? Say that instead.
- 2
Newly generates the auth client and useAuth() hook
Behind that sentence, Newly writes the auth client – Better Auth with its Expo plugin – and an auth context that exposes a useAuth() hook. A component calls useAuth() to find out whether someone is signed in, who they are, and how to sign them out. The same pass generates API helpers that attach the user's token to outgoing requests, so your data calls go out authorized without you threading a token through every fetch.
- 3
The backend tables and /api/auth/* endpoints appear
Auth needs somewhere to live. On Liquid Backend, Newly creates the four tables Better Auth expects – users, sessions, accounts, verification – and the /api/auth/* endpoints in front of them. users is your people. sessions is who is logged in right now. accounts ties one person to each method they sign in with (email, Google, Apple). verification backs flows like email confirmation. It's ordinary Postgres you can query, not a schema you had to design.
- 4
Sessions persist in expo-secure-store on the device
Once a user signs in, the session sticks. Newly stores the JWT in expo-secure-store – the iOS Keychain, the encrypted Android Keystore – and the token rides along on each request for the server to check against the sessions table. Users stay logged in across restarts until they sign out. The reason that matters is below in the storage breakdown: the credential sits in OS-level secure storage, not the readable kind.
- 5
Wrap protected screens in the auth provider
The last step guards the screens that require an account. Newly wraps the app in the auth provider, and each protected screen checks useAuth() to decide what to render: the real screen for a signed-in user, a redirect to login for everyone else. Drop Google and Apple into the same flow and, on Liquid Backend, the buttons work straight away because the providers are already registered. That completes the loop, and the generated code is yours to edit.
What the prompt generates for you.
Much of how to add user login to your app feels hard because most of the work never shows up on screen. You write a prompt and that part gets written for you: the client, the hook, the tables, the secure storage, and the gate. You read the result, adjust what you want, and carry on building.
User logins, at a glance.
The auth library Newly wires in, with its tables and helpers generated
“Add login with email and Google” – Newly generates the rest
Email/password, Google, and native Apple Sign In on iOS
Persisted in expo-secure-store, generated and wired for you
What it is
Login is a system, not a screen.
The login screen is the part you see. Most of the work is the part you don’t. When people ask how to add user login to your app, what they actually need is a chain: a way to issue and refresh tokens, somewhere safe to store them on the device, a backend table that remembers who is signed in, and a gate in front of the screens that require an account. Break one link and you’ve got a form that looks like login but forgets everyone the moment they close the app.
Newly builds that chain for you. You write the prompt; the AI writes the client, the session storage, the tables, and the gate, and wires them together. The rest of this guide walks the chain link by link, so you can see what each piece does and adjust it when you need to.
The pieces
Five parts of login, all generated.
Ask how to add user login to your app and this is the parts list. Five files, each with one job. They land in your project as plain React Native and Postgres, so you can read any of them and edit them when you need to.
The auth client (Better Auth + Expo plugin)
The library layer that talks to your auth endpoints. Newly builds it on Better Auth and its Expo plugin, so the React Native side knows how to sign in, sign out, and read the current session. It arrives already pointed at your project's backend, so there's no library to choose or plugin to configure first.
The auth context and useAuth() hook
Where the login state lives. The generated auth context tracks who is signed in and exposes a useAuth() hook. Any screen calls useAuth() to read the current user or trigger sign-out, so “show this only to logged-in users” becomes a one-line check rather than a session object prop-drilled down the tree.
Authenticated API helpers
These keep your data calls authorized. Newly generates helpers that attach the user's JWT to every request as a bearer token, so the backend always knows who is asking. You write the fetch for your feature and the token plumbing is already taken care of.
Backend tables and /api/auth/* endpoints
On Liquid Backend, Newly creates the users, sessions, accounts, and verification tables and the /api/auth/* endpoints in front of them. This is the server side of login, sitting in your project's own database as tables you can query directly.
Secure session storage
Sessions persist as JWT bearer tokens in expo-secure-store – the iOS Keychain, the Android Keystore – so they survive restarts and stay out of readable storage. The generated code writes the token on login and the server checks it against the sessions table on every authenticated request after that.
Login methods
Email, Google, and Apple.
Email and password is the baseline every app starts with. The safety rails – password reset and email verification – are available on request rather than on by default, so ask for them when your flow needs them and Newly wires them in. Worth saying plainly, because a guide that implies verification you never turned on is just a support ticket waiting to happen.
Social login covers Google and Apple. Apple Sign In is the native iOS sheet, built with expo-apple-authentication, the same prompt iPhone users tap through a dozen times a week. Apple effectively requires it once you offer any third-party social login on iOS. On Liquid Backend, Google and Apple are already configured, so “add login with email and Google” works without you registering an OAuth app first.
What you won’t get on Liquid Backend is magic links. Passwordless email links are a Supabase feature, and on the Supabase backend the same social providers also want their OAuth credentials in the dashboard before they fire. The next section lays out exactly where the two backends part ways.
Two backends
Liquid Backend vs Supabase for auth.
Either one can run the login inside your app, and your users won’t be able to tell which you picked. The split is in setup. Liquid Backend is the bundled default and configures itself; Supabase is a one-click swap that then asks two things of you. The side-by-side below is the honest version.
Liquid Backend (bundled default)
Better Auth, configured for you.
- Better Auth wired up from the first run
- Google and Apple social login pre-configured
- users, sessions, accounts, verification generated
- Included, with no extra dashboard or API keys to copy
- JWT in expo-secure-store, validated server-side
Supabase (one-click swap)
Supabase Auth, with real setup steps.
- One-click swap in Newly project settings
- Same email, Google, and Apple methods
- Open Postgres with an exit door (pg_dump)
- Social providers need OAuth credentials set in the dashboard
- Tables need Row Level Security enabled to stay private
The short version: on Liquid Backend, Google and Apple work from a prompt. On Supabase, the same providers want OAuth credentials in the dashboard and Row Level Security on your tables. One-time configuration, but configuration all the same.
Generated vs by hand
What Newly generates vs what you’d write.
Rolling your own auth is about a month of focused work, and it lands on the one layer where a small mistake becomes a breach. The left column is what Newly writes for you. The right is the identical list, done by hand. The difference is mostly the time it takes.
Newly generates it
- Better Auth client with the Expo plugin, wired in
- Auth context and a useAuth() hook your screens read
- Authenticated API helpers that attach the bearer token
- users, sessions, accounts, verification tables generated
- /api/auth/* endpoints on Liquid Backend
- JWT stored in expo-secure-store, validated server-side
- Google and Apple pre-configured on Liquid Backend
- Native Apple Sign In via expo-apple-authentication on iOS
You write it by hand
- JWT issuing plus refresh-token rotation logic
- Secure token storage on both iOS and Android
- Password reset and email verification flows
- Google and Apple OAuth: redirect URIs, native sheet
- A sessions table and protected-route checks
- Edge cases: expired tokens, revoked sessions, linking
- On Supabase: OAuth credentials in the dashboard
- On Supabase: Row Level Security policies on every table
What it costs and what you get.
From $25 a month, Newly generates the full login stack on Better Auth and Liquid Backend and adds the React Native and Expo code to your project, where you can read and change it. Login isn’t metered per user.
FAQ
How to add user login to your app, answered straight.
You describe it in plain language. Tell the AI something like “add login with email and Google” and Newly scaffolds the whole stack: the auth client (Better Auth with its Expo plugin), an auth context with a useAuth() hook, authenticated API helpers that attach your token to every request, and the backend tables auth needs – users, sessions, accounts, and verification – plus the /api/auth/* endpoints behind them. The runtime is Better Auth on top of Liquid Backend, the backend bundled with every Newly project. You don't glue libraries together or design a session table by hand. You prompt, read what came out, and adjust the React Native and backend code directly.
Add login with a single prompt.
That is how to add user login to your app without losing a month to it. From $25 a month, Newly generates email, Google, and Apple sign-in on Better Auth and Liquid Backend, and the React Native code lives in your project.