LeCoqRoti
When you spend enough time with an app like Panic's file transfer client, you begin to notice the small things. The way a toolbar button responds, how a sheet sizes itself to its text. Version 5.11.6 is built from those small things. It is less a feature release and more a careful tidying of edges — the kind of update that comes from watching someone work and noticing where the friction sits.
Consistent transfers: FTP, S3 and WebDAV in one window
- FTP, SFTP, S3 and WebDAV transfers with a consistent interface
- Two-factor login workflows that need to feel routine, not theatrical
- Batch renaming on local or remote items without leaving the file list
- Keeping favourite folders a click away through the Places Bar
System fit: macOS 13 and five interface languages
- Requires macOS 13 Ventura or later
- Interface languages cover English, German, Simplified Chinese, French and Japanese
- Local-to-remote synchronisation is available, though not the centre of this release
Memory rhythm: around 180 MB during daily uploads
After a week of daily transfers — uploading builds, pulling down media assets, pushing site updates — the application settles into a predictable rhythm. Memory usage hovers around 180 MB with four connections open, climbing briefly during synchronisation jobs and dropping back once the queue empties. CPU draw is negligible when idle; during a multi-threaded SFTP transfer of a few hundred small files, it peaks at perhaps 12% on an Apple Silicon machine and returns to near zero immediately. The interface never stalls, even while calculating folder sizes on a remote S3 bucket containing several thousand objects.
Stability in 5.11.6 reflects the maturity of the codebase. The crash when dragging files into IntelliJ — fixed in this release — was one of those rare edge-case bugs that only surfaced in a specific IDE interaction. During testing across FTP, SFTP, S3 and WebDAV endpoints, no unexpected disconnections or silent failures occurred. Error reporting for oversized S3 uploads is now clearer: instead of a generic failure, the log names the file and the size limit it exceeded. That alone saves minutes of guesswork.
Disk I/O behaves sensibly. Large files stream rather than loading entirely into memory, which means a 12 GB video file transfers without pressure on the system. The app respects macOS energy settings on laptops, throttling background transfers when on battery if the system preference demands it. For anyone who keeps a transfer client open all day alongside a code editor and a browser, the resource footprint is unobtrusive — the kind of quiet competence that only becomes noticeable when you switch to something heavier.
Import reality: bookmarks from existing FTP clients
Will it handle my existing server bookmarks? If you are coming from another client, the import options cover generic FTP/SFTP bookmark formats. You can also build your list manually; the connection editor makes no assumptions about ports or protocols, so a non-standard SFTP port or a custom S3 endpoint is straightforward to configure. Panic Sync, included, keeps bookmarks consistent across Macs that share an account — no manual export step needed.
Does it work well with very large S3 buckets? Yes. The file list loads incrementally, so browsing a bucket with tens of thousands of objects does not freeze the interface. The release notes for 5.11.6 specifically call out improved error reporting for files too large to upload to S3, which suggests the team is actively maintaining that code path. Multi-part uploads for large objects are handled automatically.
Will I need to generate keys elsewhere? Not necessarily. The built-in key management panel can create and manage secure keys without leaving the application. That is useful when setting up a new SFTP connection and you want to avoid the terminal round-trip for ssh-keygen. The two-factor authentication support covers TOTP and interactive keyboard-interactive prompts, so connections to hosts that require a second factor work without scripting workarounds.
Is the batch renaming safe for remote files? The rename sheet previews the result before you commit. It works on local and remote items identically — the UI does not distinguish. You can apply a numbering scheme, find-and-replace, or a custom pattern, and the preview updates in real time. If you rename twenty files on a remote SFTP server, the client sends the rename commands sequentially and reports any failures per file.
Two-pane SFTP: drag-and-drop with a remembered Places Bar
Web developers maintaining sites over SFTP find the workflow natural: a two-pane layout with local files on the left and the server on the right, drag-and-drop between panes, and a Places Bar that remembers /var/www/html across sessions. The ability to open the current remote location in Terminal means a quick shell command is never far away — helpful when a file permission needs changing without switching to a dedicated SSH client.
Photographers and video editors who deliver work via S3 or Backblaze B2 benefit from the large-file handling and the clear transfer queue. A shoot can produce 60 GB of footage; queueing the upload, seeing the progress per file, and receiving a clean error log if something fails makes the delivery process predictable rather than anxious. The info sidebar lets them check file dimensions and sizes before sending, which avoids accidental uploads of proxy files instead of masters.
Designers who collaborate through Dropbox or Google Drive get a more direct interface than the Finder integration offers. Connecting to cloud storage through a transfer client reveals the raw folder structure without sync icons and status overlays. Batch renaming a set of exported assets directly on the remote store, without downloading first, keeps the workflow lean.
System administrators who manage multiple servers across different protocols appreciate the consistent interface. An FTP connection to a legacy host, an SFTP session to a modern VPS, and an S3 bucket all behave the same way in the file list. The tags feature allows marking servers by purpose — staging, production, backup — and filtering the bookmark list by tag reduces visual noise during a busy maintenance window.
Tuesday morning: tagged bookmarks for staging, production and assets
You open the application on a Tuesday morning. The sidebar shows your bookmarks, tagged and ordered: staging for the test server, production for the live site, assets for the S3 bucket. You select the staging server; an SFTP connection opens with a key you generated inside the app months ago. The remote pane populates quickly, showing the directory tree of the current deployment.
In your local pane you have navigated to the build output folder. A batch of updated HTML files sits there, modified late last night. You select seven files, drag them to the remote pane, and release. The transfer queue appears at the bottom of the window — each file takes under a second. The progress indicators are small and precise; no animated paper planes, just a bar that fills and a checkmark that appears.
One file fails. The error column reads: file already exists and is newer on the server. You realise you forgot to pull the latest before rebuilding. You right-click the remote folder, choose synchronise, and set the direction to download. The sync preview opens: it shows three files on the server that are newer than your local copies. You confirm, they download, and you make a mental note to rebuild with those included later.
Before switching to the production server, you open the batch rename tool on the local build folder. Twelve image assets need a version suffix. You type _v2 as a suffix, the preview column updates, and you apply. The local files rename instantly. You drag them to the production SFTP pane, where the transfer completes in moments. You close the connection, and the app settles back to its idle state — quiet, ready, occupying a single slot in the Dock.
Correspondence 0
Take a chair or join the table to send a letter.
No correspondence on this note yet. Letters are read before they appear.