Is it possible to turn on Stage Manager on Xcode's iPadOS simulator?

Hi, I'm working on a View Controller where the Navigation Controller's UIBarButtonItems, composed of SF Symbol images and/or System Items, should change their tint color based on the current Navigation Controller scroll edge or default appearance. let buttonAppearance: UIBarButtonItemAppearance = .init(style: .plain) buttonAppearance.normal.titleTextAttributes = [.foregroundColor: color] standardAppearance.buttonAppearance = buttonAppearance I've used UIBarButtonItemAppearance titleTextAttributes to successfully change a UIButton's label text color, but I wasn't able to find a supported method under the UIAppearance API to do the same update to images. I'd highly appreciate clarification on whether or not it is supported and, if not, what could be some alternatives. Specs: iOS 16+ Thanks!

Running a Process executableURL path for a Catalyst target using a macOS type bundle returns the following error as output: (/Applications/Xcode-15.1.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Debugger/libViewDebuggerSupport_macCatalyst.dylib), but incompatible platform (have \'MacCatalyst\', need \'macOS\')) Is it possible to set which dylib platform is used by the macOS bundle executable file instead of using the MacCatalyst one?

Using NSMenuItem's delegate method menu(_ menu: NSMenu, willHighlight item: NSMenuItem?) should return a nil item when the mouse location is moved out of the NSMenu window or if any of the items should not be highlighted. As per Apple Developer website: Only one item per menu can be highlighted at a time. If item is nil, it means that all items in the menu are about to be unhighlighted. But, on macOS Sonoma, when moving the mouse over a .sectionHeader and/or a Separator item, willHighlight won't be called, which makes it not return any item (neither nil, nor the section header). This behavior makes it impossible to use willHighlight method to determine whether custom views should be highlighted or not. Is this a bug or expected behavior?

Specs: macOS Sonoma 14.3.1 Using NSMenu's submenus with a list of NSMenuItems (with or without custom views) will produce a hang for the first time they are presented. The larger the list, the more time the UI will be frozen before presenting the submenu. Is there something that can be done to mitigate this behavior?

On a submenu (NSMenu), items that use custom views as part of their layout, do not call NSMenu's delegate willHighlight method. The method is called correctly when placing the same items with custom views inside the root/parent NSMenu. Steps Create a NSMenu with at least two NSMenuItem; One with a custom view and another without it. Add a submenu to the item without a custom view; make sure to set the submenu's delegate Add multiple items to the submenu; Make sure some of the items are using custom views Using one of NSMenu's delegate method, willHighlight, check if it will return an item when hovering over the custom view items inside the submenu Notice it will only return when hovering over items that do not use a custom view. Expected Result NSMenu's willHighlight method should be called and inform with item with custom view should be highlighted inside the submenu. Tests done on macOS 14.3.1 and 14.4.1. Xcode 15.2 and 15.3.

After popping up a NSMenu a few times, NSResponder's mouseExited event is called even when the cursor is inside the tracking area, returning the main app window's max X value, which makes the mouseEntered/Exited methods unusable for tracking whether or not cursor is currently inside the view's frame. Steps Create a NSMenuItem with a custom view inside Add a tracking area to the views frame Add a background color that changes on mouseEntered/Exited Open and close NSMenu a few times until the color starts flickering when moving the cursor inside the view's frame If possible, print out NSEvent's locationInWindow on both mouseEntered and Exited and see that the location for exited method is not being reported correctly, while the flickering from the bg color being set is happening. Expected Result mouseExited should only be called the cursor leaves the tracking area. locationInWindow values should not exceed the NSPopUpWindow's frame. Tested on macOS Sonoma 14.3.1 and 14.4.1; Xcode 15.2; Feedback ID https://feedbackassistant.apple.com/feedback/13698735

New versions of AppKit/Mac Catalyst apps that use Google's Sign In framework are being rejected by App Store Review for the past two weeks. Reason shared was: The user is taken to the default web browser to sign in or register for an account, which provides a poor user experience. And also citing: Data Collection & Storage guidelines -> https://developer.apple.com/app-store/review/guidelines/#data-collection-and-storage Opening macOS' default web browser has been a native behavior of Mac apps when using SFSafariViewController with ASWebAuthenticationSession, which is required, since iOS 13, for securely/privately logging in users. As far as I could investigate, there hasn't been any updates to the guidelines that would indicate any required changes to developers in regards to how login works for macOS apps. Are there any steps developers need to take to get updates approved while still providing users with Google's Sign in? As reference, there is an on-going discussion on GoogleSignIn repo about this issue affecting multiple developers and apps: https://github.com/google/GoogleSignIn-iOS/issues/388