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.

Classic

Ah, interesting. I've always relied on Xcode to automatically sign, will take a look at triggering it manually beyond just the Signing Capabilities settings section. I'll try your tip later and call Apple if I can't sort myself out. Luckily my update to that app isn't urgent.

It's six months too late, but here's two potential approaches: (a) extend Bindings to have an eavesdropping function that gossips about changes to CoreData-updating functions (b) customize the @State variable used by the TextField The answer below seems long, but it's actually very little code and fairly easy. I just overexplain things, sorry. The Extension Approach TextField will still use your vanilla in-memory @State variable. To overhear changes in the binding, add the extension below minus my comments. ExtBinding.swift import Foundation import Combine extension Binding { 		func didSet(_ then: @escaping (Value) -> Void) -> Binding { 				return Binding( 						get: { return self.wrappedValue }, 						set: { 								then($0) 								self.wrappedValue = $0 						} 				) 		} } Line 4 —— Extension means "gives all Bindings the ability to use the new function below" Line 5 —— This "layers" a new Binding that doesn't disturb reading data, but 					does do something special when you write. That something special Line 9 —— is "then($0)", which escapes the new wrappedValue outside this function, 					so you can do something unique inside your View. Finally — I put this in a separate file, even a separate Extensions folder, 					so it's easy to find for someone else or me in six months. Now, add .didSet { } after the TextField's text binding, as below. A few notes: If you're missing the function parentheses, I left them off. Swift lets us do so for closures at the end of a function. When the binding is updated by typing, anything I write in that closure will be executed. Inside the closure is binding's new value, which you can access by naming it however you'd like TextField("Your Label", $textFieldData.didSet { newText in 																								react(to: newText) } ) Line 2 — That's a function in my View struct. For example, just below var body: some View { ... } func react(to text: String) { // Do something with your latest text } Finally, if you want the TextField to appear at app launch with text from CoreData, you can: (a) initialize the @State var with an initial value (b) add to the TextField().onAppear { myStateVar = getData() } My preferred practice is to initialize the @State variable, the dependency is thus clear up-front. Doing so is simple, but uses some notation to get at the @State object in different ways. Below is an example, but then a warning. struct SomeSubView: View { 		@State var text: String 		init (initialText: String) { 			 _text = State(initialValue: initialText) } Line 4 —— The parent view supplies the data, either an @ObservableObject or text itself. Line 5 —— Instead of the self. notation for setting normal variables, 					underbar points to the Binding variable. It's a cousin to $. Let me know if that doesn't work. The custom variable approach is the same concept, except the Binding definition in the Extension becomes the declaration of your @State variable. I prefer the extension approach because then my code is cleaner: my variable takes a single line up top, is initialized clearly with a dependency, and the TextField specifies it is going to call an action. Warning 1 The code above does not include a debounce mechanism, which means every character typed in will call save in your CoreData database. Yikes! You might find an example, test it, and share it here for others. I decided to use AppKit's text field because it lets me limit the frequency of saves to CoreData, customize the view so it's pretty, and accept rich text editing and pictures. I posted an example implementation today on StackOverflow. - https://stackoverflow.com/a/63144255/11420986 If you're writing for iOS, you can find a UIKit version also on StackOverflow - https://stackoverflow.com/a/58639072/11420986. I can walk you through either. Warning 2 The way you setup CoreData — which follows almost every single tutorial on SwiftUI and CoreData available — violates the MVVM pattern SwiftUI promotes. MVVM is one wise method to create clean code; it requires your View does not directly interact with your Model. The reasoning is this prevents, littered throughout View code, accidental reads or writes to the Model that you wouldn't want, but forgot about with time or that your new team member may not know about until *head*desk* hours later. Also, if you wanted to change the structure of your CoreData model or switch to Google's Firebase to launch your app on Android, you'd have to refactor every view. (Good for Apple?) The fix: Manage all CoreData fetches and saves in one Class, which your View Model accesses to initialize the in-memory data store. In this way, the Google Firebase remodel above would only require switching one class for another. Further, if you create a Protocol for a DataManager, you can have your ViewModel require only a DataManager, which means that as long as your parsed data structure stays the same, you can simply swap out a CoreData DataManager for a Firebase DataManager without changing perhaps anything in your ViewModel or Views! If you want, I can point you to a tutorial or two. For hobbyist or quick mock-up purposes, sure @FetchRequest and ignoring separation of concerns is fast and sweet... but it's not SwiftUI-ish because it violates the fundamental pattern, simplicity, and separation of concern that it was meant to promote. Neglecting separation of concerns will just generate frustration when you make a semi-complex app and take breaks between looking at files. OK, soap box over.