SwiftUI List performance

There is however a problem with this solution. If there is a TextField in the popover, typing in makes it firstResponder ; and the parent window controller do not receive mouseEnter events that triggers the tooltips. Which means I do not need to simulate mouseDown but just makeFirstResponder. So at the end, the question boils down to: how to manage the conflict between popover and its parent window about FirstResponder. Is it possible to have first and second responder, I mean forwarding the mouse messages to the parent ? Considering that The shared NSApplication object performs the important task of receiving events from the window server and distributing them to the proper NSResponder objects. NSApp translates an event into an NSEvent object, then forwards the event object to the affected NSWindow object. All keyboard and mouse events go directly to the NSWindow object associated with the event. … When a window object receives an NSEvent object from NSApp, it distributes it to the objects in its vi

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. You wrote: To get info about nearby WIFi networks and filter out company specific SSIDs and to prioritize them Can you expand on that? What are you doing with that SSID list once you get it? It’s hard for me to suggest a path forward without a better understanding of your ultimate goal. [quote='875214022, arnair, /thread/808341?answerId=875214022#875214022, /profile/arnair'] Is there an official deprecation schedule or timeline? [/quote] No. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I can confirm there is something crashing my Apps that only have Launchscreen storyboards. I use Autoresizing and not Autolayout. And guys please, make a real effort to build a Launchscreen component in SwiftUI. It makes no sense in 2026, always ten years after and we still have a storyboard file messing/crashing our Apps in Swift.

Do this: Launch Xcode 26.3rc. File > New > Project. At the top, select iOS. In the main list, select App Playground. Complete the workflow from there. Good luck with your submission! Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi Kevin, Following up on my previous update regarding the registration hang and SAM layer panic. We performed further experiments using the Selection Timeout (SERVICE_DELIVERY_FAILURE) approach as you suggested. Below are the results: 1. Selection Timeout Experiment Results We modified the DEXT to report SERVICE_DELIVERY_FAILURE immediately for Bundled commands arriving before the registration returns. We confirmed fControllerTaskIdentifier matches the request. Stability Improvement: With this change, any attempt to unplug the hardware or deactivate the DEXT no longer triggers a Kernel Panic. Resource lifecycle management (retaining/releasing descriptors) is now functioning correctly. Persistent Hang: Despite reporting the timeout, UserCreateTargetForID remains hung indefinitely and never returns on its own. 2. Log Evidence: The Unlock Mechanism The logs show that the kernel registration thread is blocked until a termination signal is received. Log A: Hang after Selection Timeout default 14:00:07.77

Does anyone know if Apple has plans to fix this issue? We are facing this issue in our SwiftUI forms as well, and trying to work around it introduces fiddly issues with inter-op between UIKit and SwiftUI input fields requiring focus.