ITMS-90207: Invalid Bundle. The bundle at 'Runner.app' does not contain a bundle executable.

Sharing the full email I sent to Apple Support

I am consistently encountering the ITMS-90207 error "Invalid Bundle. The bundle at 'Runner.app' does not contain a bundle executable." when attempting to upload my Flutter iOS app to App Store Connect via both Transporter and direct upload from Xcode Organizer. This issue persists despite extensive troubleshooting and thorough local validation, which shows the IPA is correctly formed.

App Details:

• App Name: OnOn
• App Store Connect App ID: 6502598657
• Bundle Identifier: com.onon.app
• Latest Version/Build Attempted: Version 1.0.24, Build 50

Error Details:

• Exact Error Message: Invalid Bundle. The bundle at 'Runner.app' does not contain a bundle executable. (ID: [e.g., f548c384-73e9-4f09-96a0-363b7d67f650 from your log])
• Transporter Log Reference: From my Transporter logs, the specific iris-code is STATE_ERROR.VALIDATION_ERROR.
• Example Build ID from Transporter Log: [e.g., 6bd99937-1283-486e-a245-419ea29443f0] (This ID might vary with each attempt, but providing a recent one helps them trace).
• Timestamp of latest failed upload: [Provide the UTC timestamp from your Transporter log, e.g., 2025-07-18 19:06:49 UTC]

Local Environment Details:

• Operating System: macOS 15.5 24F74 (arm64)
• Xcode Version: 16.3 (16E140)
• Transporter Version: 1.3.3-13326
• Flutter Version: 3.29.0
• CocoaPods Version: 1.16.2

Troubleshooting Steps Performed (Extensive):

1. Full iOS Project Regeneration: Deleted ios/ folder, recreated using flutter create . --platforms=ios.

2. Podfile Configuration:

Set platform :ios, '16.0' (or 13.0 depending on what you settled on).

Consolidated post_install hooks into a single block to enforce ARCHS = 'arm64' and VALID_ARCHS = 'arm64' for all configurations.

Confirmed pod install --repo-update completes successfully.

1. Xcode Project Settings Verification:

Manually confirmed Bundle Identifier in Runner.xcodeproj (General tab of Runner target) is exactly com.onon.app.

Confirmed Signing & Capabilities are correctly configured for App Store Distribution (Automatic Signing, correct Team).

Confirmed Build Settings for Runner target:

Architectures: arm64 (Standard Architectures)

Valid Architectures: arm64

Build Active Architecture Only: No for Release.

Excluded Architectures: No exclusions for Release.

1. Firebase Integration: Ensured GoogleService-Info.plist is correctly placed and sourced from the production Firebase project for com.onon.app. (Note: Not using firebase_options.dart in the app, relying on native config files).

2. Aggressive Cleaning: Multiple flutter clean, pod deintegrate, removal of Pods/, Podfile.lock, and ~/Library/Developer/Xcode/DerivedData/* cycles.

3. IPA Generation Methods: Attempted flutter build ipa --release and direct "Archive" then "Distribute App" > "Upload" from Xcode Organizer. Both yield the same ITMS-90207 error during validation.

4. Info.plist Clean-up: Removed any manually added CFBundleExecutable or CFBundlePackageType keys, reverting to the standard $(PRODUCT_BUNDLE_IDENTIFIER) placeholder. (Confirmed this fixed the "CFBundlePackageType" error).

Crucial Local Diagnostic Results (from the IPA that failed upload):

I have performed detailed analysis of the Runner.app executable within the generated IPA that consistently fails validation. The results indicate a correctly formed binary:

Architecture Check (lipo -info Runner): Non-fat file: Runner is architecture: arm64 (This confirms the binary contains only the arm64 architecture, ruling out fat binary issues.) * Code Signing Verification (codesign -vvv Runner):

Runner: valid on disk Runner: satisfies its Designated Requirement (This confirms the executable is properly signed and not corrupted.)

Entitlements Check (codesign -d --entitlements :- Runner):

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0"><dict>

<key>application-identifier</key><string>6N74W47GWA.com.onon.app</string>

<key>beta-reports-active</key><true/>

<key>com.apple.developer.team-identifier</key><string>6N74W47GWA</string>

<key>get-task-allow</key><false/>

</dict></plist>

Request: Given that all local diagnostics indicate a valid and correctly signed arm64 executable within the IPA, I am unable to identify the reason for the ITMS-90207 error. Could you please investigate this specific error from your end? Please check your internal validation logs for build attempts associated with App ID 6502598657 around [latest timestamp/date] (e.g., July 18, 2025, 19:06 UTC). Any specific details from your swinfo tool or other internal validation processes would be greatly appreciated to help resolve this issue.

Thank you for your time and assistance.

I would look in the built app to make sure that the CFBundleExecutable key in the Info.plist file is present, and that its value is the name of your main app binary that is located at the root of your .app. And of course, that binary file must be present in the package as well.

If that much is good, then I'd also check that the binary file is an actual executable, and not some other type of Mach-O binary. An easy way to do that is to run otool -hv /Path/To/Your.app/YourMainExecutable in Terminal, and make sure that the file type is listed as EXECUTE.

Checking in the built app as the starting point here means that I would unpack the .ipa file you are submitting to the App Store by unzipping it — you can change the extension to .zip to make that easy to do so with the built-in macOS Archive Utility. The Info.plist file inside the built app sources its contents in several ways, including values set in a "source" Info.plist file that you check in as part of your source code, there are build settings with values that get set during the build, and also additional processing by Xcode during the build process. Thus with that combination of things, I always work backwards from the built app result — what the App Store is seeing — to understand the contents of the built app and potential reasons you are seeing a specific error during the App Store's validation, and then take that information back up through the app's build and configuration in Xcode to figure out the configuration that produced that built app.

If you find that the contents of the built app deviates from my suggestions above, then you'll need to start backtracking from there into your build process. I'd suggest taking a brand new Xcode project (created through Xcode's File > New Project new project menu item), and comparing all of its build settings to that of your real project. Since your project was configured through third-party tools, namely Flutter, the goal here is to identify what is different in a project created by Xcode and through your third-party tool. Once you find how your project is configured differently than what Xcode's standard new project does, you'll need to check in with the support for Flutter, since there might be adjustments needed in their software or configurations you have with their tools that is leading to the source of this error for you.

— Ed Ford,  DTS Engineer