Nimbus

Nimbus puts S3, Google Drive, OneDrive, SFTP and dozens of other storage services into Finder and one native Mac app, driven by rclone.

Nimbus is a Mac app for cloud storage. It lets you browse, copy, sync and mount remotes from S3, Google Drive, OneDrive, SFTP and the rest of rclone’s long list. It doesn’t reimplement any provider: it drives rclone and puts a native interface on top, including a Finder extension so your remotes show up where your files already are.

Status: In development
Runs on: macOS
Built with: Swift 6, SwiftUI, File Provider, rclone

Why it exists

rclone is the most capable cloud-storage engine there is, but using it means a terminal and a config file. The usual alternative is one vendor app per cloud, each with its own sync folder and its own idea of how a Mac should behave. Nimbus keeps rclone’s reach and its open config format, and drops the command line.

What it does

Your remotes, in Finder: A File Provider extension lists your remotes in Finder. Files download when you open them, and edits go back up.
Mount a remote as a volume: Mount any remote as a Finder volume. Mounts marked to open at launch, or left open when you quit, come back on the next launch.
Add a remote without the config file: A guided sheet asks only the questions rclone needs for that provider, and providers that use OAuth sign in through your browser. Existing rclone configs import as they are.
Browse, copy and sync: List and grid views with Quick Look and type-to-select; drag between clouds to copy; copy or sync any two remotes or folders, with progress in a Transfers view and the menu bar.

How it’s built

One engine, two clients

The app and its Finder extension talk to the same local rclone process through RcloneKit, a typed Swift client for rclone’s remote-control API. The engine’s port is shared through the app group, and no provider is ever reimplemented in Swift.

The rclone contract is tested, not assumed

Four behaviors were checked against the real rclone and fixed. Among them: listings return paths relative to the remote’s root, and the API has no download call, so file contents come through rclone’s own file server. The lesson written into the project: a mock proves the client’s shape, not the server’s contract.

Setup follows rclone’s own questions

Adding a remote walks rclone’s own configuration flow instead of a hand-built form per provider: 13 questions for S3 instead of 78 options, 8 for Google Drive instead of 52. A test pins those counts, so an rclone upgrade that changes the flow fails loudly rather than silently.

Mounts that come back

Deciding what to restore and which stale mounts to clean up are pure, unit-tested functions. Leftover NFS servers from a crashed session are stopped before a new mount starts, and automatic remounting happens at most once per session.

Rules the build enforces

The build fails on hard-coded font sizes, which protects Dynamic Type, and on any remote Swift package dependency.

You see The Nimbus app

You see Your remotes in Finder File Provider extension

You see Mounted volumes A remote as a Finder volume

RcloneKit A typed Swift client for rclone’s remote-control API, shared by the app and the extension

rclone serve nfs Mounted with the system’s own NFS client

rclone, running locally One engine for every provider. Nimbus never reimplements one.

S3, Google Drive, OneDrive, SFTP and more than fifty others

One engine, two clients. The app and its Finder extension talk to the same local rclone through RcloneKit; mounts go through rclone’s NFS server.

On the record

Providers: More than 50, through rclone
Tests: About 200 test functions across the app and RcloneKit

Nimbus is in development. There is no release date yet.

Write to the studio