I've been struggling with drag and drop as a beginner. Why does your snippet above produce a warning Result of call to loadObject(ofClass:completionhandler:) is unused? And why would the result print, but when used to update a variable in view produce an error about immutable self? import SwiftUI struct DragNDrop: View { 		@State var isDropTarget = false 		var displayThisNumber: Int = 0 		var body: some View { 				VStack{ 						Text(String(displayThisNumber)) 						ZStack { 								Image(systemName: "5.circle.fill") 								Circle() 						} 								.font(.system(size: 40)) 								.onDrag { return NSItemProvider(object: String(Int(5)) as NSString) } 						Color.orange 								.opacity(isDropTarget ? 0.5 : 1) 								.onDrop(of: ["public.text"], isTargeted: $isDropTarget) { items in 										for item in items { 												if item.canLoadObject(ofClass: NSString.self) { 														item.loadObject(ofClass: String.self) { str, _ in 																guard str != nil else { return } 																displayThisNumber += Int(str) 														} 												} 												return true 										} 								} 				} 		} }

Bump

Yeah, that and the memory leak from toggles. Worse... if there are functions in a class instantiated somewhere down the chain, the menu commands don't have access to those functions.

Have you figured out a way to go past 10 items besides sub-menus?

Thanks for reminder re: Groups. Yep, that works.

This thread is old... but I've posted a related question: how to pass and return a parameter to the NSView (i.e., right click triggers a SwiftUI popover). My passed binding does not update. https://developer.apple.com/forums/thread/655056

Oh egads that's embarrassing. The class was in the struct, so of course the Binding didn't update.

Until Beta 3, the code above worked well. Now, at the bottom of a scrollview, toggling the sidebar causes a massive memory leak.

What’s your memory graph like? I’m also finding high cpu and memory use. It’s somewhat random, maybe 1 in 8 runs. Switching out the lazy stack didn’t fix it. Have looked at the grid in that app yet. So perhaps the issue is elsewhere?

extension NSTextField { 		open override var focusRingType: NSFocusRingType { 				get { .none } 				set { } 		} } with PlainButtonStyle() you can start a blank slate customization

TextEditor is not as customizable as TextField and does not auto-size itself.

Did you solve this?

To clarify, after following tutorials on how to fix the error, I: removed duplicates in Keychain from expired certs (wasn't a problem four weeks ago, weeks-post expiration) regenerated profiles, then certs and profiles again in the web interface built with cleaned derived data each time removed all certs online and in keychain, restarted the laptop and rebuilt in Xcode's managing signing certificates manually specified signing / provisioning profiles in the app and app extension (that worked in Xcode, failed in Archive/Upload What am I missing?

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.

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.