+1

Did you sort this? The focus ring display is not mutually exclusive (buggy).

Likewise, in Xcode 15 and 16 beta 1-3.

The builder you want is iOS 17.4 forward; so to support 17 and 18 you'll need a minimum of 17.4.

Similar error for a view within an SPM target (attached). Filed FB11663508. Using Version 14.0.1 (14A400). Preview error

@DeveloperToolsEngineer That wipe did not resolve the crash for the view located in an SPM module of an iOS project using Xcode 14.0.1 (14A400) on macOS 12.6 (21G115). Filed FB11663508.

I was trapped by this error even though I installed Xcode 14 release via the xip and that installation worked fine for two days through several reboots. Even after deleting the newly non-functional installation, the App Store update process was still spinning forever. After a restart, I decompressed the xip again, copied it over, and boom Xcode now works.

Ditto! It respects dailyEnd, but not dailyStart. This query will yield an empty array. Removing dailyEnd will return 10 days of June. https://weatherkit.apple.com/api/v1/weather/en/41.029/-74.642 ?dataSets=forecastDaily &currentAsOf=2022-01-01T00:00:00Z &dailyStart=2022-01-01T00:00:00Z &dailyEnd=2022-01-07T00:00:00Z &timezone=Americas/Los_Angeles &countryCode=US It's probably forthcoming later this summer, but filed FB10383199.

Bump +1

Same, even on a blank new template project.

Can confirm this, too, which is too bad. If I want to compose a toolbar with items inside the Sidebar section, near the title, and right aligned in the document section, I have no choice but to force the non-sidebar toolbar to reload on every navigation change. It's a waste to rebuild it. Maybe it's an instrument's ghost, but also a large number of traces do not reference any code... app or Apple.

I’m confused. Why do you make AState a singleton and pass it through the environment?

Same question, no luck. Filed FB9067349. Elements in a List on macOS 11 that contain a TextField work as expected. Clicking on the field triggers item selection. Hovering a bit reveals the editable field. However, List selection is obviated when adding a button or an element with a gesture, simultaneousGesture, or highPriorityGesture with or without masks or with a built-in or custom Primitive Button Style accepting only double tap gestures. This results in poor UI for a macOS app where double tap in a list would be an expected behavior that differs from a single tap. Unfortunately, the only workaround seems to be adjust UI with a "go" marker to the side... or skip a SwiftUI implementation. Weirdly, adding a gesture to the list item background works... once, and then starts seizing up.