I don't know if this is a bug or what, but here is something that works. Add a level of indirection. Example: struct MyApp: App { @StateObject var appModel: AppModel = .init() ...     var body: some Scene {       WindowGroup { ... }.commands { CommandGroup(after: CommandGroupPlacement.toolbar) {     ItemsThatUpdate().environmentObject(appModel) } } ... struct ItemsThatUpdate: View {     @EnvironmentObject var appModel: AppModel     var body: some View {         Group {             Button(action: toggleFoo) { // Now this text will update as desired when model changes                 Text(verbatim: "Toggle Foo - \(appModel.foo)")             }             Button ... Button ...         }     }     private func toggleFoo() {         appModel.foo.toggle()     } }

I'm seeing a similar problem. I'm trying to change the CommandGroup Buttons based to some state in an ObservableObject, and it's not happening. Did you ever figure this out? As you said, uses include: Showing a checkmark for boolean states, like "✓ Foo enabled" Items that show or hide parts of view. Eg, "Show Sidebar" ↔︎ "Hide Sidebar" Enabling or disabling items

I reported a bug. FB9049107.

Okay, good to know. If I go from light to dark, I get text that while not invisible, is still colored wrong (not enough contrast).

Hi "workingdogintokyo", Thanks for taking the time to do that. I'm running the newest non-beta stuff: macOS 11.2.1 and Xcode 12.4. So maybe that's the difference, and they've fixed it in the new versions. One other thing I didn't mention: I checked "SwiftUI App" when creating my test project, not "AppKit App Delegate". Other than that I changed nothing, besides the ContentView code I posted. I may also try a system restart. My MacBook's current "uptime" is 36 days.

JoshATA, It appears that the HSplitView is causing it. If you run the following, and change light to dark or vice versa in System Preferences, you see the "Test" button behave badly. struct ContentView: View {     var body: some View {         HSplitView {                        VStack {                 Text("Does this button change color correctly?")                 Button("Test") {                     print("Hi.")                 }             }         }         .frame(maxWidth: .infinity, maxHeight: .infinity)     } }

How do you control the wifi/network state from a UITest? This thread suggests it's possible, but I'm looking at the API of XCUIDevice and XCUIApplication and I don't see anything. What I want to do: I want to test the code in my app that displays in-app purchase prices. Specifically, this scenario: Device has no internet connection. App starts up and tries to get in-app product info and fails. Device connects to internet. App detects this change, re-requests in-app product info, succeeds, and displays the prices. So I need a way to turn the wifi and cellular networking off and on from within the UITest. Is it possible?

Yeah, but then that doesn't explain why they changed it from objectDidChange to objectWillChange. The former would also work perfectly fine if it was merely a way to say "update on next cycle".

At first I was able to simply hit the continue button in the debugger, to run my app. Now it's stopping in a different place, and when I hit continue the app never shows up. The stack frame it stops in is now dyld\`ImageLoader::trieWalk.

I filed a Feedback about it: FB8782243.

Oh wait, I’d be remiss if I didn’t mention a new, and completely different, mechanism for mandatory access control, namely the EndpointSecurity subsystem. A good introduction to this is WWDC 2020 Session 10159 Build an Endpoint Security app. I just watched the talk. Awesome! That may actually do it, thank you. I've been in the app dev world, so this stuff is new to me. I'll study more of this and the other topics he mentioned (system extensions, network extensions). It looks like there are some open source projects using it (Google Santa, Sinter).

Thank you both, for the info and clarification. macOS’s sandbox facilities would be a good match for this but they aren’t supported for third-party development. [...] requires you to craft a bunch of code in the sandbox specification language (a Scheme derivative) and that language is not documented for third-party use.  This, btw, is why sandbox-exec has been deprecated. There’s not much use running a program within a sandbox if there’s no supported way to specify the details of that sandbox. Dang. It would be super useful and give some peace of mind to people who need to run all this semi-trusted software. I also recently upgraded my hardware, but I "only" have 16GB. Apple wouldn't need to support or document the Scheme-based config language, if we had access to the system calls underneath it people could make their own tools. Maybe something like BSD jail. I guess whatever system calls are used to implement sandbox-exec are also private/hidden. 😞

A better idea is to just install a virtual machine and run these things inside that. You can restrict how much access the VM guest has to the host. Do any of these VM products let me run another macOS while not doubling my RAM requirements? In other words can I tell them to share the parts of the system. Is this what Docker does? I've not yet used it, but it sounds like maybe I want a "container" rather than a full separate VM. ?

Any news on this? Code like the following doesn't seem to work for me. (Xcode 12.2 beta, Big Sur beta). 		var body: some Scene {         WindowGroup {             ContentView().environmentObject(appState)         }         WindowGroup("File List") {             if appState.showFileList {                 FileListView().environmentObject(appState)             }         }     }

One case is when you need to pass that object down to other subviews in your hierarchy. For example: struct TopView: View { 		@StateObject var foo: Foo = ... 		var body: some View { 				VStack { 						... 						SomeSubView(foo: foo) 				} 		} } struct SomeSubView: View { 		@ObservedObject var foo: Foo = ... 		var body: some View { ... } }		 Another situation: an @ObservedObject or @StateObject could have a property that is another ObservableObject. You could pass that to Views as well. In that case, since you are controlling the instantiation of the model object, I think you would use @ObservedObject, not @StateObject.