We use the xcodebuild -exportArchive command to export our app. This command has code signing issues with Xcode 13, where apparently a communication with Apple failed. The command is executed on macOS 12.0 Beta (21A5304g). By switching to Xcode Version 12.2 (12B45b) using xcode-select, the export works under equal conditions! This seems to be a regression in Xcode 13. Our iOS and Mac App Store builds export fine, this only affects the developer-id build. I would like to ask if this is a bug/regression that we can expect to be fixed. If you need further information / logs, I will happily provide them. The command: xcodebuild \ -exportArchive \ -archivePath „xy.xcarchive" \ -exportOptionsPlist "ExportOptions.plist" \ -exportPath „$exportPath“ \ -allowProvisioningUpdates The command output: Error Domain=DeveloperAPIServiceErrorDomain Code=5 "Communication with Apple failed." UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedRecoverySuggestion=You are not allowed to perform this operation. Please check with one of your Team Admins, or, if you need further assistance, please contact Apple Developer Program Support. https://developer.apple.com/support, NSLocalizedDescription=Communication with Apple failed.} error: exportArchive: No profiles for ’bundle-identifier’ were found Error Domain=IDEProfileLocatorErrorDomain Code=1 "No profiles for 'bundle-identifier' were found" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedDescription=No profiles for 'bundle-identifier' were found, NSLocalizedRecoverySuggestion=Xcode couldn't find any Developer ID provisioning profiles matching 'bundle-identifier'.} error: exportArchive: Communication with Apple failed. Error Domain=DeveloperAPIServiceErrorDomain Code=5 "Communication with Apple failed." UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedRecoverySuggestion=You are not allowed to perform this operation. Please check with one of your Team Admins, or, if you need further assistance, please contact Apple Developer Program Support. https://developer.apple.com/support, NSLocalizedDescription=Communication with Apple failed.} error: exportArchive: No profiles for 'bundle-identifier.shareextension' were found Error Domain=IDEProfileLocatorErrorDomain Code=1 "No profiles for 'bundle-identifier.shareextension' were found" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedDescription=No profiles for 'bundle-identifier.shareextension' were found, NSLocalizedRecoverySuggestion=Xcode couldn't find any Developer ID provisioning profiles matching 'bundle-identifier.shareextension'.} Also filed as FB9560862.

Hi, we have a fairly large Objective-C only codebase for iOS and macOS. We plan to introduce a new, isolated cross-platform view and figured to give Swift and SwiftUI a try in this scenario. When preparing the project file, we ran into a linker error when using SwiftUI previews. The error was caused in the AppCenter framework and only occurs on iOS. macOS had no issue starting the preview, even though it uses the same framework. Our solution was to add the required Libraries and Frameworks within the conditional Other Linker Flags parameter of the project settings. However, we are still curious on why the error occurs only on iOS and why SwiftUI previews have linker issues while normal simulator / device builds are fine.

We are currently trying to adopt the newly introduced find bar in our app. The app: The app is a text editor with a main text view. However it includes nested views (for text like footnotes) that are presented as modal sheets. So you tap on the footnote within the main text, a form sheet is presented with the contents of the footnote ready to be edited. We have an existing search implementation, but are eager to move to the system-provided UI. Connecting the find bar through a custom UIFindSession with our existing implementation is working without any issues. The Problem: Searching for text does not only work in the main text view, but also nested text (like footnotes). Let's say I have a text containing the word "iPhone" both in the main text and the footnote. In our existing implementation, stepping from the search match to the next one would open the modal and highlight the match in the nested text. The keyboard would stay open. With the new UIFindInteraction this is not working however. As soon as a modal form sheet is presented, the find interaction closes. By looking at the stack trace I can see a private class called UIInputWindowController that cleans up input accessory views after the modal gets presented. I believe it is causing the find panel to give up its first responder state. I noticed that opening popovers appears to be working fine. Is there a way to alter the presentation of the nested text so that the view is either not modal or able to preserve the current find session? Or is this unsupported behavior and we should try and look for a different way? The thing that really confuses me is that this appears to work without issue in Notes.app. There the find bar is implemented as well. There are multiple views that can be presented while the find bar is open. Move Note is one of them. The view appears as a modal sheet. It keeps the find bar open and active, though its tint color matches the deactivated one of the main Notes view. The find bar is still functional with the text field being active and the overlay updating in the background. This behavior appears to be a bug in the Notes app, but is exactly what we want for our use case. I attached some images: Two are from the Notes app, two from a test project demonstrating the problem. Opening a modal view closes the find bar there.