loginWithApple

The Apple authorize URL to open in a browser. See loginWithGoogle for how to open it and why the result must not be cached — the two are the same flow with a different provider key.

Sign in with Apple identifies end users differently, and an app offering more than one method has to account for it. Portal identifies an end user by email address, and Apple lets the user hide theirs: choosing Hide My Email sends Portal a @privaterelay.appleid.com address, and that relay address is what Portal stores. The same person is then two end users, with two clients and two wallets — one for the relay address, one for the real address they used with Google or a magic link. Relay addresses are stable, so an Apple-only user is consistent with themselves; the divergence appears only when one person uses two methods. Do not assume a person maps to one end user regardless of how they signed in.

Apple also supplies the email only on the user's first consent for a given Service ID. A user who previously consented under a different Service ID gets no email, and the sign-in fails because Portal cannot identify them — so changing the Service ID is a breaking change for existing users, not a configuration detail.

Throws