[demolaf]

• Related to Customizable SwiftUI auth UI: content slots, per-screen state, and theming #1400

Adds public EmailAuthScreen, PasswordRecoveryScreen and EmailLinkScreen, so apps can draw the email sign-in screens themselves while the library keeps signing in, sending links, navigating and reporting errors. Builds on #1412.

⚠️ Breaking Changes

• AuthView gains signIn and signUp cases, so an exhaustive switch over AuthView needs a new branch or a default:.

Changes

• Each screen owns its input state and passes its content an EmailAuthContentState, PasswordRecoveryContentState or EmailLinkContentState: Bindings for input, closures for actions, plus isValid, isLoading and a localized errorMessage.
• DefaultEmailAuthContent, DefaultPasswordRecoveryContent and DefaultEmailLinkContent hold the stock markup, and EmailAuthView, PasswordRecoveryView and EmailLinkView now render them through the screens.
• signIn and signUp route MFA and account conflicts to their handlers like the phone screens, and every action ignores taps while invalid or loading.
• Add AuthView.signIn and AuthView.signUp routes, shown by default as SignInView and SignUpView, reached with AuthMethodPickerState.goToEmailSignIn and EmailAuthContentState.goToSignUp. They close once signed in, and EmailAuthScreen(flow:) fixes a screen's flow; the stock first screen still toggles in place.
• Password recovery failures are now reported to the sheet's error alert instead of being dropped silently.
• Pressing Go in the password field while signing up now moves to Confirm password instead of starting a sign-in.

API Usage

AuthPickerView { authenticatedApp }
  .pickerContent {
    EmailAuthScreen { state in
      TextField("Email", text: state.email)
      SecureField("Password", text: state.password)
      if let errorMessage = state.errorMessage {
        Text(errorMessage)
      }
      Button("Sign in", action: state.signIn)
        .disabled(!state.isValid || state.isLoading)
      Button("Forgot password?", action: state.goToPasswordRecovery)
      Button("Create account", action: state.goToSignUp)
    }
  }
  .pickerDestination { screen in
    switch screen {
    case .passwordRecovery:
      PasswordRecoveryScreen { state in
        DefaultPasswordRecoveryContent(state: state)
          .background(.yellow.opacity(0.1))
      }
    case .signUp:
      EmailAuthScreen(flow: .signUp) { state in
        DefaultEmailAuthContent(state: state)
      }
    default:
      DefaultAuthPickerDestination(screen: screen)
    }
  }

Preview

---

Maintainer note: Fixes internal CPRN-519

[gemini-code-assist]

Code Review

This pull request refactors the authentication views by introducing state-driven screen components (EmailAuthScreen, EmailLinkScreen, PasswordRecoveryScreen) to decouple UI from business logic. The review identifies several high-severity issues regarding potential race conditions when capturing email state in asynchronous tasks and inconsistencies in email validation logic. Additionally, medium-severity feedback suggests improving user experience by disabling submit buttons during loading states.

[gemini-code-assist]

Capturing email dynamically inside the asynchronous Task can lead to race conditions if the user edits the text field while the request is in flight. If the email is modified before the request completes, the wrong email address will be saved to authService.emailLink, which will break the email link sign-in flow when the user opens the link. Capture the email address locally before starting the Task to ensure consistency.

  private func sendSignInLink() {
    guard isValid, !isLoading else { return }
    let emailToSend = email
    isWorking = true
    errorMessage = nil
    Task {
      defer { isWorking = false }
      do {
        try await authService.sendEmailSignInLink(email: emailToSend)
        didSend = true
        authService.emailLink = emailToSend
      } catch {
        errorMessage = authService.string.localizedErrorMessage(for: error)
        reportError?(error)
      }
    }
  }

[gemini-code-assist]

There is an inconsistency in email validation. The screen uses CommonUtils.isValidEmail(email) to enable/disable the submit button, while the text field in DefaultEmailLinkContent uses FormValidators.email for inline validation. This can lead to cases where the button is enabled but the field shows an error, or the button is disabled with no error shown. Use FormValidators.email.isValid(input: email) to ensure consistent validation across the UI. Note that you will also need to add import FirebaseAuthUIComponents at the top of this file.

Suggested change

	private var isValid: Bool {
	CommonUtils.isValidEmail(email)
	}
	private var isValid: Bool {
	FormValidators.email.isValid(input: email)
	}

[gemini-code-assist]

There is an inconsistency in email validation. The screen uses CommonUtils.isValidEmail(email) to enable/disable the submit button, while the text field in DefaultPasswordRecoveryContent uses FormValidators.email for inline validation. This can lead to cases where the button is enabled but the field shows an error, or the button is disabled with no error shown. Use FormValidators.email.isValid(input: email) to ensure consistent validation across the UI. Note that you will also need to add import FirebaseAuthUIComponents at the top of this file.

Suggested change

	private var isValid: Bool {
	CommonUtils.isValidEmail(email)
	}
	private var isValid: Bool {
	FormValidators.email.isValid(input: email)
	}

[gemini-code-assist]

Capturing email dynamically inside the asynchronous Task can lead to race conditions if the user edits the text field while the request is in flight. If the email is modified before the request completes, the wrong email address will be saved to sentEmail, displaying the incorrect email in the success sheet. Capture the email address locally before starting the Task to ensure consistency.

Suggested change

	private func sendResetLink() {
	guard isValid, !isWorking else { return }
	isWorking = true
	errorMessage = nil
	Task {
	defer { isWorking = false }
	do {
	try await authService.sendPasswordRecoveryEmail(email: email)
	sentEmail = email
	didSend = true
	} catch {
	errorMessage = authService.string.localizedErrorMessage(for: error)
	reportError?(error)
	}
	}
	}
	private func sendResetLink() {
	guard isValid, !isWorking else { return }
	let emailToSend = email
	isWorking = true
	errorMessage = nil
	Task {
	defer { isWorking = false }
	do {
	try await authService.sendPasswordRecoveryEmail(email: emailToSend)
	sentEmail = emailToSend
	didSend = true
	} catch {
	errorMessage = authService.string.localizedErrorMessage(for: error)
	reportError?(error)
	}
	}
	}

[gemini-code-assist]

The submit button is not disabled when state.isLoading is true. Although the screen's submit logic guards against multiple submissions, disabling the button during loading provides a better UX and prevents redundant tap interactions.

Suggested change

	.disabled(!state.isValid)
	.disabled(!state.isValid || state.isLoading)

[gemini-code-assist]

The submit button is not disabled when state.isLoading is true. Disabling the button during loading provides a better UX and prevents redundant tap interactions.

Suggested change

	.disabled(!state.isValid)
	.disabled(!state.isValid || state.isLoading)

[gemini-code-assist]

The submit button is not disabled when state.isLoading is true. Disabling the button during loading provides a better UX and prevents redundant tap interactions.

Suggested change

	.disabled(!state.isValid)
	.disabled(!state.isValid || state.isLoading)