Every mobile app needs a login screen, and every login screen is a place where users disappear. You spend weeks building features and designing interfaces. Then a user hits "Sign In" and leaves after forgetting their password. The user leaves without creating an error log or crash report.
Authentication choices for mobile apps shape both the sign-in experience and the costs an indie builder has to carry for security and providers. In a 2025 consumer survey, about half of people said they abandon a purchase when they forget a password for that account. For low-frequency apps like utilities or niche SaaS, that kind of abandoned login may never show up in your analytics. The right auth pattern can affect conversion alongside security posture.
Nine authentication patterns and when each one fits
Favor low-friction sign-in methods first, then add stronger controls where the app actually needs them.
Passkeys (FIDO2/WebAuthn)
Passkeys replace passwords with cryptographic key pairs stored on the user's device. The user approves sign-in with Face ID, a fingerprint, or a PIN. No password to forget. No code to type. FIDO Alliance materials describe major platform vendors and standards groups as steering toward passkeys as the default. Passkeys can satisfy NIST AAL2 when they combine something-you-have with biometric or PIN-based user verification. They are phishing-resistant by design.
Sign in with Apple and Sign in with Google
Social login through Apple or Google removes the sign-up form entirely. App Store guidelines require that iOS apps offering third-party social login also offer an equivalent login option that limits data collection and does not use data for advertising. Sign in with Google covers Android, iOS, and web with a single integration. Both providers can reduce the amount of authentication work your app handles directly.
Magic links
The user enters an email, receives a link, and clicks to authenticate. No password required. On mobile, users must leave your app to check email, which creates significant friction in a mobile-first context.
SMS OTP
A six-digit code sent via text message. Familiar to most users, but SP 800-63B-4 classifies SMS as a restricted authenticator due to SIM-swap and interception risk. Per-SMS costs also accumulate at scale. Use SMS as a second factor.
Email and password
The original pattern. Still recognized by users, but actively declining. Apple's WWDC guidance says any account where a password can still be used remains vulnerable to phishing and credential reuse. It is a weak choice as the only method for new apps.
Other patterns worth knowing
- TOTP (authenticator app codes): More secure than SMS, but high friction for non-technical users. Best for developer tools and B2B SaaS.
- Device biometrics (local authentication): Use device biometrics as a re-authentication layer to confirm user presence for sensitive actions.
- Push notification MFA: Low friction on mobile, but vulnerable to push bombing attacks. Best for internal tools with known user bases.
These methods work better as supporting controls than as the default login path for most consumer mobile apps.
Why passkeys are the clear winner for mobile
If you want one default choice for a new mobile app, passkeys have the strongest case. They reduce sign-in failure and speed up login, which means fewer abandoned sessions and fewer support issues.
A 2025 passkey industry index measured a 93% sign-in success rate for passkeys compared to 63% for all other methods. Median sign-in time dropped from 31.2 seconds to 8.5 seconds. Login-related support incidents fell by 81%.
Individual company results reinforce the pattern. X saw its login rate double after adding passkeys. Zoho reported faster logins and passkey adoption growth after implementation.
Mobile users are especially receptive. Authenticate 2025 deployment data showed 55-60% passkey adoption on mobile versus roughly 20% on desktop. Face ID and fingerprint unlock already feel familiar on phones, which makes passkey adoption feel natural.
Two platform updates accelerate this trend. The new Account Creation API lets users create an account and passkey in a single step, removing the password form from that flow. Automatic Passkey Upgrades create passkeys for existing password-based accounts when users sign in with a password. Those accounts can then use passkeys going forward. On Android, Credential Manager is the recommended API for authentication and is intended to replace legacy sign-in APIs.
Indie builders usually get passkey support through a hosted auth provider that handles WebAuthn server-side work rather than a DIY build.
What current security standards require from your app
SP 800-63B was withdrawn in July 2025 and replaced by SP 800-63B-4. Any guidance referencing the prior version is outdated. The new standard formally recognizes synced passkeys within its framework, including those stored in a sync fabric such as platform password managers.
Four requirements apply to nearly every app you ship:
- All auth communication must use TLS (HTTPS)
- Do not hardcode API keys in your app binary
- Do not store tokens or passwords in plaintext on the device
- Use platform APIs for authentication, not custom implementations (OWASP MASWE-0032)
Treat these as baseline controls. Miss them, and you create avoidable security and review problems before users ever see your product.
OWASP now flags the absence of passwordless authentication (MASWE-0035) as a distinct security weakness, which could affect security reviews or future enterprise customer requirements.
Apps handling sensitive health, finance, or identity data should generally target AAL2: authentication using either a multi-factor authenticator or two separate authentication factors, with at least one replay-resistant authenticator. Android security guidance recommends biometric auth for financial, healthcare, and identity management apps.
How to pick an auth provider without a pricing trap
Hosted auth saves time, but pricing cliffs turn provider choice into a migration decision. The free tier gets you started. The pricing cliff determines what happens during your first growth spike. The worst time to migrate auth is when your app is growing.
Provider comparison for indie budgets
Watch for usage limits, paid-only features, and low-traffic project behavior.
Firebase Auth includes common sign-in methods and is easy to start with. Phone and SMS behavior varies by plan. Low-traffic behavior can become part of the tradeoff at launch.
Supabase Auth supports social OAuth, anonymous sign-ins, and MFA. Free-tier project behavior matters if your app needs to stay continuously live, so review the current pricing before you commit.
Clerk uses monthly returning users as its billing model. Passkeys and MFA require the Pro plan.
Auth0 is often positioned for larger teams rather than lean indie budgets.
For builders concerned about lock-in, self-hostable tools can offer an alternative path.
Five auth mistakes builders find in production
Even with the right provider and pattern, implementation details trip up experienced builders.
Duplicate accounts from multiple sign-in methods. When you offer email login and Google login without account linking, a user who tries both gets two accounts. No error appears. The user just sees empty data. Use a provider that handles email-based account linking automatically.
Firebase magic links expose your project ID. The auth email reads "sign in to upfollow-4491b" with no customization option. For a consumer-facing app, that first impression can cost you the user.
Passkeys break across mismatched domains. If your web app authenticates at yourapp.com but the mobile app hits auth.yourapp-api.com, password managers treat them differently. Configure a custom domain that matches your main app domain.
SMS OTP creates lockout scenarios. Phone-number changes and carrier-side risk make SMS unreliable as a sole factor, especially when SIM-swap attacks are involved. SMS works best as a second factor, not the primary method.
Complex account structures slow you down. Start simple. Add roles and teams only when real users demand them.
Getting started with Anything
If you are building with Anything, start with the built-in auth stack so you can ship and test while you learn where sign-in friction appears. That path keeps early auth work smaller and leaves room to add more later if the product proves it needs it.
With Anything, you build apps iteratively: describe the idea, refine it through prompts, then ship. Built-in authentication includes JWT, Next Auth, and social login.
The same backend supports both web and mobile apps, so one auth setup can carry across both surfaces. Mobile deployment currently supports iOS via Expo, while Android is still in development. If your app needs social login on iOS, plan around Apple's App Store guidelines before choosing providers.
For more context, Check out Dirk's and William Sayer's story. If the built-in auth fits your first version, use it and learn from real sign-in behavior. If you need passkeys or a broader provider mix later, add them after you validate the rest of the app.
Get started with Anything and ship your first authenticated app this week. Pick the simplest auth setup that works for your users, then iterate based on what you learn from real sign-in data.
