Same here. I filed 2 feedbacks as I wasn't sure whether to file against Xcode or the SDK. I included a simple test project. Feedback numbers are: FB19254965 FB19254927

For anyone else looking here, this is what I did based on the reply above... It took me a moment to realise I needed to add the authentication keys to the Xcode args, and use something different for Fastlane. For anyone else looking, I added this to the top of my Fastfile before_all do app_store_connect_api_key( key_id: "YOURKEY", issuer_id: "YOUR_ISSUER_ID", key_filepath: "path/to/key.p8" ) end Then when building I have this build_mac_app(xcargs: "-allowProvisioningUpdates -authenticationKeyID YOURKEY -authenticationKeyIssuerID YOUR_ISSUER_ID -authenticationKeyPath /Users/username/key.p8")

I've been having the same issue. Again, was fine in Xcode 15, but very temperamental in Xcode 16. I'm using Fastlane to build and upload iOS versions and then Catalyst versions of two targets. The iOS versions always work perfectly. The Catalyst versions sometimes work. Sometimes one of the targets works and the other fails. Sometimes they both fail. I confirmed that there's nothing that needs agreeing to on the portal, and I've started cleaning the build folder every time just to check. Even stranger is that sometimes, when I go back to Xcode there are many Unknown Apple ID accounts that have been added to the Accounts section. They're not always there after a failed upload. Attaching the image of the failed accounts. The errors I'm seeing in the Fastlane output are: Multiple occurrences of this, presumably due to the extra accounts being created: 2024-10-02 23:55:26.239 xcodebuild[53833:26449828] IDEDistribution: Failed to log in with account "(null)" while checking for an App Store Connect account (Error Domain=DVTServicesAccountBasedSessionErrorDomain Code=0 "Unable to log in with account ''." UserInfo={NSLocalizedFailureReason=Unable to log in with account ''., NSLocalizedRecoverySuggestion=The login details for account '' were rejected., DVTDeveloperAccountErrorAccount=<DVTAppleIDBasedDeveloperAccount: 0x600002390b40; username=''>, NSUnderlyingError=0x6000035617d0 {Error Domain=DVTPortalServiceErrorDomain Code=1100 "Your session has expired. Please log in." UserInfo={payload={ creationTimestamp = "2024-10-02T22:55:26Z"; httpCode = 200; protocolVersion = QH65B2; requestUrl = "https://developerservices2.apple.com/services/QH65B2/viewDeveloper.action"; responseId = "2630ce6d-d3ef-4782-9aad-91d72813d8ee"; resultCode = 1100; resultString = "Your session has expired. Please log in."; userLocale = "en_US"; userString = "Your session has expired. Please log in."; }, error: exportArchive The operation couldn’t be completed. Unable to log in with account ''.

I had similar issues. My .mm file was importing the generated myapp-swift.h header. In that header was @import QuickLook That's the module that was unable to be built. What fixed it for me was updating these build settings: I fixed this issue by updating the following build settings for the project. C Language Dialect to GNU17 C++ Language Dialect to GNU++23 CLANG_CXX_LANGUAGE_STANDARD to GNU++23 You may not have them all.

I'm seeing the same error in beta5. See screenshot,,,

Same issue here. For me the problem only occurs when building with Fastlane and seemed to start when I added a Widget. If I build in Xcode it works fine. Xcode is handling all signing. Keeping an eye on this in case anyone has a solution.

Here's how I fixed it... Select your Extension target and go to Build Settings Search for "module" and look for Packaging -> Product Module Name. You'll probably see that the "Resolved" column is showing the same name as your main target. Type a unique name in the middle column (the column is titled "WidgetsExtension" or whatever your extension target is called) You should see that the "Resolved" column now shows the unique name you entered. It should hopefully build now.

Same issues here.

Same problem here. Commenting so I can follow along.

Same problem here. Commenting so I can follow along.

Same problem here. Commenting so I can follow along.

So it turns out the OpenAL framework isn't available on Catalina, but is on Big Sur. It was being included in my project due to a specific pod, which I removed, and it fixed the issue