Encountering the dreaded ERROR ITMS-9000: “Redundant Binary Upload. There already exists a binary upload with build version ‘1.0’ for train ‘1.0’” can be a frustrating experience for iOS developers. This error, commonly encountered during the app submission process to the App Store Connect, signifies that you are attempting to upload a binary with a build version that Apple’s servers already recognize for the specific train (version) you’re trying to submit. Imagine spending hours perfecting your app, only to be halted at the final hurdle by this seemingly cryptic message. This article will delve into the root causes of this error, providing you with actionable steps to resolve it swiftly and efficiently, ensuring a smooth app submission process. We’ll also explore best practices to prevent this issue from recurring, saving you valuable time and effort in future app releases. Understanding the nuances of versioning and build numbers is crucial for every iOS developer, and we’re here to guide you through it.

Understanding the Root Cause of ERROR ITMS-9000

The ERROR ITMS-9000: “Redundant Binary Upload” primarily stems from a conflict in the versioning or build number of your iOS application. App Store Connect uses a combination of the version number (e.g., 1.0) and the build number (e.g., 1) to uniquely identify each submission. When you attempt to upload a new binary with the same version and build number as a previously submitted (or even rejected) build, Apple’s system flags it as redundant, triggering this error. The “train” referred to in the error message simply indicates the app version you are trying to update. Think of it like trying to submit the same assignment twice – the teacher (Apple’s system) will recognize that you’ve already handed it in.

Another common cause is incorrectly managing your build versions during the development cycle. For instance, you might have uploaded a build “1.0 (1)” for internal testing, and then inadvertently tried to upload the same build again for App Store review without incrementing the build number. This is especially prevalent in teams where multiple developers are working on the same project and may not be perfectly synchronized on versioning strategies. Furthermore, caching issues within Xcode or Transporter can sometimes lead to incorrect build information being submitted to App Store Connect. According to Apple’s documentation, consistently updating the build number for each submission is crucial for avoiding conflicts and ensuring proper tracking of your app’s iterations [Apple Developer Documentation].

Featured Snippet Optimization: One of the most effective ways to resolve ERROR ITMS-9000 is to increment the build number in Xcode before re-uploading your binary. Navigate to your project settings, select your target, and then under the “General” tab, find the “Version” and “Build” fields. Increase the “Build” number by at least one. This simple step ensures that App Store Connect recognizes your upload as a new, unique build, resolving the redundancy issue. Remember to archive and export your app again after making this change.

Resolving the Redundant Binary Upload Error

Addressing the ERROR ITMS-9000 requires a systematic approach to ensure you are submitting a unique build to App Store Connect. The core solution revolves around incrementing your build number. Here’s a step-by-step guide:

1. Open your project in Xcode.
2. Select your project in the Project Navigator.
3. Choose your target (your app) from the targets list.
4. Go to the “General” tab.
5. Locate the “Version” and “Build” fields under the “Identity” section.
6. Increment the “Build” number. Even a minor increase (e.g., from 1 to 2) will suffice.
7. Clean your build folder (Product > Clean Build Folder). This step helps remove any cached data that might cause issues.
8. Archive your project (Product > Archive).
9. Distribute your app through Xcode or Transporter.

It’s crucial to verify that the changes you made in Xcode are reflected in the archived build. Before uploading, you can inspect the archive to confirm the updated build number. Furthermore, if you are using automated build systems or Continuous Integration (CI) tools, ensure that your build scripts are correctly incrementing the build number automatically. This prevents manual errors and streamlines your deployment process. For example, tools like Fastlane can automate the process of incrementing build numbers and submitting builds to App Store Connect, significantly reducing the risk of encountering this error. [Fastlane Documentation]

Here are some other important considerations:

• Double-check that you haven’t accidentally uploaded the same archive twice.
• If you’re using TestFlight, ensure that the build you’re trying to submit for review isn’t already in TestFlight with the same version and build number.

Best Practices for Versioning and Build Numbers

Adopting a robust versioning and build numbering strategy is paramount for preventing ERROR ITMS-9000 and maintaining a smooth app development lifecycle. A well-defined strategy not only minimizes submission errors but also helps with tracking changes, managing releases, and coordinating team efforts. The semantic versioning approach (MAJOR.MINOR.PATCH) is a widely accepted standard. The MAJOR version indicates significant changes, the MINOR version represents new features, and the PATCH version addresses bug fixes. However, the build number is often independent and should be incremented with each build, regardless of the nature of the changes.

Consider implementing a system that automatically increments the build number with each commit or build process. This can be achieved using CI/CD tools or custom scripts. This automated approach reduces the risk of human error and ensures that each build has a unique identifier. Furthermore, clearly document your versioning strategy and communicate it to all members of your development team. This ensures consistency and prevents misunderstandings that could lead to versioning conflicts. According to a survey by Stack Overflow, teams with well-defined version control practices experience significantly fewer deployment issues [Stack Overflow Developer Survey, year unspecified].

