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.

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 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.)

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

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

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.

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.

I filed FB13428947 and attached a simple project.

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.

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.

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

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 }

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.

Oh, no, it's weirder -- command-B defines it, but command-R's build does not. Weird, but ok I guess.

In retrospect possibly obvious: the Firebase id is optional, so I added a slight layer of abstraction and use a type that has a non-optional id element. (I'd already had this type for other reasons, so it was a minor refactor.) With that done, it worked as expected. Including not crashing, which is always a nice benefit!