ITMS-90158

When submitting our app to AppStore connect we received the following error: ITMS-90034: Missing or invalid signature - The bundle 'com.xxxxxxx' at bundle path 'Payload/XX.app' is not signed using an Apple submission certificate. Solved We just resubmitted the app.

Hello Apple Developer Community, I’m facing an issue when submitting my iOS app to App Store Connect. ITMS-90429: Invalid Swift Support libswiftDarwin.dylib, libswiftMetal.dylib, libswiftCoreAudio.dylib, libswiftsimd.dylib, libswiftQuartzCore.dylib, libswiftos.dylib, libswiftObjectiveC.dylib, libswiftDispatch.dylib, libswiftCoreGraphics.dylib, libswiftCoreFoundation.dylib, libswiftUIKit.dylib, libswiftCoreMedia.dylib, libswiftCore.dylib, libswiftFoundation.dylib, libswiftCoreImage.dylib aren’t at the expected location: /Payload/Runner.app/Frameworks. Move the file to the expected location, rebuild your app using the current public (GM) version of Xcode, and resubmit it. My setup: Using Flutter for iOS development Flutter version: 3.32.8 Xcode version: Version 16.3 What I have tried so far: Cleaned build folder: flutter clean Upgraded Flutter and CocoaPods to the latest version. Rebuilt the project using latest Xcode GM version. Verified that Always Embed Swift Standard Libraries is set to YES in Xcod

Hello, i know this topic is here since ever, also in other forums, however this topic i face for a month and cant get pass it, I tried all other suggestions which didnt bring me anywhere. so, project using cmake in order for Qt creator (so c++ base project with enabled swift), however once i run a cmake which generates *.xcodeproj for Xcode, i open it via xcode and can properly build and deploy to device. however when I try to archive and sent to Testflight/AppStore, I get: ITMS-90426: Invalid Swift Support and when I try to followup guides to create it manualy, copying libs from: $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) plese here note, that ALL guides indicate to use folder swift, however there are no *.dylib files... they are only in swift-5.0 folder then I receive an error type: ITMS-90429: Invalid Swift Support - The files libswiftMetal.dylib, libswiftHomeKit.dylib, libswiftsimd.dylib, libswiftCallKit.dylib, libswiftos.dylib, libswiftNetwork.dylib, libswiftMapKit.dylib, libsw

Trying to upload an iOS26 app archive with Xcode 26 beta 7 and getting ITMS-90717: Invalid large app icon, meaning my app is not eligible for TestFlight testing. My App contains an IconComposer .icon asset, so I'm not sure what it's complaining about. I'm not seeing anything in the release notes about this, and I'm not sure if I'm doing something wrong or not.

Hi, When submitting my iOS app that integrates the TwilioVoice SDK (v6.12.1+), validation fails with the following error: Upload failed with errors: Validation failed The app references non-public selectors in Payload/careqb.app/careqb: _isKeyDown, _modifiedInput, _modifierFlags (ID: 34774fb-ba69-4131-904f-694aead106d7) Steps to reproduce: Integrate TwilioVoice using CocoaPods (v6.12.1). Archive the app in Xcode 16.x. Validate for App Store Connect. Question: Is this a known false positive in App Store validation, or is TwilioVoice exposing private APIs internally? What’s the recommended way to proceed until Twilio releases a fix? Thanks, Ashutosh

Project Background: I developed a Mac project using Electron and VSCode Successfully uploaded the packaged pkg using Transporter, However, I will receive an email informing me that there are some issues with the project: ITMS-90296: App sandbox not enabled - The following executors must include the 'com. apple. security. app sandbox' entitlement with a Boolean value of true in the entitlement property list: [[com. electron. iflyrecclient. pkg/Payload/iFlytek Listen. app/Contents/MacOS/iFlytek Listen]] ITMS-90886: 'Cannot be used with TestFlight because the signature for the bundle at' iFlytek hears. app 'is missing an application identifier but has an application identifier in the provisioning profile for the bundle.' Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight.' Here is my packaging process: Generate an app using the electron packager tool Sign the app using @ electron

App Store Connect rejects the build with the following error: Please correct the following issues and upload a new binary to App Store Connect. ITMS-90058: This bundle is invalid - The value for key CFBundleVersion [iphoneos] in the Info.plist file must be a period-separated list of at most three non-negative integers. Please find more information about CFBundleVersion at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion But we double-checked at the app level; in all places the CFBundleVersion and versions is mentioned in the correct format. Even though we tried to upload via Xcode and Transporter, both show success. but the build is not reflecting in TestFlight. Receive the above error message via mail. data: { attributes: { cfBundleShortVersionString: 3.25.9, cfBundleVersion: 25, p Validated with the delivery log, but the delivery log also shows correct versioning only.

My app (com.onon.app) consistently fails App Store Connect validation (ITMS-90207: Invalid Bundle) despite passing all local diagnostics (valid arm64 binary, correctly signed, appropriate entitlements). Is there a known issue with Apple's validation server, or are there obscure validation rules I might be missing? Diagnosic info Architecture Check (lipo -info Runner): Non-fat file: Runner is architecture: arm64 Code Signing Verification (codesign -vvv Runner): Runner: valid on disk Runner: satisfies its Designated Requirement 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 Has anyone encountered a similar issue with a Flutter app that passes local code signing checks but is rejected by App Store Connect? Are there any known edge cases or obscure validation rules that aren't covered by standard code signing diagnostics? I've also opened a Technical Support Incident with