feat: init SwiftUI library for FirebaseAuthSwiftUI

[russellwheatley]

Work in progress

[morganchen12]

Overall looks good. Had one architecture question for consideration.

[morganchen12]

Everything that's marked TODO can be done in a future PR.

[peterfriese]

This computed property does a lot. It is trying to sync with ATTrackingManager.trackingAuthorizationStatus, and also drives showUserTrackingAlert and limitedLogin.

We should simplify this.

[peterfriese]

Here is an alternative solution that feels cleaner:

  @State private var showUserTrackingAlert = false
  @State private var trackingAuthorizationStatus: ATTrackingManager.AuthorizationStatus = .notDetermined

  var isLimitedLogin: Bool {
    trackingAuthorizationStatus != .authorized
  }

  public init() {
    _trackingAuthorizationStatus = State(initialValue: ATTrackingManager.trackingAuthorizationStatus)
  }

  func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
      Task { @MainActor in
        trackingAuthorizationStatus = status
        if status != .authorized {
          showUserTrackingAlert = true
        }
      }
    }
  }

[russellwheatley]

updated to reduce scope of binding: 0d5d8ba (#1237)

Not sure if you agree but a binding was still needed to stop toggle from switching if limited login wasn't possible.

[peterfriese]

Instead of making assumptions about the grace period, it'd be better to make the call and handle the error.

See https://github.com/peterfriese/IdentityKit/blob/a9383206ef3dce073e3b64b6828ccb8d3b77315b/Sources/IdentityKit/Service/AccountService.swift#L68

[russellwheatley]

Thanks for that, that's a much cleaner approach so I have leaned heavily on it and will use that for reauthenticate operations for other providers. I have tweaked it slightly by keeping it swiftui and removing the password prompt via UIKit:

16131d6 (#1237)

[peterfriese]

Looking good. I left a few comments, happy for you do address them in a follow-up PR.

I'd also like to see the following:

1. Previews for all views. At the moment, it's not possible to preview the views, which makes it difficult to judge the design.
2. Package.swift files for the individual modules (to support (1))

Approved provided my remarks are addressed in follow-up PRs.

[peterfriese]

TODO: please move the ContentView into a separate file to make it easier to find.

[peterfriese]

TODO:
Nit: I would prefer the following signature (here, and in general):

    Button {
    } label: {
    }

[peterfriese]

So this means that we'll always have Email/Password be the most prominent provider. I would advocate to allow users to instantiate EmailAuthView themselves via the providerButtons closure.

1. I think we should no longer promote Email/Password as the go-to auth provider. Passwords are inherently insecure, and we should promote more secure providers instead.
2. This gives developers more flexibility (e.g. put SiwA / SiwG first, and Email last)

[peterfriese]

I'm not super happy with the Swift suffix. Also, can we include Auth in the name? Same for the protocol(s).

This applies to all providers.

[russellwheatley]

Thanks, @peterfriese. Now the last bits of feedback have been resolved, and as discussed in the last meeting, I will merge this PR. I'll follow up with the further suggestions you've made with the exception of email/password View update. This is on hold until we have finalised solution for using View modifiers (See this PR). But I think we're all in agreement, users should be able to decide if they want email/password auth which will be opted-in (i.e. something like AuthService().withEmailPasswordSignIn()).