Ooooh, let me try that. Nope, it had been an @State in the ItemView, I changed it to @ObservedObject, and it still doesn't update the view.

This is at the declaration level, not in-function level. Eg., extension View { #if os(macOS) @ViewBuilder func onChange<V>( of value: V, initial: Bool = false, perform action: @escaping (V, V) -> Void ) -> some View where V : Equatable { onChange(of: value) { n in action(value, n) } } #endif }

@workingdogintokyo's suggestion worked. Except the compiler warns that the capture isn't used, even though it is. Yay!

Solved: my LabelWithMenuView takes a String, and the surrounding view doesn't care that the object changed, so I instead changed it to pass in the object, which is then an ObservedObject, and the rename works properly. This is very strange to me, since the rename actually happens in surrounding view.

I tried that, it did not solve the problem. There are, in fact, two: • If the view with the EditButton does not have a parent view that is a NavigationStack (or perhaps types of views), there is no toolbar, and thus there is no edit button. (That is, if ContentView.swift does not contain a NavigationStack, then there is no toolbar.) • If I put a NavigationStack in ContentView, then there is a toolbar and an Edit button, but edit mode is not enabled the first time I click on the Edit button If I add .toolbar { EditButton() } .onChange(of: self.editMode?.wrappedValue) { o, v in print("editMode \(o) -> \(v)") } then when I click on the button the first time, it prints editMode Optional(SwiftUI.EditMode.inactive) -> Optional(SwiftUI.EditMode.active) and... never again prints anything, although edit mode clearly does change.

I filed FB13428947 and attached a simple project.

Ok, I put the .toolbar section on the List, and... it didn't really change behaviour. Then I removed the outer view's NavigationStack and it behaved more strangely -- namely, on the first click, the list items moved very briefly. However, this only seems to happen the first time it's run on the simulator after Xcode installs it. I updated my FB and added two screen recordings.

And if I change the .toolbar code to #if os(iOS) .toolbar { if self.editMode?.wrappedValue == .active { Button("Done") { self.editMode?.wrappedValue = .inactive } } else { Button("Edit") { self.editMode?.wrappedValue = .active } } } #endif when I click on "Edit", the selection buttons appear and immediately disappear.

I don't think we have the .plist file. We use pkgbuild --identifier org.${PRODUCT}.${VERSION} \ --version ${VERSION} \ --scripts "${TARGET_DIRECTORY}/darwin/scripts" \ --root "${TARGET_DIRECTORY}/darwinpkg" \ ${TARGET_DIRECTORY}/package/${PRODUCT}.pkg > /dev/null 2>&1 productbuild --distribution "${TARGET_DIRECTORY}/darwin/Distribution" \ --resources "${TARGET_DIRECTORY}/darwin/Resources" \ --package-path "${TARGET_DIRECTORY}/package" \ "${TARGET_DIRECTORY}/pkg"/$1 > /dev/null 2>&1

That is deprecated. (Sooooooo many of the keychain APIs are deprecated.)

Ok that's how I was trying to explain the situation here, so I'm glad I got it almost exactly right. (Your explanation is less rambly than mine. Also that file-based keychains are probably not going away for quite a while.) Merci! (And for the keychains: we only care about the root certificates, as part of network analyses, so that's why I'm not too worried about it. We may have to worry about a root cert being added to a user's keychain, as opposed to the system one, but I believe we can worry about that later, and that later will mean we'll have code in the user agent to deal with it, so present-me is letting future-me deal with it.)

Finally did that, experimented with trimmed down the .plist file to only have the minimal keys, and voila, Bob's my uncle! Thank you 😄

Ok, this was solved: the MDM profile in question had our VPN under one name, and the WCF under another ("Foo" and "Foo 1"), and this apparently made it not work. I really need to get familiar with MDM deployment, sigh.

Oh that NSNumber was holdover from trying to debug a different thing, I kinda forgot how asynchronous queues work for a bit, ha ha. Using leaks and the command line doesn't find anything particularly horrible either.

No, I meant @synchronized for thread-safety. It's wrapped in an outer @autoreleasepool via main. But ARC should be freeing things. And it is, honestly, but the memory use I see in top or Activity Monitor is different depending on whether I'm running it under Instruments or not. And that's the part that really confuses me.