Apple file provider!!

[philocalyst]

Description

• This brings integrate with the apple file provider API rather than using FUSE directly, allowing for deeper system integration!
• I am putting it up for early review, very early stage... needs more extensive testing then what I have done.
• Based it nearly entirely on surrounding implementations.

Related Issue

Closes #

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to change)
• 📚 Documentation update
• 🌍 Translation (new language or translation update)
• 🔧 Refactoring (code change that neither fixes a bug nor adds a feature)
• 🧪 Tests (adding or updating tests)

Changes Made

Testing Performed

• Tested on Linux
• Tested on macOS (limited way! These things are complicated)
• Tested on Windows
• Tested in development mode (npm run tauri dev)

Screenshots

Checklist

• My code follows the project's code style
• I have run npm run lint:all and fixed any issues
• I have updated the documentation if needed
• My changes don't introduce any new warnings
• I have tested my changes thoroughly

Additional Notes

[philocalyst]

@Hakanbaban53 Do you have a mac?

[Hakanbaban53]

I I don't have a physical Mac, but I run a macOS virtual machine using QEMU. I use it to test rclone-manager (Build, tests and other thinks)

[Hakanbaban53]

Hey @philocalyst, thank you so much for putting this together!

Moving away from legacy macFUSE to a native Apple File Provider is a massive UX upgrade for macOS users, and I really appreciate the heavy lifting you've done here with the Rust bridge and Tauri bindings.

I am going to spin up my macOS virtual machine to test the file enumeration and materialization flows. I'll review the new Angular service alongside the backend changes, and I'll push any required tweaks directly to this branch.
Thanks again for the awesome contribution!

[gh0sti]

Any updates on this feature? @philocalyst and @Hakanbaban53

[philocalyst]

I understood that it was handedoff to @Hakanbaban53, but I can fix conflicts!

[Hakanbaban53]

@gh0sti @philoclyst I can provide an update on this:

When using standard Rclone RC endpoints, everything relies on HTTP requests (for directory listings, streaming, etc.) because there is no native way to pass and register all filters, mount options, and extra flags via standard RC calls.

However, on the librclone side (which powers the Android implementation with SAF), I wrote several patches to handle external management, which works cleanly and keeps things well separated. The plan for iOS is to follow this exact same approach.

macOS requires slightly different handling, though rclone serve should work well since it shares similar configurations with mounts. One constraint on my end is that I don't own physical Mac hardware and rely on a macOS VM inside VMware, which makes compiling and testing Rust code relatively slow.

@philoclyst I recommend holding off on resolving the merge conflicts for now. I'm currently working on another branch for workflow support:

Because there are substantial changes underway, especially on the Rust side, I'll circle back to look into this right after the v0.3.3 release.