Currently, local_auth is a relatively thin wrapper around the underlying auth SDKs, with the outlier addition of the useErrorDialogs parameter (on by default) that shows native dialogs for a small subset of errors (mostly around not having auth enrolled). We should remove this parameter and the dialogs, for a number of reasons:

• Most importantly, it makes us more consistent with the direction we have been moving strongly toward in our plugins of having relatively minimal wrappers, and leaving any additional functionality to the community to build, to allow for diverse approaches to anything that doesn't have a specific required solution.
• The current implementation is inconsistent and has maintenance overhead (examples include [local_auth][iOS] useErrorDialogs= false still shows system dialog when locked out by system #117810 and [local_auth] "authenticate" with parameter "useErrorDialogs = true" does not open a dialog #96646, and the fact that Windows ignores the parameter).
• There is no specific reason for the dialogs to be part of the plugin flow; handling them separately would not add any overhead or impair UX (as compared with, e.g., image_picker downsampling, where doing it in the plugin avoids a lot of round-trip serialization of potentially large amounts of data).
• There is no reason the dialogs need to be native, or dialogs at all. If people really want that flow they could use a community plugin that shows native dialogs, but Flutter UI would be a perfectly good choice; it's odd for the plugin to be opinionated about this.
• The one thing the dialog currently does that actually needs platform code is the button that opens settings. However:
  • That step could easily be handled via another plugin (e.g., android_intent_plus on Android) while being UI-agnostic.
  • It is, again, inconsistent and problematic. On Android, there is a clear way to do this. On iOS, our implementation is actually wrong; it opens the app's settings, not the device security settings, and the only way to go to the right location is with an unsupported, undocumented, reverse-engineered URL scheme. That's not something we want to add to an official plugin, but may well be the best choice for individual app developers depending on their level of risk tolerance for it breaking in iOS updates. On macOS, we don't have support for it at all because the only way to open specific settings is undocumented and fragile.