Compose a clear sign-in flow around authentication supplied by the application.
Login establishes access to an account. Ask people to sign in when the task requires an identity, and explain why when that requirement is not obvious. Keep the route back to the original task clear.
Liquidify supplies interface controls. It does not provide account verification, sessions, passkeys, identity-provider integration, or account recovery. Those capabilities belong to the application and its authentication service.
For credentials, use a native form with labeled TextFields and a submit Button. A single-line TextField with secure renders a password input; this masks the display but does not authenticate or protect transport by itself. Use meaningful name attributes and supported autoComplete values such as username and current-password so browser and password-manager behavior can be tested.
Use a Link for an existing recovery destination or a Button for a supported authentication action. Present provider or passkey options only when the application's authentication integration supports them. A native platform capability described by Apple is not automatically available through a Liquidify prop.
Figure in preparation
Login: interaction sequence
Authentication happens outside the interface controls.
An authentication redirect is an application boundary. If the person returns without completing it, show the sign-in options again and explain that sign-in did not finish. Do not treat the return navigation alone as proof of success.
Use a waiting label such as “Signing in” and suppress duplicate requests while the application is checking credentials. On failure, restore the action and give a useful explanation without exposing account information the service intentionally withholds. Preserve the account identifier when appropriate; handle secret retention according to the authentication integration.
Distinguish an unsuccessful sign-in from a connection problem or an expired session. Offer recovery only through a functioning route. For an expired session during another task, preserve recoverable draft work according to the product's data policy and explain what can be resumed after sign-in.
Use “Sign in” for access to an existing account and “Create account” for registration. Name the available authentication method accurately. Avoid promising automatic access after a submission that still needs another verification step.
Explain any next step with enough context to complete it, such as checking an email inbox. Delivery, expiration, and resending remain service responsibilities; the UI must reflect their actual state.
Keep visible labels and native input semantics. Permit paste and review password-manager autofill rather than replacing those interactions with custom key handling. Make recovery links reachable by keyboard and announce failures without repeatedly announcing the whole form.
After a failed attempt, keep focus where the person can recover. After a successful route change, place attention at the destination's appropriate heading or task context. Test zoom, long translated labels, and the browser keyboard over the sign-in fields.
Read Forms, TextField, Button, and Link. Use Notifications for recoverable in-page messages.