The Transporter transfer failed error about an app-specific password means the credentials you used to upload were not accepted, almost always because your Apple ID has two-factor authentication and you tried to use your normal password instead of an app-specific password. Two-factor accounts, which is now effectively all of them, cannot authenticate command-line or Transporter uploads with the regular Apple ID password. Generate an app-specific password at appleid.apple.com and use it in Transporter, or in Fastlane through the app-specific-password environment variable. For continuous integration, the more reliable option is an App Store Connect API key, which avoids app-specific passwords entirely.
Short answer
The error means your upload credentials were rejected, and the fix is to use an app-specific password instead of your Apple ID password. Per Apple's app-specific password guidance, accounts with two-factor authentication require an app-specific password for tools like Transporter and altool, which you generate at appleid.apple.com under Sign-In and Security. In Fastlane, provide it through the FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD environment variable, per the Fastlane authentication docs. For CI and automation, prefer an App Store Connect API key, which uses a key file rather than a password and avoids two-factor prompts entirely. Never use your plain Apple ID password for these uploads.
Why the app-specific password error happens
The error happens because Apple requires two-factor authentication on developer accounts, and tools that upload builds, such as Transporter and the command-line altool, cannot complete a two-factor challenge the way a browser can. To let these tools authenticate, Apple provides app-specific passwords, which are single-purpose credentials tied to your account but usable without an interactive second factor. If you supply your normal Apple ID password instead, it is rejected, producing the transfer failure.
So the message is really telling you the wrong kind of credential was used. It is not that your account is broken or your password is wrong in general; it is that a two-factor account needs an app-specific password for this path. An expired or revoked app-specific password produces the same failure, which is why regenerating one is often the fix even if you thought you were already using it.
How to generate an app-specific password
Generate the password from your Apple ID account page, not from App Store Connect. Sign in at appleid.apple.com, open the Sign-In and Security section, and find App-Specific Passwords. Create a new one, give it a recognizable name like Transporter or CI, and Apple shows you a password in a grouped format. Copy it immediately, because it is displayed only once.
Treat that value as a secret. It grants upload access to your account, so store it the way you would any credential, in your CI secret store or a password manager, not in a file in your project. If you lose it or suspect it leaked, revoke it from the same page and generate a new one. You can hold several app-specific passwords at once, so using a separate, clearly named one per tool or machine makes them easy to rotate and revoke.
Using it with Transporter
In the Transporter app, sign in with your Apple ID and, when prompted for the password, enter the app-specific password rather than your normal one. That is the whole fix for the interactive case: Transporter accepts the app-specific password, the two-factor requirement is satisfied, and the transfer proceeds. If it still fails, the most common reasons are a mistyped password or one that has been revoked, so regenerate and try again.
The same principle applies to altool on the command line, where you pass the app-specific password in place of your account password. Whether you upload through the Transporter app or a script, the credential that works is the app-specific password, and the credential that fails is your plain Apple ID password, because the account uses two-factor authentication.
Fastlane environment variables
Fastlane authenticates through environment variables, and the one that carries the app-specific password is FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD. Set that to the app-specific password you generated, along with your Apple ID in FASTLANE_USER, and Fastlane's upload actions can then authenticate without an interactive second factor. This is the direct equivalent of typing the app-specific password into Transporter, expressed as configuration.
Keep these values in your CI secret store rather than in the Fastfile or the repository, since they are credentials. Setting FASTLANE_USER and the app-specific-password variable is enough for the common upload flow, but if you see repeated session or two-factor issues in automation, that is usually the signal to move to the App Store Connect API key instead, which Fastlane also supports and which is more robust for unattended builds.
Better for CI: the App Store Connect API key
For continuous integration, an App Store Connect API key is the more reliable choice than an app-specific password. Instead of a password, you create an API key in App Store Connect, which gives you a key ID, an issuer ID, and a downloadable .p8 key file, and tools authenticate with those. Because it is designed for programmatic access, it does not involve your personal password or trigger two-factor prompts, which makes unattended CI far more stable.
Fastlane supports this directly through its App Store Connect API key configuration, and once set up it replaces the Apple ID and app-specific password entirely for uploads. The trade-off is a little more initial setup, but for any automated pipeline it is worth it, because you avoid the session and password issues that make app-specific passwords fragile in CI. For a one-off local upload, the app-specific password is fine; for a pipeline, prefer the API key.
Authentication options compared
The available credentials suit different situations. The table below compares them.
| Method | How you provide it | Best for |
|---|---|---|
| App-specific password | Generated at appleid.apple.com | Transporter and simple local uploads |
| App Store Connect API key | A .p8 key file with key and issuer IDs | CI, automation, unattended builds |
| Plain Apple ID password | Not accepted with two-factor | Never for these uploads |
Read the table by where you are uploading from. For a manual upload through Transporter, the app-specific password is the quick answer, and for a pipeline, the API key is the durable one, while the plain Apple ID password is not an option for either because of two-factor authentication.
Fix checklist
A short sequence resolves the error and prevents it recurring. The checklist below covers it.
| Check | Action | Done? |
|---|---|---|
| Generate password | Create an app-specific password at appleid.apple.com | [ ] |
| Use it | Enter it in Transporter or altool in place of your password | [ ] |
| Fastlane variable | Set FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD in CI secrets | [ ] |
| Prefer the API key | Use an App Store Connect API key for automated pipelines | [ ] |
| Retry the upload | Re-attempt the transfer with the correct credential | [ ] |
The step that resolves most cases immediately is simply generating a fresh app-specific password and using it in place of your Apple ID password. If the failure is in CI and recurs, moving to the App Store Connect API key is the more permanent fix.
After upload: scan before you submit
Fixing authentication gets your build uploaded, but a build that transfers successfully still has to pass review, and a preventable security or privacy issue can cause a rejection unrelated to how you uploaded. Those issues are cheaper to catch before submission than after.
A scanner like PTKD.com analyzes your .ipa and reports findings ordered by severity and mapped to OWASP MASVS, so you catch issues like unjustified permissions, cleartext traffic, or embedded secrets before you submit. To be clear about the boundary: PTKD does not manage your credentials, generate an app-specific password, or configure an API key. It checks the uploaded build's security, which is a separate concern from the authentication that got it there.
What to take away
- The app-specific password error means your upload credential was rejected because a two-factor account cannot use the plain Apple ID password.
- Generate an app-specific password at appleid.apple.com under Sign-In and Security, and use it in Transporter or altool in place of your password.
- In Fastlane, provide it through FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD, and keep it in your CI secret store, not the repository.
- For CI and automation, prefer an App Store Connect API key, which uses a key file, avoids two-factor prompts, and is more reliable than a password.
- Treat these credentials as secrets, and after uploading, scan the build with PTKD.com for the separate matter of review-blocking security issues.
