You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We don't copy implementations, since that would require maintaining two copies forever; instead we share them. See path_provider, shared_preferences, and video_player for some examples.
The first step in adding macOS support would be renaming the existing iOS package. Normally we use the name of the shared implementing framework; unfortunately in this case that's the LocalAuthentication framework, which would make the name local_auth_localauthentication. Given that I think we'll want to fall back to the less accurate, but more useful in distinguishing the implementation packages, local_auth_darwin.
(For anyone interested in doing this, renaming needs to be done in its own PR, without any macOS additions, and then adding macOS would be a follow-up PR once the rename has landed.)
Normally we use the name of the shared implementing framework; unfortunately in this case that's the LocalAuthentication framework, which would make the name local_auth_localauthentication. Given that I think we'll want to fall back to the less accurate, but more useful in distinguishing the implementation packages, local_auth_darwin.
/cc @jmagman in case you have any alternate thoughts for our latest installment of "Name That Shared iOS/macOS Code!" 🙂.
We don't copy implementations, since that would require maintaining two copies forever; instead we share them. See path_provider, shared_preferences, and video_player for some examples.
The first step in adding macOS support would be renaming the existing package iOS. Normally we use the name of the shared implementing framework; unfortunately in this case that's the LocalAuthentication framework, which would make the name local_auth_localauthentication. Given that I think we'll want to fall back to the less accurate, but more useful in distinguishing the implementation packages, local_auth_darwin.
(For anyone interested in doing this, renaming needs to be done in its own PR, without any macOS additions, and then adding macOS would be a follow-up PR once the rename has landed.)
Hi, I don't quite understand what you mean. Can you elaborate more on this statement with a simple explanation.
The first step in adding macOS support would be renaming the existing iOS package. Normally we use the name of the shared implementing framework; unfortunately in this case that's the LocalAuthentication framework, which would make the name local_auth_localauthentication. Given that I think we'll want to fall back to the less accurate, but more useful in distinguishing the implementation packages, local_auth_darwin.
I'm not telling you to do anything; what you choose to contribute is entirely up to you. I'm describing what we would accept for adding an endorsed macOS implementation of local_auth, which is a single package containing the shared iOS and macOS implementation.
The process for getting from the current state to that state is at least three separate PRs:
Rename local_auth_ios to something more generic, as described above.
Add macOS support to that renamed package.
Switch local_auth to using the new package instead of local_auth_ios.
The relative order of 2 and 3 isn't particularly important, but 1 must be done first.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
stuartmorgan-g commentedon Dec 28, 2023
We don't copy implementations, since that would require maintaining two copies forever; instead we share them. See path_provider, shared_preferences, and video_player for some examples.
The first step in adding macOS support would be renaming the existing iOS package. Normally we use the name of the shared implementing framework; unfortunately in this case that's the
LocalAuthenticationframework, which would make the namelocal_auth_localauthentication. Given that I think we'll want to fall back to the less accurate, but more useful in distinguishing the implementation packages,local_auth_darwin.(For anyone interested in doing this, renaming needs to be done in its own PR, without any macOS additions, and then adding macOS would be a follow-up PR once the rename has landed.)
stuartmorgan-g commentedon Dec 28, 2023
/cc @jmagman in case you have any alternate thoughts for our latest installment of "Name That Shared iOS/macOS Code!" 🙂.
OutdatedGuy commentedon Dec 28, 2023
Hi, I don't quite understand what you mean. Can you elaborate more on this statement with a simple explanation.
stuartmorgan-g commentedon Dec 28, 2023
I'm not sure what elaboration you are looking for. Which part isn't clear?
OutdatedGuy commentedon Dec 29, 2023
I didn't understand what you are telling me to do
stuartmorgan-g commentedon Dec 29, 2023
I'm not telling you to do anything; what you choose to contribute is entirely up to you. I'm describing what we would accept for adding an endorsed macOS implementation of
local_auth, which is a single package containing the shared iOS and macOS implementation.The process for getting from the current state to that state is at least three separate PRs:
local_auth_iosto something more generic, as described above.local_authto using the new package instead oflocal_auth_ios.The relative order of 2 and 3 isn't particularly important, but 1 must be done first.
depombo commentedon Jan 17, 2024
alexrabin-sentracam commentedon Mar 11, 2024
Just wanted to give y'all a quick update, I am awaiting approval on my pr and hopefully it gets merged soon!
Rimantovas commentedon Jun 2, 2024
flutter-triage-bot commentedon Jun 5, 2024
The
triaged-desktoplabel is irrelevant if there is noteam-desktoplabel orfyi-desktoplabel.[local_auth_darwin] macOS Support (#6267)
[local_auth] Endorse macOS (#7274)
github-actions commentedon Aug 20, 2024
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.[local_auth] Endorse macOS (flutter#7274)
[local_auth] Endorse macOS (flutter#7274)