File Transfer Protocols and Speed Optimization
By Jamal Uddin · · 6 min read

The right file transfer protocol depends on what you are moving and who receives it. For server to server transfers, SFTP is the usual secure choice. For delivering files to people, especially to phones, HTTPS is the standard because every browser supports it and it is encrypted by default. Plain FTP is fast and simple but sends passwords and data unencrypted, so it should not be used over the public internet.
This guide compares the common protocols, lists practical ways to speed up transfers, and explains how AppForShare uses HTTPS to move mobile app builds from developers to testers.
Common file transfer protocols
| Protocol | Encrypted | Typical use |
|---|---|---|
| FTP | No | Legacy systems and closed internal networks |
| FTPS | Yes, FTP over TLS | Older FTP workflows that need encryption |
| SFTP | Yes, runs over SSH | Server administration, automated transfers between systems |
| HTTPS | Yes, HTTP over TLS | Web downloads and uploads, APIs, delivery to browsers and phones |
FTP: the classic protocol
FTP has been around since the early days of the internet. It uses separate connections for commands and data and is widely supported by servers. Its main weakness is that usernames, passwords and file contents travel in plain text, so anyone on the network path can read them.
SFTP: secure transfers over SSH
SFTP is a different protocol from FTP despite the name. It runs inside an SSH connection, so authentication and data are encrypted, and it uses a single connection, which makes it easier to use through firewalls. It is a good default for moving files between servers.
FTPS: FTP with TLS
FTPS adds TLS encryption to FTP. It keeps FTP's command set, which helps when existing tools depend on it, but firewall setup can be harder because of FTP's separate data connections.
HTTPS: transfers to people and devices
HTTPS is what browsers and mobile operating systems use for downloads. It needs no extra client software, works through almost any network, and supports resuming partial downloads. Over-the-air app installation on both iOS and Android relies on HTTPS.
How to choose a protocol
- Is the recipient a person on a phone or laptop? Use HTTPS. Asking testers or clients to install an FTP or SFTP client adds friction.
- Is it a scheduled transfer between servers? Use SFTP.
- Does a legacy system only speak FTP? Use FTPS if possible, and keep plain FTP inside a private network.
- Is the data sensitive? Never use plain FTP across the internet.
Optimizing file transfer speed
1. Make the file smaller
The fastest transfer is the one with fewer bytes. For mobile builds, that means removing unused resources, shrinking images, and building only the architectures you need. On Android, App Bundles help for store releases, but testers who install directly need an APK, so consider separate per-ABI APKs for large apps.
2. Split large uploads into chunks
Uploading in chunks means a dropped connection only repeats the last chunk, not the whole file. This matters most on mobile and office networks.
3. Use a good network path
Upload from a wired connection or a CI server rather than a laptop on busy Wi-Fi. Upload speed is usually much lower than download speed on home connections.
4. Avoid interference
VPNs, proxies and security software can slow transfers or break large uploads. If uploads keep failing, try once without them to find the cause.
5. Automate repeat transfers
If you send a new file every day, script it. Automation removes manual steps and runs from machines with better connections.
Security in file transfers
Encryption in transit is the minimum. Beyond that, good practice includes limiting who can access a file, making access links expire, adding a password for sensitive files, and deleting files that are no longer needed. SFTP and HTTPS both encrypt traffic, but neither controls who you share a link with, so access control still matters.
How AppForShare transfers app builds
AppForShare is built for one kind of transfer: getting Android .apk and iOS .ipa test builds from a developer to testers' phones. It is not a general file transfer service. It works like this:
- HTTPS everywhere. Uploads, install pages and downloads all use HTTPS.
- Install link and QR code. Each build gets its own link. Testers open it on the phone and install over the air, with no FTP client and no app store review.
- Signed, short-lived download links. Builds sit in a private Google Cloud Storage bucket. Each download uses a signed link that expires quickly.
- Optional password on any build, on the Free plan and above.
- Chunked, resumable uploads from CI. The AppForShare CLI uploads large builds in 32 MB chunks and resumes after a dropped connection. It runs in GitHub Actions, GitLab CI, Fastlane or any shell on Pro and Team. See uploading builds from CI.
- Release notes for each build on Pro and Team, so testers know what changed.
- Branded install page on Team, with your own custom domain, logo and colours. See customization and white-label install pages.
Size limits and link life
| Plan | Max file | Link life | Monthly bandwidth |
|---|---|---|---|
| Guest | 50 MB | 3 days | 20 installs per link, 4 per day |
| Free | 150 MB | 7 days | 10 GB |
| Pro | 2 GB | While subscribed | 40 GB |
| Team | 4 GB | While subscribed | 150 GB |
Bandwidth counts what testers download. Uploading is free. A 50 MB build installed 20 times uses about 1 GB. More detail is in file size and upload limits.
Android and iPhone specifics
Android
Testers download the APK in the browser and allow installs from unknown sources for that browser once. See how to enable unknown sources on Android.
iPhone and iPad
iOS only installs apps over the air when the build is signed Ad Hoc (with the device UDID in the provisioning profile), Enterprise or Development. App Store and TestFlight builds cannot be installed from a link, and AppForShare does not re-sign builds. Testers can get their UDID with the free UDID finder. On iOS 16 and later, testers also need to turn on Developer Mode for Ad Hoc and Development builds; see how to enable Developer Mode on iPhone.
Conclusion
Use SFTP between servers, avoid plain FTP on the internet, and use HTTPS when the recipient is a person on a device. Keep files small, upload in chunks, and automate repeat transfers. For mobile test builds, AppForShare handles the HTTPS delivery, install page and link expiry so testers only need to open a link.
Frequently asked questions
What is the most secure protocol for transferring large files?
SFTP is a common secure choice between servers, and HTTPS is the standard for delivering files to people and devices. Both encrypt data in transit. Plain FTP does not encrypt anything and should not be used over the internet.
How can I speed up large file transfers?
Reduce the file size, upload in chunks so a dropped connection does not restart the whole transfer, use a fast and stable network such as a CI server, and avoid VPNs or proxies that slow large uploads.
Which protocol does AppForShare use?
AppForShare uses HTTPS for uploads, install pages and downloads. Builds are stored in a private Google Cloud Storage bucket and downloaded through signed links that expire quickly.
What is the largest file AppForShare accepts?
Guest uploads can be up to 50 MB, Free up to 150 MB, Pro up to 2 GB and Team up to 4 GB per build.
Can I send any type of file with AppForShare?
No. AppForShare is for Android APK and iOS IPA test builds that testers install over the air. It is not a general file sharing service.


