macOS · Apple Silicon
- Filename
- FortSwift-v4.1.25-macos-arm64.dmg
- Version
- 4.1.25
- Signature
- Developer ID, notarised and stapled (Team ID RC982T9KL6)
Check it yourself
Here is the evidence.
Check the file you downloaded, read the algorithms we use, and read what the product currently cannot do. This page does not ask you to take our word for it; it gives you the commands.
Download integrity
Every release ships a matching SHA256SUMS manifest listing bare filenames, so it can be checked with the tools already on your machine. Each installer additionally carries a platform publisher signature.
What a matching hash does and does not prove
A matching SHA-256 shows the file you have is the file in the manifest we served. On its own it does not establish who built it, and it does not help if the installer and the manifest were replaced together — the manifest is not independently signed today. So check the publisher signature as well. Signing and notarisation are also not a third-party security audit.
Windows · x64
- Filename
- FortSwift-v4.1.25-windows-x64.zip
- Version
- 4.1.25
- Signature
- EV Authenticode, Certum timestamp (thumbprint AD85 0522 C798 0F69 8136 4C85 9A0A 5CE3 20A8 EF03)
Android · arm64
- Filename
- FortSwift-v4.1.25-android-arm64.apk
- Version
- 4.1.25
- Signature
- Release keystore; the certificate fingerprint matches this site's assetlinks.json
- iOS / iPadOS
- — TestFlight only. There is no public build, so there is no hash to check.
- Linux
- — There is no client. The version manifest leaves it out deliberately rather than advertise a version that does not exist.
Check it yourself
Download the installer and the SHA256SUMS file for the same version into one directory. If the hash does not match, stop — do not install it, and do not bypass your system's own checks.
macOS
The first line checks the file hash; the rest check the signature and notarisation. codesign and spctl inspect the installed app, so adjust the path if you installed it elsewhere.
shasum -a 256 -c SHA256SUMS-v4.1.25.txt
xcrun stapler validate FortSwift-v4.1.25-macos-arm64.dmg
codesign --verify --strict --verbose=2 /Applications/FortSwift.app
spctl --assess --type execute --verbose=4 /Applications/FortSwift.appExpect: the hash line prints OK; stapler reports the validate action worked; codesign passes; spctl reports accepted with source Notarized Developer ID. A missing Xcode command line tool is not a pass.
Windows (PowerShell)
The ZIP itself carries no Authenticode signature, so what you verify is the executables inside it. This script expands the archive into a fresh temporary directory and lists the signatures without running anything.
Get-FileHash -LiteralPath .\FortSwift-v4.1.25-windows-x64.zip -Algorithm SHA256
Get-Content -LiteralPath .\SHA256SUMS-v4.1.25.txt
$dir = Join-Path ([IO.Path]::GetTempPath()) ([guid]::NewGuid())
Expand-Archive -LiteralPath .\FortSwift-v4.1.25-windows-x64.zip -DestinationPath $dir
Get-ChildItem -LiteralPath $dir -Recurse -Include *.exe,*.dll |
ForEach-Object { Get-AuthenticodeSignature -LiteralPath $_.FullName } |
Format-List Path, Status, SignerCertificateExpect: the hash matches the manifest character for character, and every exe and dll reports Status Valid with subject Fookstar Tech Pte. Ltd. An invalid status, a different subject, or finding no executables at all is not a pass.
Android
Needs a machine with the Android SDK build tools. Note that the APK's file hash and its signing certificate fingerprint are two different things.
shasum -a 256 -c SHA256SUMS-v4.1.25.txt
apksigner verify --verbose --print-certs FortSwift-v4.1.25-android-arm64.apk
curl -s https://fortswift.com/.well-known/assetlinks.jsonExpect: the hash prints OK, and the certificate SHA-256 that apksigner prints matches sha256_cert_fingerprints for the same package name in assetlinks.json. A mismatch breaks Android passkeys, which is why this one is worth checking yourself.
Cryptography
These are the algorithms actually in use. The same table says what each one does not establish — an algorithm name is not a security conclusion.
| Algorithm | What it does here | What it does not establish |
|---|---|---|
| X25519 + ML-KEM-768 | Hybrid key agreement; the two shared secrets are combined into the session key, so breaking either alone does not recover it | A design description, not an audit result. This protection only took effect in 4.1.17 — before that the host put the KEM secret on the wire in clear — so both ends need a build that carries the fix. The independent ML-KEM audit is still outstanding. |
| ChaCha20-Poly1305 | Session encryption and integrity, 256-bit key | Naming the algorithm does not prove every implementation path is free of defects, and nothing about session retention or server-side visibility follows from it. |
| Ed25519 | Identity and snapshot signatures; the controller verifies the host's identity with it | Package signing, hardware key custody and trust-snapshot signing are three separate things. Do not read them as one blanket certification. |
| Argon2id | Password handling in the optional fixed-password mode | Belongs to an optional mode, and does not change the fact that the default mode, account_trust, is passwordless. |
About certification
There is no SOC 2, no ISO 27001, no GDPR certification and no third-party security audit. The relay cannot read traffic — it forwards blindly and the controller verifies the host's Ed25519 identity end to end — but that too is a description of the design, not a certification.
What does not work
Below is what the product cannot do today, listed plainly. This section sits at the same level as the others. It does not collapse, and it is not written as “for now” or “coming soon”.
Clients and distribution
- There is no Linux controller — not planned-soon, simply absent.
- The macOS controller ships for Apple Silicon only. There is no Intel build.
- iOS and iPadOS are TestFlight only. There is no public release build.
- The Windows controller is a zip, not an installer. The Android build is arm64 only.
- Android and iOS / iPadOS cannot act as hosts.
- There is no web or browser client.
- There is no native passkey sign-in in the desktop or mobile apps — desktop sign-in goes through the browser.
Startup and unattended access
- Nothing starts at boot, on any of the four platforms. macOS installs a LaunchAgent, Linux a user-level systemd unit, Windows a task triggered at logon.
- So a machine that reboots and sits at the login screen is offline. The Windows service that does start at boot supervises the lock-screen capture helper only; it does not start the host.
- Locked-screen control means controlling a machine someone has logged into and then locked. It does not mean reaching a machine that has just rebooted.
- Ctrl+Alt+Del is not supported.
- Approving a UAC elevation prompt remotely is refused by design: remote input may unlock the machine, but it must never approve an elevation request on the owner's behalf.
Sessions and records
- Session history, connection records and usage or bandwidth reporting are not wired up. The code exists on both sides, but the client never reports a session, so there is no data to show.
- You cannot choose between monitors. The protocol carries the field, but the client is fixed to the first display and there is no picker.
- There is no microphone and no two-way audio. Audio travels one way from the host, and is off by default.
- There is no session recording, wake-on-LAN, remote printing, stylus input or virtual display.
- 120 and 144 Hz are not supported: the protocol field tops out at 65.535 fps, which is structural.
Deployment and service
- There is no self-hosted or on-premises product.
- There is no public self-service sign-up and no self-service checkout.
- There is no availability commitment and no status page.
- Hardware key custody covers controllers only. The host's host.key is a plaintext file, and Linux has no hardware backend.
The three hosts differ a great deal
macOS is the only fully-featured host. If the machine you need to reach runs Windows or Linux, read this table first.
| Capability | macOS host | Windows host | Linux host |
|---|---|---|---|
| Hardware encoding | H.264 / H.265 | No — software VP9 only | No — software VP9 only |
| Audio | Yes, off by default | Not implemented | Not implemented |
| Clipboard | Yes, text only, 256 KiB | Unavailable (the write is a silent no-op) | No |
| File transfer | Off by default, download only | Unavailable (the transfer root is never opened) | No |
| Resolution switching | Real display-mode switching | Encoder-side scaling only | Encoder-side scaling only |
| Display environment | — | — | X11 only; Wayland cannot capture the full desktop |
Compiled against the product as it stood on 2026-09-22. When a capability changes, this page changes first and the rest of the site follows.