This can mostly be compared side-by-side to FLALocalAuthPlugin_Test.h

This should be renamed in a follow-up; I didn't rename it here because there are enough changes that git would probably not show it as a diff, making review harder.

This should always have been here, but transitive includes in Obj-C masked the missing include.

I removed NSObject from all the test implementations since the protocols aren't Obj-C now, so it was just cruft.

All the Pigeon-generated type names changed because there's no more prefixing.

This was unfortunate, but it was the best I could come up with to fix all the warnings without significant restructuring. Without this, the places where we dispatch from a potentially-background-thread-callback back to a main thread call to a method on self triggers warnings about self not being Sendable.

There are ways to fix that with more static methods, passing more state around instead of using self, etc., but they would require refactoring that I didn't want to combine with the language conversion as it would have made side-by-side review nearly impossible.

I think let's keep @unchecked Sendable for now. I plan to look closer into Swift concurrency later this year

This branch is new. In Obj-C, we just assumed the docs weren't lying about the error being set if it returned false, but that's not type safe in Swift, and since docs have lied about nullability before I wanted a fallback instead of a crash from force-unwrapping.

This branch is new. We were failing to handle the case where there is no view before, so I added minimal handling for now.

This branch is new. We were failing to handle the case where there is no view before.

We could fail like on iOS (see below), but since macOS has a simple way to handle showing an alert without a view I went with that option.

This branch is new, for the reason described here.

curious if this also conforms to the protocol:

func canEvaluatePolicy(_ policy: LAPolicy, error: inout NSError?) -> Bool

The goal is to match LAContext, and what I have here is the signature according to Apple:

https://developer.apple.com/documentation/localauthentication/lacontext/canevaluatepolicy(_:error:)

nit: XCTAssertEqual(successDetails.result, .success)

Done throughout.

here and other tests - we can mark the function signature as throws, and remove this do/catch block

Done throughout.

nit: separate lines for each items

(https://google.github.io/swift/ -> Line-Wrapping -> "Comma-delimited lists are only laid out in one direction: horizontally or vertically. ")

Done. I forgot swift-format annoyingly doesn't handle this.

nit: use class unless we need value semantics of struct (since struct comes with overhead)

What's the overhead? I thought it was the opposite; https://developer.apple.com/documentation/swift/choosing-between-structures-and-classes#Overview says to prefer structs by default.

What's the overhead?

Value types increase both build time and binary size. Though Apple has improved it over the years, so it shouldn't be our key consideration.

The key consideration is whether we want value or reference semantics (which should be the "control identity" in the link you provided)

For example, factories in general should be reference types, because they often share state, so we don't want multiple factories. This particular factory is stateless, so not the end of the world, but still, semantically we don't want multiple factories when passing it around.

The next example is more interesting:

struct DefaultAlertController {
    var controller: UIAlertController
}

If we use value type like here, imagine this code:

let c1 = DefaultAlertController(...)
let c2 = c1

Then we have 2 separate values (c1 and c2), but both pointing to the same underlying UIAlertController, which is conceptually misleading (it looks like you have created 2 distinct controllers, but you haven't).

Makes sense! Changed all of them.

nit: return in success to reduce indentation?

if success {
  handle...
  return
}
...

Done.

nit: can infer these (e.g. case .biometryNotAvailable)

Done.

nit: infer type

and below

Done.

we can mark the whole protocol @MainActor so no need each function. (same below)

This is problematic until we annotate both Pigeon-generated methods and the FlutterPlugin registration methods as @MainActor, because it cascades through other code that ends up in places like the creation of the default implementations in register(with:), which aren't annotated @MainActor even though in practice they are.

It's much easier for now to annotate the specific methods.

nit: add a blank line between each members (same below)

Done

The goal is to match LAContext, and what I have here is the signature according to Apple:

https://developer.apple.com/documentation/localauthentication/lacontext/canevaluatepolicy(_:error:)

Done throughout.

Done throughout.

Done. I forgot swift-format annoyingly doesn't handle this.

Makes sense! Changed all of them.

Done.

This is problematic until we annotate both Pigeon-generated methods and the FlutterPlugin registration methods as @MainActor, because it cascades through other code that ends up in places like the creation of the default implementations in register(with:), which aren't annotated @MainActor even though in practice they are.

It's much easier for now to annotate the specific methods.

Done

Done.

Done.

nit: these classes can all be final

Done.

thanks. not straightforward but interesting name

I think you have to put [weak self] in outer closure context.evaluatePolicy, otherwise it would remain strong when outer closure is still alive.

Makes sense; done.

nit: this is a good use case for guard let

Converted to guard.

nit: can be let result: AuthResult (prefer immutability). This will fail to compile if any of the case below forget to set the result.

Done. I didn't know Swift could do this to; I'm a big fan of the pattern in Dart.

nit: blank line between each members. Also wanna add doc comments?

Done.