The Fastlane error Could not start the delivery: all transports failed means Transporter, which Fastlane uses under the hood to upload your build, could not connect through any of its upload transport engines, and it is almost always a network problem rather than a problem with your app or signing. Transporter tries fast protocols called Aspera and Signiant that use specific ports, and when a firewall, VPN, or proxy blocks those ports, every transport fails. The fix is to force the DAV transport, which uses standard HTTPS and gets through most firewalls, by adding the transport flag. In Fastlane you do this by setting an environment variable that passes the DAV option to Transporter.
Short answer
This is a connectivity error, not a build or signing failure, so the fix is about how the package is transferred, not the package itself. It happens because your network blocks the ports the Aspera and Signiant protocols need, so per the Fastlane diagnostics, all transports fail to connect. The reliable fix is to force the DAV protocol, an extension of HTTP that uses standard ports, by passing the transport flag. In Fastlane, set DELIVER_ITMSTRANSPORTER_ADDITIONAL_UPLOAD_PARAMETERS to the value that selects DAV, as covered in the deliver docs. Also update your command-line tools and, for a more reliable path, consider uploading with an App Store Connect API key.
What the error means
Could not start the delivery: all transports failed is Transporter reporting that it tried each way it knows to transfer your build to App Store Connect and none of them worked. Fastlane actions like deliver and pilot call Transporter, also known as iTMSTransporter, to do the actual upload, so when you see this error in a Fastlane run, it is Transporter, not Fastlane's own logic, that failed. The word transports refers to the transfer protocols Transporter uses, and all transports failed means every one of them could not establish a connection.
Because the failure is at the transfer layer, it is not telling you anything is wrong with your archive, your certificates, or your provisioning. The build was produced fine; it simply could not be sent. That distinction matters, because it points you at your network and Transporter's transport settings rather than at re-signing or rebuilding. The next sections cover the transport engines involved and the flag that routes around the usual cause.
The transport engines: Aspera, Signiant, and DAV
Transporter can move your package using more than one transfer engine, and the error names all of them collectively. Two of them, Aspera and Signiant, are high-speed protocols designed to upload large files quickly, but they rely on specific network ports, often UDP ports, that many corporate firewalls, VPNs, and restrictive networks do not allow. The third, DAV, is an extension of HTTP that travels over standard web ports.
So when Transporter says all transports failed, it usually means it tried Aspera and Signiant, both were blocked by your network, and it could not fall back to a working path. This is why the error is so strongly tied to firewalls and VPNs: the fast protocols are exactly the ones a locked-down network tends to block. Signiant, in other words, is not broken; it is being prevented from connecting, along with Aspera, and the answer is to steer Transporter to the one transport that standard networks do allow.
Force the DAV transport
The direct fix is to force Transporter to use DAV, because it runs over standard HTTP and HTTPS ports that firewalls almost always permit. You do this by passing the transport flag with the DAV value to Transporter. In Fastlane, the clean way is to set the environment variable DELIVER_ITMSTRANSPORTER_ADDITIONAL_UPLOAD_PARAMETERS so that it passes the DAV transport option through to the underlying uploader, after which deliver and pilot use DAV and get past the blocked ports.
There is a nuance about fallback worth knowing. Transporter accepts an ordered, comma-separated list of transports, so you can request a specific order, and if you name only one transport it uses just that one with no fallback if it fails. So forcing DAV alone is the surest way past a firewall, while listing several lets Transporter try alternatives. If a run keeps defaulting to a blocked engine despite the flag, setting DAV explicitly as the transport is the way to pin it to the protocol that works on your network.
Other causes and fixes
While a blocked network is the usual culprit, a few other things can produce the same error, and they are worth checking if DAV alone does not resolve it. A VPN or corporate proxy can interfere even when it is not obviously blocking ports, so disconnecting the VPN or trying a different, less restricted network sometimes fixes it immediately. An unstable or slow connection can also cause every transport attempt to time out, which surfaces as all transports failed.
Outdated tooling is another cause. Transporter ships with the Xcode command-line tools, and an old iTMSTransporter can fail to connect where a current one succeeds, so updating your Xcode command-line tools, or the standalone Transporter, is a reasonable step. Finally, an occasional Apple-side hiccup can cause a transient failure, so a retry after a short wait is worth trying. Between forcing DAV, clearing network interference, and updating your tools, you cover the common causes.
Switch to the App Store Connect API key path
A more durable answer, especially in CI, is to upload using an App Store Connect API key rather than relying on the legacy transport engines. The newer upload path used with an API key is generally more reliable than the Aspera and Signiant transfer protocols, and it authenticates without an app-specific password or interactive two-factor prompts, which also removes a separate class of upload failures. In Fastlane you provide the API key to deliver or pilot, and the upload uses the modern route.
This does not conflict with the DAV fix; rather, it is a strategic improvement for pipelines that upload often. Moving to an API key based upload reduces your exposure to the transport-engine failures entirely and is the recommended setup for automated releases. So if you keep hitting this error in CI, adopting the App Store Connect API key is worth doing alongside, or instead of, forcing DAV, because it changes the upload mechanism to a sturdier one.
Causes and fixes at a glance
Matching the cause to its fix makes this quick to resolve. The table below maps the common ones.
| Cause | Why transports fail | Fix |
|---|---|---|
| Firewall blocks Aspera or Signiant ports | Fast protocols cannot connect | Force the DAV transport |
| VPN or proxy interference | Traffic is redirected or blocked | Disconnect the VPN; try another network |
| Unstable or slow network | Transfers time out | Use a stable connection; retry |
| Outdated iTMSTransporter | Old uploader cannot connect | Update Xcode command-line tools |
| Legacy upload path in CI | Transport engines are fragile | Upload with an App Store Connect API key |
Read the first row first, since a firewall blocking the fast protocols is by far the most common reason all transports fail.
Is it a signing or credentials problem?
No, and it helps to rule that out so you do not waste time re-signing. This error is about transferring the package over the network, so it is separate from a certificate or provisioning problem, which would fail earlier during the build or with a different, signing-specific message. Your archive is already built and signed by the time Transporter tries to send it, so the transports failing says nothing about your keys.
It is also distinct from an authentication failure, such as a wrong or missing app-specific password or a two-factor prompt, which shows up as a login or session error rather than a transport diagnostic. If your message is specifically all transports failed, treat it as the network-and-transport issue it is, apply the DAV flag and the network checks, and leave your certificates, profiles, and passwords alone unless a different error points at them.
A safe retry path
Working through these steps clears the error without touching your build. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Rule out signing | Confirm the build archived and signed fine | [ ] |
| Force DAV | Set the transporter flag to use DAV | [ ] |
| Clear network blocks | Disconnect VPN; try another network | [ ] |
| Update tooling | Update Xcode command-line tools or Transporter | [ ] |
| Consider the API key | Upload with an App Store Connect API key | [ ] |
| Retry the upload | Re-run deliver or pilot; the build is unchanged | [ ] |
The step teams skip most is forcing DAV, since it is the one change that directly addresses the blocked fast protocols that cause the error.
Where a scan fits
This is a delivery and network problem, so a security tool has no role in getting the upload through, and it is worth being clear about that boundary.
A scanner like PTKD.com analyzes your app build for security issues such as exposed keys, over-broad permissions, and risky third-party code, mapped to OWASP MASVS. To be clear about the boundary: PTKD does not upload your app or configure Transporter, which are your Fastlane and network setup. It reviews the build you are trying to deliver, so the same artifact that is failing to upload can be checked for security once your transport issue is resolved.
What to take away
- Could not start the delivery: all transports failed is a network error, not a build or signing failure, so leave your certificates and profiles alone.
- Transporter tries the Aspera and Signiant protocols, which use ports firewalls and VPNs often block, and all transports failed means none could connect.
- The direct fix is to force the DAV transport, which uses standard HTTP and HTTPS ports, by passing the DAV flag through Fastlane's transporter parameters.
- Also clear VPN and proxy interference, update your Xcode command-line tools, and retry, since the build is unchanged and safe to re-upload.
- For a durable fix in CI, upload with an App Store Connect API key, and a tool like PTKD.com can scan the same build once the upload succeeds.