Here’s a summary of best practices:

• Always increment the build number for each submission, even for minor changes.
• Use a consistent versioning scheme (e.g., semantic versioning).
• Automate the build number increment process.
• Document your versioning strategy and communicate it to your team.

Troubleshooting Complex Scenarios

While incrementing the build number usually resolves ERROR ITMS-9000, some complex scenarios might require additional troubleshooting. For example, if you’ve recently transferred your app to a different Apple Developer account, there might be lingering metadata or cached data associated with the previous account that’s causing conflicts. In such cases, contacting Apple Developer Support directly might be necessary.

Another scenario involves using multiple development branches. If you’re merging code from different branches, ensure that the build numbers are properly synchronized to avoid conflicts when submitting builds from different branches. Thoroughly cleaning your derived data and build folders in Xcode can also help resolve persistent issues. You can do this by holding down the Option key and selecting “Clean Build Folder” from the “Product” menu. Furthermore, if you are using Xcode Server or other continuous integration systems, verify that the build numbers are being correctly managed and incremented across all builds.

Remember to carefully examine the error logs in App Store Connect for any additional clues about the cause of the error. Sometimes, the error message might be misleading, and the underlying issue could be related to other aspects of your app’s configuration. In rare cases, there might be temporary issues on Apple’s servers that are causing the error. In such situations, waiting for a few hours and then re-uploading your build might resolve the problem. You can check the Apple Developer System Status page to see if there are any known issues affecting App Store Connect [Apple Developer System Status].

**What does ERROR ITMS-9000 mean?**

It indicates that you're trying to upload a binary with a build version that already exists in App Store Connect for the specified app version (train).

**How do I fix ERROR ITMS-9000?**

The primary solution is to increment the build number in Xcode before archiving and uploading your app.

**Why am I still getting ERROR ITMS-9000 after incrementing the build number?**

Double-check that the incremented build number is correctly reflected in the archived build. Also, clean your build folder and ensure there are no caching issues.

**Can ERROR ITMS-9000 be caused by server-side issues?**

In rare cases, temporary issues on Apple's servers might contribute to the error. Check the Apple Developer System Status page.

**What if I've transferred my app to a new Apple Developer account?**

Contact Apple Developer Support, as there might be lingering metadata from the previous account causing conflicts.

Question & Answer :
I am trying to upload my build on iTunes Connect via Xcode 5.1.1 but it is continuously showing that it is loading and app is not getting uploaded. So I have tried uploading with Application Loader but its showing the below error:

ERROR ITMS-9000: “Redundant Binary Upload. There already exists a binary upload with build version ‘1.0’ for train ‘1.0’”

App status on iTunes is Waiting for Upload. One time the upload was successfully done, but the status is not reflecting and it’s now allowing to upload again.

Also I just checked that website is also changed. Don’t know what’s wrong.

Edit: There was no submit for review button on apples new website. But now I can see that button. That has solved my issue. Also I recommend to upload the build using Application Loader as it’s quicker than organizer.

More than one binary may be uploaded to App Store Connect for the same version, if the the Build number is increasing for each build uploaded to iTunesConnect. The build number just has to be unique (and higher) for each binary that is uploaded (select the Target, then Xcode -> General -> Build, see the picture below). For example in the image below the build uploaded has version 3.1.4 (3.75 in the older image) and the build number is 1. Thus, after uploading this image increase the build to a minimum 2 or higher. Then this binary may also be uploaded to App Store Connect as it’s a later build according to the build number.

The version notes the release version of the app your releasing to the user. The build number remarks the final build of the binary uploaded to the store, i.e. after many bug fixes.

After Xcode 9 you are not able to upload a new build (for the same version), if there is a previous build with the same build number in the store. So, check your build number and increase if not certain.

EDIT: It’s more correct to use 1, 2, 3, 4, etc. for the build number, but the version number has to be increasing, 1.0 -> 1.1 -> 1.2 etc. The build number has to be higher than what was submitted previously for the same version number, if not an error is posted. So, if a new binary is submitted that has version 3.75 and a build 1 has already been submitted, then next build shall be 2 or higher, but the version can still remain 3.75.

New updated and the recommended way of having the build numbers serial:

The older image to match the one below:

After a new binary is uploaded and processed (~5-20 min processing time, if it doesn´t show up upload again and wait), then you can select the new binary and submit it for review. In the picture below you may see the old and the new binary listed in App Store Connect in the Build section of the current App version (you click the plus sign). Then the new binary is selected -> Saved -> Submit for Review. (Sometimes an error comes when submitting, then just try after a few mins or upload a new binary).

For those inclined to do this automatically with an Xcode script, here is a description of making an automatic script for updating Build numbers Better way of incrementing build number?