In this article

When App Store Connect rejects a build number, inspect CFBundleVersion in the archive actually uploaded. Do not assume that the value in Flutter's pubspec or Xcode's open project is the value inside that archive. Preserve the exact rejection because different versioning errors need different corrections.

Apple's upload-build workflow, checked October 8, 2026, explains how uploaded builds are associated with app versions. This article focuses on tracing effective archive values, not inventing a universal numbering formula.

Distinguish the two version fields#

The marketing version and the build version serve different purposes. In an iOS app bundle, inspect CFBundleShortVersionString and CFBundleVersion separately. Your team's label “version” is too ambiguous for a rejection investigation.

Capture the expected app identifier, platform, marketing version and build number, then compare them with the uploaded archive and App Store Connect's existing record. An inverted pair of fields or a stale archive can look like a counter problem.

Do not assume a build-number rule for one platform applies unchanged to every Apple platform. Use the precise provider message and current documentation for the target.

Read the packaged values#

On a Mac, an illustrative read-only inspection is:

sh
/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' \
  'Example.xcarchive/Products/Applications/Example.app/Info.plist'
/usr/libexec/PlistBuddy -c 'Print :CFBundleVersion' \
  'Example.xcarchive/Products/Applications/Example.app/Info.plist'
/usr/libexec/PlistBuddy -c 'Print :CFBundleShortVersionString' \
  'Example.xcarchive/Products/Applications/Example.app/Info.plist'

Replace the example path with the archive and app that exist in your build. Keep these observations with the archive checksum. If the upload tool used another export or archive, inspect that object as well.

Trace configuration precedence#

Review the Flutter version declaration, explicit build arguments, selected scheme/configuration and Xcode's resolved version settings. A wrapper can override a source-file value. A release scheme can select a different configuration from the one a developer inspected interactively.

For a hypothetical Flutter project, --build-name selects the marketing version and --build-number selects the build number through Flutter's build workflow. Use your installed tool's help and project mapping to confirm the effective result; do not fix an iOS rejection by changing an unrelated Android code.

Record each candidate source of the value and whether it applied to the failing archive. This reduces guesswork when several configuration layers contain similar numbers.

Avoid rebuilding before checking an uncertain upload#

If the client disconnected, first determine whether Apple accepted the build. Apple's upload guidance describes where uploaded builds become available after processing. A local error is not always a provider rejection.

If a genuinely new binary is needed, allocate an appropriate new build version according to the exact error and target platform. Rebuild, inspect the packaged values and verify the file selected for upload.

Keep the numbering correction narrow#

Changing signing identities, bundle IDs or marketing versions merely to escape a build-number error can create unrelated release problems. Correct the layer that supplied the wrong value, then retain the rejected and corrected archive identities for comparison.

When generated code changes several settings at once, use our AI-generated code review checklist. The acceptance evidence is the expected packaged values plus the next provider result—not an edited pubspec alone.