App login options: email, Google, Sign in with Apple or passkeys?

Short answer: For most small business apps, offer email sign-in (ideally with a passkey on top) plus one or two social options your customers actually use. If you add Google or Facebook login on iOS, Apple's guideline 4.8 says you must also offer an equivalent option with privacy features, and Sign in with Apple is the usual way to meet it. Whatever you pick, plan in-app account deletion from day one, because both app stores ask for it.

The five options side by side

Each sign-in method changes three things: how many people finish sign-up, how many support tickets you get, and how much work the backend needs.

Option	What the customer does	Strengths	Weak spots
Email and password	Types an address, picks a password, often confirms by email	Works everywhere; you own the account record	Forgotten passwords, reset emails landing in spam, password reuse
Email code or magic link	Types an address, taps a link or enters a code	No password to forget	Depends on fast email delivery; awkward if the mail app is on another device
Google or other social login	Taps one button, picks an account	Very quick on Android and the web	Triggers Apple's second-option rule on iOS; some people avoid linking accounts
Sign in with Apple	Taps one button, confirms with Face ID or Touch ID	Fast on Apple devices; can hide the real email	You may receive a relay address instead of the customer's real one
Passkey	Confirms with fingerprint, face or device PIN	Nothing to type or forget; resistant to phishing	Needs server work; some customers don't know what a passkey is yet

Passkeys are the newest piece. Apple's developer page describes them as synced through iCloud Keychain across Apple devices, and Android's documentation lists passkeys alongside Sign in with Google and passwords inside Credential Manager, the API Google recommends for sign-in in Android apps. In practice, a passkey works best as an upgrade offered after the first sign-in rather than the only door in.

What Apple actually requires (as of November 2026)

Guideline 4.8: the second login option

Apple's App Review Guidelines say that if your app uses a third-party or social login service (the examples given include Facebook Login, Google Sign-In and Sign In with LinkedIn) to set up or authenticate the user's primary account, you must also offer an equivalent login service that:

limits data collection to name and email address,
lets people keep their email address private when setting up the account, and
does not collect their interactions with your app for advertising without consent.

Apple's own design guidance for Sign in with Apple describes the private relay email and states that Apple doesn't use it to profile people, so most teams add that button to satisfy the rule.

There are listed exceptions. You don't need the extra option if your app only uses your company's own account system, if it's a business or education app where people sign in with an existing work or school account, or if it's a client for a specific third-party service such as a mail or social account. A booking app that only offers "email and password" is therefore outside 4.8 entirely.

Guideline 5.1.1(v): let people in without a login when you can

The same guidelines say that if your app doesn't include significant account-based features, people should be able to use it without logging in. For a restaurant menu app or a store locator, forcing sign-up before anything useful happens is both a review risk and a conversion killer. Apple's design guidance makes the same point from the user side: delay sign-in as long as possible and ask only in exchange for value.

Account deletion inside the app

If your app lets people create an account, Apple requires that they can start deleting it from inside the app, usually in account settings. Apple's support page adds detail worth building to:

deactivating the account alone isn't enough; the option must delete the account record and associated personal data,
if deletion finishes on your website, link straight to that page,
outside highly regulated industries, don't make people phone or email you to finish,
confirmation steps (such as a code to the account email) are fine, deliberate obstacles are not,
apps using Sign in with Apple should revoke the user's tokens through Apple's REST API when they delete.

Google Play has its own version: if your Android app allows account creation, you need an in-app deletion path and a web link where people can request deletion, declared in the Data safety form in Play Console. The web link matters because some people have already uninstalled the app.

Picking a combination for your type of app

Booking or loyalty app for one business: email code or email and password, then offer a passkey. Add Sign in with Apple only if you also add Google.
Consumer app with many casual sign-ups: Sign in with Apple plus Google, with email as the fallback for people who use neither.
Staff or field-team app: your company's own accounts, or Microsoft or Google work accounts, which falls under Apple's business-app exception.
App with a web version: whatever you choose must also work in the browser. Apple notes that Sign in with Apple can be offered on non-Apple platforms, including the web, so customers aren't stranded on a laptop.

One practical trap: a customer who signed up with Sign in with Apple and chose to hide their email will have a relay address in your system. If they later try "forgot password" with their real address, they won't be found. Show which method an account uses ("You signed in with Apple") on the account screen, and support linking methods if your audience switches devices often.

Requirements checklist before you build or resubmit

[ ] Listed every sign-in method per platform (iOS, Android, web)
[ ] If any social login is on iOS, an equivalent privacy-focused option is also present
[ ] Core features that don't need an account work without one
[ ] In-app "Delete account" in account settings, deleting data rather than only deactivating
[ ] Web page for deletion requests, linked in the Play Console Data safety form
[ ] Token revocation wired up for Sign in with Apple accounts
[ ] Account screen shows the sign-in method in use
[ ] Passkey offered after first sign-in, with the old method kept as fallback
[ ] Demo account details ready for app review if features sit behind login
[ ] Email deliverability tested for codes, links and reset messages

FAQ

Do I have to use Sign in with Apple at all?

No. It becomes the practical choice only when you offer a third-party or social login on iOS. An app that uses only its own email-based accounts doesn't need it under guideline 4.8.

Can passkeys replace passwords completely?

Technically yes, but most small apps keep email sign-in as a fallback for customers on older devices or shared phones. Offer the passkey as the faster route and let it become the default over time.

Is a "Deactivate account" button enough for review?

No. Apple's guidance says offering only temporary deactivation is insufficient; people must be able to delete the account and its associated personal data.

Will the business know a customer's real email with Sign in with Apple?

Only if the customer chooses to share it. Otherwise you receive a unique relay address that forwards to their inbox, so build your customer records around that possibility.

If you're weighing which sign-in buttons belong in your app and want the deletion flow done properly the first time, send us a note about your app.