maple-file is a Flutter client with a Go file service baked in, aimed at many backends at once

A Go service inside a Flutter shell

The architecture is unusual enough to be worth stating first. The client is built with Flutter, and the file management capability is provided by an embedded Go service. On the Go side, the storage drivers are currently built uniformly on top of the honmaple/cloudfs project, and the repository no longer maintains a large batch of local protocol driver implementations, preferring instead to reuse the native drivers and middleware capabilities of cloudfs directly. That is a consolidation decision rather than a technical necessity, and it has consequences. The repository no longer carries its own protocol implementations, so the set of backends it can support is effectively the set cloudfs can talk to, and the project has traded some independence for much less duplicated code. The repository layout reflects the split, with the Flutter application under app/, the Go service under server/, a proto/ directory for the interface between the two, and example/ holding the screenshots the README shows.

The storage list is long, and uneven

The supported backends are the core of the product, and the list is a mix of protocols, products and network drives. The ASCII entries cover the common ground:

   - [X] FTP
   - [X] SFTP
   - [X] S3
   - [X] SMB
   - [X] Webdav
   - [X] Foxel

Alongside them are local files, Alist and OpenList, Google Drive, OneDrive, and a set of regional network drives and mirrors. What matters more than the length is that the support is not uniform, and the README says so in a capability matrix with one column per operation: listing, creating a directory, renaming, moving, copying, deleting, uploading and downloading. Most backends have every box ticked. The exceptions are informative. The 115 drive has no upload. The Quark drive has no copy and no upload. GitHub, GitHub Release and the mirror source are read only, offering listing and download but nothing else. So the tool is best understood as a multi protocol browser and downloader with write support wherever the backend allows it, rather than as a uniform client.

Serverless means the credentials travel with the device

The project's tagline is that it is a serverless multi protocol cloud drive application, and the README repeats the point in its feature list by supporting Web, Android, macOS and Windows. What that means in practice is visible in the architecture. There is no central account and no cloud service of the project's own; the Go service travels with the app on whichever device you run it, and it talks to your storage with your credentials. The upside is straightforward. Nothing is uploaded to a vendor, there is no subscription and no account to create, and the same installation works on a phone and on a desktop. The flip side is that the same privileges exist on every device you install it on, which makes the read only designation for the GitHub backends sensible rather than merely cautious, since a token for a code hosting account is not something you want a mobile app to hold.

The everyday features are the usual reader and transfer features

Beyond the backend matrix, the feature list is a list of things a file tool is expected to do well. Files can be listed, copied, moved, deleted, renamed, uploaded and downloaded. The desktop build supports drag and drop upload of files or whole folders, and files can be multi selected and operated on together. The file list information is cached so that a re-sort or a re-filter does not hit the network again. There is a recycle bin, which is the difference between a delete and a mistake. Preview is supported for video, audio, image and text files. Files can be encrypted and compressed before they are stored, which matters for a tool whose job is to move data between services with different trust models. Two languages are built in, Chinese and English, and the backup and synchronisation between different storage backends is listed as still in testing, which is the one feature in the list that the README marks as unfinished rather than shipped.

Where the gaps are, and who it is for

The limits are visible in the matrix, and they are the first thing to check. Three backends are read only, two of the regional drives have missing write operations, and the cross storage synchronisation is not finished. A team whose whole library lives in GitHub releases will find the app useful for reading and downloading and nothing else, and a team that wants its drives to mirror each other will find the feature flagged for testing. There is also the matter of the project being GPL-3.0, which matters for anyone who wants to embed the Go service in a product of their own. The audience implied by the rest of the documentation is a person with many small storage accounts and a habit of downloading from one and uploading to another, which the app serves well, and the documentation is published as a guide site separate from the repository, with the app itself on the App Store and the release builds on the GitHub releases page.

The alternative is a desktop file manager with protocol support

The realistic alternative is a general purpose file manager that mounts the protocols you need, whether that is WebDAV, SFTP, SMB or an object store, and you use the storage providers own applications for the accounts they host. The difference in approach is where the backend knowledge lives. A general file manager speaks a protocol and leaves the account specifics to the provider, so Google Drive and OneDrive are usually reachable only through their own tools. This application instead keeps a table of providers and their capabilities, and it is willing to present a backend as read only rather than pretend, which is exactly the information a user with fifteen drives needs. The trade is that the driver set is bounded by what cloudfs implements, so adding a provider means contributing upstream rather than writing a driver here, and the project has deliberately made that its position. For a user who mostly reads and downloads, either route works. For a user who wants one screen that shows what is writable and what is not, that is the thing this project is for.

Editorial conclusion

Adopt maple-file if you juggle several storage backends and want one interface for listing, uploading and previewing across them, especially if some of those backends are reachable only through a protocol the mainstream clients ignore, such as SFTP or SMB. Do not adopt it expecting GitHub or mirror backends to be writable, because the capability matrix marks them list and download only, and do not rely on cross storage synchronisation today, since the README still marks it as in testing. Before you commit, read the capability table for the specific backends you need, and check the licence terms, since the project is GPL-3.0.

Frequently asked questions

Official sources

1. honmaple/maple-file on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases