Thanks for the PR!

If we're going to support this plugin on Linux and Mac, we should probably come up with a documented behavior for all the methods. Would you like to take a crack at the other ones?

It feels like the approach of doing some of the work in Dart and some work in native-land might become challenging to maintain over time, but I do see value in offering this package to desktop developers.

See also #1566

@collinjackson Sure thing! I'll see what I can do.

The reason it is split right now between dart and native land is because there is no official way for plugin maintainers to add plugin desktop support that i am aware of, and each plugin comes but with their own way. If there was an official way to publish a plugin package to support desktop with platform channels then i agree it should go there an be in Dart.

The desktop platforms have platform channel support, it's just not stable yet. Working around that within the official plugin repository is not the right path forward here (and won't be possible in general, so this doesn't establish an approach that can be replicated). Instead we should be adding desktop support the right way, as the APIs stabilize and the tooling for pulling the native sides matures.

If people experimenting with desktop before things stabilize want to use a plugin, they can implement the native side locally using the current platform channel support, or in cases like this they can do the workarounds themselves in their Dart code above the level of the plugin's Dart code.

@AppleEducate seems like this one should live here for now

@AppleEducate seems like this one should live here for now

An actual implementation of path_provider (#1716 for instance) could be staged in the FDE repo. This PR isn't a correct implementation though (${Platform.environment['HOME']}/.config is not the documents directory on macOS, for instance).

@stuartmorgan maybe worth moving #1716 to FDE repo? I wasn't aware of this PR and was about to start reimplementing the same. IMO having desktop "adapters" for plugins in FDE repo is totally working

This PR isn't a correct implementation

I should have been more specific in first comment, I meant actual implementation of path_provider in swift, so agree

@stuartmorgan maybe worth moving #1716 to FDE repo?

Yes, I'll do that now. Honestly I just forgot I hadn't moved it (at the time it needed a Dart change since there was a Dart-side whitelist-style platform check on at least one method, so it wasn't trivial to move to FDE like the others were, and I never followed up on doing just that Dart change; it turns out to be gone now anyway).

This PR isn't a correct implementation though (${Platform.environment['HOME']}/.config is not the documents directory on macOS, for instance).

@collinjackson I would recommend closing the PR given this.

Closing per @stuartmorgan's recommendation.