“swiftui”

I’m seeing what appears to be the same regression on iOS 27 Beta 5 in a production SwiftUI app. In my case the affected UI is a horizontal filter/action: ScrollView(.horizontal, showsIndicators: false) { HStack(spacing: 8) { groupMenu sortMenu templatesButton voiceButton } .padding(.horizontal, 16) .padding(.vertical, 8) } The controls are a mixture of native SwiftUI Menu and Button views rather than one custom control implementation: Group: Menu Sort: Menu Templates: Button Voice: Button On iOS 27 Beta 5 the controls render normally, but taps around the centre/upper portion of the controls are frequently ignored. Tapping toward the lower edge of the same visible control can trigger it. The important part in my case is that multiple different control types in the same horizontal ScrollView exhibit the same behaviour. The actions themselves are working — when the tap is recognised, the menu opens or the button action runs normally. The surrounding screen uses a normal NavigationStack with an

@DTS Engineer Xcode 27 Beta 5 seems to crash quite often, I think it happens when I edit code. I think SwiftUI preview was trying to render while I was editing. I have submitted the crash reports, by clicking Send to Apple button on the crash report. Hopefully they can be fixed, Xcode 27 Beta 4 didn't crash like this, seems to be happening on Xcode 27 Beta 5.

@astro-spacecadet, did you ever find a workaround or file a Feedback for this? If you have an FB number, I'd like to reference it in mine. I'm hitting exactly this in a production watchOS app (Apple Watch Ultra 3, watchOS 26.6): alerts present and dismiss normally on tap, but their button closures never execute - combined with every screen-transition animation going dead (pushed views snap into place, the nav-bar clock gets stuck mid-transition position). One difference from your case: mine heals on a true scene .background transition (crown press), no force-quit needed. With an active HKWorkoutSession the app never backgrounds on its own, which is why the broken state can persist for an hour of real use. I instrumented every alert (present / action-fired / dismiss edges) plus sheet lifecycle events, and caught a full wedged session in the field. Findings: 44 consecutive alert present→dismiss cycles with zero actions fired, across 4 different alerts on 3 different presenters - including one attached directly

Hello @MrWizardCoder, SwiftUI's .task is a view modifier that inherits the cancellation behavior of Swift.Task. For updates to the documentation, feel free to add your suggested wording in a Feedback request through Feedback Assistant.  Travis

UPDATE: The NSStatusItem does not receive mouse hover/movement events on macOS (FB23329983) seems to be fixed in macOS 27 dev beta 5 (build 26A5406e). The following issues still remain: inability to set NSStatusItem button highlight cannot be set programmatically (B23330269), for which expandedInterfaceDelegate gives a partial solution. NSStatusItem window occlusionState no longer reflects hidden menu bar visibility (FB23349447) Additionally, there is a somewhat serious design issue/oversight with expandedInterfaceDelegate and expandedInterfaceSession when it comes to implementing touch support. With a custom menu bar extra window implementation (when one uses a custom NSWindow or NSPanel and for the menu bar extra app's window together with the new expandedInterface..., instead of relying on the traditional NSMenu or NSPopover attached to a menubar extra status item) there is no mechanism at all to detect touch tap gesture outside of the window. This would be essential to figure out when the user wants to di

Hi @DTS Engineer and @fpiovezan, I filed FB24278299 for this issue. The problem still reproduces with Xcode 26.6 (17F113) and iOS 26.6 (23G71) on an iPhone 15 Pro Max over Wi-Fi, using an unmodified SwiftUI/SwiftData iOS App template. With “Debug executable” enabled over Wi-Fi, the first screen remains unresponsive for approximately 40 seconds. The same template has no noticeable delay over Wi-Fi with “Debug executable” disabled and becomes responsive in approximately 5 seconds over USB with LLDB attached. FB24278299 includes the minimal project, recordings, Xcode Launch Results, exact timestamps, synchronized Mac and iPhone diagnostics, CoreDevice and Xcode diagnostics, and the requested Accessibility settings evidence. Please associate it with FB20344064, FB20359822, and FB21378487 if appropriate. Thank you for looking into this and for the earlier guidance in this thread.

Dear @AlexeyVasilkov, @HuijieLin, Could either of you please provide a small test project that replicates this issue? You could provide a link to download the project. If you're not familiar with preparing a test project, please take a look at Creating a test project. To answer the questions in the OP: Is it expected that iPadOS renders LaunchScreen.storyboard based on the interface orientation / size class rather than the actual window bounds in multitasking scenarios? This would not be the case, except if UIRequiresFullScreen is set to true, causing your app to be in compatibility mode, making your scene’s interface orientation to match the aspect ratio of the scene bounds. (Note: this key is deprecated as of iPadOS 26. For details, please see technote TN3192: Migrating your iPad app from the deprecated UIRequiresFullScreen key.) If not expected, what is the recommended way to ensure the Launch Screen matches the app’s actual window size/aspect ratio at launch (without using code, since Launch Screen is sta