I'm building a MacCatalyst app, where the Tab key is used for a special functionality within the app. For that, I inserted a UIKeyCommand in the main menu for "\t". When I press Tab, the default functionality takes over, and the focus moves to a button in the toolbar and stays there, which I don't want. As a result, the action of my key command is not called. I set tabKeyCommand.wantsPriorityOverSystemBehavior = true, but it makes no difference. The root view controller of my app is an UISplitViewController. I overloaded 'shouldUpdateFocus(in:)' and always return false hoping that this will disable moving the focus for the whole app, but it's not working. It looks like it's more difficult then needed. How can I instruct the system to not interfere with the Tab key?

I have a doc app consisting of two types of scenes, "Default Configuration" and "About". When an about scene is created, I set its activation condition to NO, so it does not get activated for any userActivity or URLContext: scene?.activationConditions.canActivateForTargetContentIdentifierPredicate = NSPredicate(value: false) Now, I open an about scene and some default configuration scenes. If the about scene is on top, then when opening a handoff user activity, this about scene gets activated instead of the default ones, or a new default scene being created. If the about scene is in background or it is not created, a correct default scene is activated and passed the activity. Opening documents from finder works fine in both cases, a default scene is activated and it gets URLContext objects. Is this the expected behaviour? I found a workaround but it feels like a workaround. I enable activation on the about scene: scene?.activationConditions.canActivateForTargetContentIdentifierPredicate = NSPredicate(value: false) Then in the about scene, I listen to scene(_:userActivity:), get the activity when it gets activated, pass it to UIApplication.shared.delegate, which in turn requests a new scene activation and passes the activity object to this new scene. In this case, a scene with the correct default configuration gets activated. I'm running the tests on macOS 12.4 if it matters.

Swift class indentation is eating useful horizontal space, and it's not much helpful, apart from being consistent. How can I disable it? I know that I can disable it altogether, but I want to keep the auto-indentation for the rest of {} blocks, it's useful.

I downloaded the simulators, opened the DMGs, and copied them to the library. Then I start Xcode and it enters an infinite loop of "Cannot open because unverified...". I keep pressing "Open Anyway" in the Settings app, it keeps telling me "Cannot open because unverified blah blah...". I tried following the hints in this thread (https://developer.apple.com/forums/thread/732324) but no luck, I only wasted hours of work So, Apple, how to install visionOS 1.0 in Xcode 15 beta 2, such a way that it works??

I have added Siri capability for an iOS/MacCatalyst app in Xcode. The app compiles just fine for iOS, but when compiling for MacCatalyst I get the error: “/Volumes/xdrive/M2/M2.xcodeproj Provisioning profile "Mac Catalyst Team Provisioning Profile: com.anotherview.M2.mac" doesn't include the com.apple.developer.siri entitlement. ” On the “Signing & Capabilities” page I get the error: “Automatic signing failed Xcode failed to provision this target. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator.” How can I add Siri capabilities on a Mac Catalyst app?

Got some crashes in Xcode Organizer from a macCatalyst app and they are not symbolicated. The crashes are from an X86-64 machine, and my work machine is M1. When trying to symbolicate them in Organizer I get an error: "Unable to Symbolicate Crash - An error occurred attempting to symbolicate crash. Unable to locate dSYMs for ...". It makes sense, as I only run the app on M1, and maybe the X86-64 was not built on this machine. I then went to download the dSYM file from AppStoreConnect/TestFlight/Build Metadata, but there is no "Download dSYM" link, even though the app page says "Includes Symbols Yes". I then tried to compile the app for "AnyMac (Mac Catalyst, Apple Silicon, Intel)", and now I get a binary with two images, the arm64 and the x86, but the UUID of x86 image is different than the one from the crash file. How can I get the original dSYM to symbolicate crashes from production?

I am building an app for iOS and MacCatalyst that indexes files by storing their local paths. Because the app relies on the file remaining at its original location, I only want to accept items that can be opened in place. I am struggling to determine if an item is "Open In Place" compatible early in the drag-and-drop lifecycle. Specifically: In dropInteraction(_:canHandle:) and dropInteraction(_:sessionDidUpdate:), calling itemProvider.registeredTypeIdentifiers(fileOptions: [.openInPlace]) returns an empty array. Only once the drop is actually committed in dropInteraction(_:performDrop:) does that same call return the expected type identifiers. This creates a poor user experience. I want to validate the "In Place" capability at the very start of the session so the drop target only activates for valid files. If an item is ephemeral (like a dragged photo from the Photos app or a temporary export), the drop zone should not react at all. How can I reliably detect if an NSItemProvider supports .openInPlace before the performDrop delegate method is called?