Do I need to support passwordless on iOS, Android, and web?

Not necessarily — it depends on your users, your auth goals, and your product constraints.

Short answer

If you want a broad passwordless experience, you should usually plan for:

• Web: yes, almost always
• iOS: yes, if you have a mobile app
• Android: yes, if you have a mobile app

But you don’t always need all three on day one.

How to decide

Support all three if:

• Your product is cross-platform
• You want a consistent login experience everywhere
• You’re using:
  • Passkeys/WebAuthn
  • Magic links
  • OTP via email/SMS
• You expect users to sign in from multiple devices

You can start with fewer if:

• You’re launching MVP
• Your users primarily use one platform
• You’re using a flow that’s platform-specific

For example:

• Web-only SaaS: web support may be enough initially
• Mobile-first app: start with iOS/Android, add web later
• Internal tool: support only the platforms your org uses

Important nuance: what “passwordless” means

Different passwordless methods have different platform implications:

• Passkeys: best cross-platform story, but implementation details vary by OS/browser
• Magic links: easy on web and mobile, but app handoff can be tricky
• One-time codes: easiest to support everywhere, but less secure/less elegant than passkeys
• Biometrics: usually a layer on top of passkeys or device unlock, not a standalone auth system

Practical recommendation

If you’re building a consumer-facing product, the safest path is:

1. Support web
2. Support iOS and Android if you have native apps
3. Prefer passkeys as the primary passwordless method
4. Keep email OTP / magic link as fallback

Rule of thumb

• No native apps? Web is enough.
• Native apps? You should strongly consider iOS + Android support.
• Want the best UX/security? Aim for all three.

If you want, I can also give you a decision matrix for passwordless support by product type (SaaS, consumer app, enterprise, etc.).