How FlyingFiles works

This page is for the curious, and for administrators who want to know what the app does with files, passwords and the network before they install it.

At a glance

• FlyingFiles is a native app for macOS and Windows. It runs only on your computer.

• There's no intermediary server and no account. Files go directly between your computer, your disks and your servers.

• The nci.pl website is used to download the macOS app and — when you ask — to check for updates. The Windows version is delivered and updated by Microsoft Store.

flowchart LR
  subgraph PC["Your computer"]
    APP["FlyingFiles"]
    DISK["Disks, USB drives,<br/>network shares"]
    KEY["Keychain /<br/>Credential Manager"]
    TERM["System terminal"]
  end
  SRV["Your servers<br/>FTP · FTPS · SFTP"]
  NCI["nci.pl<br/>macOS download and updates"]
  STORE["Microsoft Store<br/>Windows installation and updates"]
  APP <--> DISK
  APP <--> KEY
  APP --> TERM
  APP <--> SRV
  APP -. "on request" .-> NCI
  STORE -. "Windows" .-> APP

How the app is built

FlyingFiles is written in C# on .NET 10, with an Avalonia 12 user interface. The same code runs on both systems; system-specific code is kept separate, in one place.

The app consists of three layers:

Compiled to native code

The app is compiled ahead of time (Native AOT) into an executable for a specific processor. As a result:

• you don't need to install .NET,

• the app starts in a fraction of a second,

• it uses less memory than an app with an interpreter.

An interface that doesn't freeze

Every disk and network operation runs in the background, and the interface only shows the progress. Even listing a folder on a hung network share doesn't block the window. Every operation that can take a while has a progress window and a working Cancel button.

One model for every location

The local disk, an archive, an FTP server and an SFTP server share a common file system interface in the app: listing, reading, writing, creating folders, deleting, renaming. The panel, copying, preview, search and comparison use only this interface. That's why:

• copying works in every combination: disk → server, server → archive, server → server;

• an archive behaves like a folder — the app extracts it to a private temporary folder and packs the changes back in when you leave it;

• search and statistics work the same way on a disk, in an archive and on a server.

How copying works

1. .ffignore rules — items covered by the source and destination rules are filtered out.

2. Destination check — you can't copy an item onto itself or a folder into its own subfolder.

3. Scan — in a single pass, the app collects the file list, the total number of bytes and the conflicts. With servers, it remembers the listings of destination folders so that it doesn't ask the server about each file separately.

4. Conflict decision — a dialog with a choice: overwrite all, overwrite older, skip duplicates, cancel.

5. Copying in 256 KB chunks, with progress:

   • moving within one disk is a rename — instant;

   • writing to a disk goes to a temporary file next to the destination, which replaces the destination file only at the end, so an interruption doesn't leave half a file behind;

   • an error in one file doesn't stop the whole operation — the file goes on the list of failed items, with the reason.

6. When it's finished — optional cleanup of macOS metadata files, refreshing the panels, a summary, the list of failed items and an entry in the transfer log.

With servers

• Retrying after a timeout and reconnecting after a dropped connection, returning to the same folder.

• Completeness check — after an error, the app compares the size of the file on the server. It treats a complete file as done, and when the state can't be determined, it doesn't retry blindly, so that it doesn't overwrite a good copy.

• SHA-256 verification (optional) — the checksum of the source file is compared with the checksum of the copy. On SFTP, the app tries to compute the checksum on the server (sha256sum, shasum, openssl), and when the account doesn't allow that, it reads the copy back.

• Cancellation — a half-uploaded file is deleted from the server, and a download doesn't leave junk on the disk.

Data and security

What the app stores

Passwords

• Passwords are stored only in the system password store — the macOS Keychain or Windows Credential Manager. The system encrypts them and controls which apps can read them.

• The settings file never contains passwords.

• The app reads a password only when it connects to that server or when the connection is edited, not at startup.

• In the server conversation log, the password is masked (PASS ********).

The settings file

• Saving is atomic (a temporary file, then a swap), with a lock that protects against two windows saving at the same time.

• On macOS, the file has owner-only permissions (0600), because it contains server addresses and logins.

• When reading, the app tolerates missing and unknown keys, and when saving, it keeps keys it doesn't know — manual additions and settings from older versions aren't lost.

• Backups are made before saving.

Terminals

A terminal's address and username may contain only safe characters (letters, digits, ., -, _, : and the brackets of IPv6 addresses). This way, a saved entry can't sneak an extra command into the terminal.

Known security limitations

• The FTPS server certificate isn't verified, and the SFTP host key is accepted without checking it against a list of known hosts. Encryption protects against eavesdropping, but not against an impostor server.

• Plain FTP encrypts nothing — neither the password nor the files.

Distribution and updates

macOS

• The app is signed with a Developer ID certificate, runs with the Hardened Runtime enabled and is notarized by Apple. The notarization ticket is stapled to the app and to the .dmg disk image, so the system can check it without a network connection.

• The app has one additional permission: controlling other apps (Apple Events) — solely to open an SSH or Telnet connection in the Terminal app. macOS asks for consent the first time it's used.

• Launched from the disk image, the app copies itself to ~/Applications. Installing in the user's folder means updates don't require an administrator password.

• Updates (Velopack library) are downloaded on request from https://nci.pl/flyingfiles/releases/osx-arm64/ over HTTPS. The app checks the list of releases, downloads the package, replaces itself and restarts. The app inside the package is signed with the same Developer ID certificate and notarized, just as with the first installation.

The app isn't in the Mac App Store: the store's sandbox doesn't allow moving freely around the whole disk or controlling Terminal — which is exactly what a file manager is for.

Windows

• The app is released as an MSIX package in Microsoft Store. The package is signed by Microsoft, so installation goes through without SmartScreen warnings.

• Updates are installed by Microsoft Store. The app recognizes that it's running from a Store package and turns off its own update mechanism.

• The app runs as a regular Windows app with your account's permissions. It doesn't need any special consent to access files, and it keeps its settings in the regular %APPDATA%\FlyingFiles folder.

Privacy by design

• No telemetry, analytics, accounts or ads.

• The app's only network connections are: your FTP/FTPS/SFTP servers, your network shares and — when you choose Check for Updates... (macOS and the old Windows beta from Setup.exe) — nci.pl.

• The video preview uses the system's Quick Look on your computer; nothing is sent anywhere.

Full text: privacy policy.

Languages

All interface texts are in a single translation file, in Polish and English. Every text exists in both languages, which automated tests check. The language changes immediately, without restarting the app.

Quality

• More than 1,700 automated tests check the app's logic and windows — also without a screen — on macOS and on Windows.

• Every bug fix starts with a test that reproduces the bug.

• FTP and SFTP support is additionally checked on real servers with a separate tool that goes through a list of operations: connecting, listing, uploading, downloading, verification, cancellation and reconnecting.

History

Up to version 0.1.0, FlyingFiles was a Python app with a Qt interface. In September 2026, the app was rewritten from scratch in C#, following a detailed specification of how the old version behaved, to gain native startup speed, signing and notarization on macOS, a Microsoft Store package and a single codebase for both systems. The first stable release of the new version is 1.0.0, from September 13, 2026. Changelog.

Open source libraries

The current versions are shown in the Help → About window.