I updated the code so it actually compiles. Your original example shows the children using the environmentObject, but new shows setting it. The following code works as expected on iOS 17/Xcode 15 class DataStore: ObservableObject { static let shared = DataStore() @Published var name: String = "" } struct DataStoreView: View { @StateObject var dataStore = DataStore.shared @State private var isShowingView1 = false var body: some View { NavigationView { VStack{ Text(dataStore.name) NavigationLink(destination: View1(), isActive: $isShowingView1) { } Button(action: { isShowingView1 = true }) { Text("Go to View1") } } } .environmentObject(dataStore) // added this here } } struct View1: View { @EnvironmentObject var dataStore: DataStore @State private var isShowingView2 = false var body: some View { ScrollView{ VStack(alignment: .center) { Text(dataStore.name) NavigationLink(destination: View2(), isActive: $isShowingView2) { } Button(action: { isShowingView2 = true }){ Text("Go to View2") } } } } } struct View2: View { @EnvironmentObject var dataStore: DataStore var body: some View { ScrollView{ VStack(alignment: .center) { Text(dataStore.name) Button(action: { dataStore.name = "updated value" }){ Text("Update data") } // When updating this environmentObject the viewstack will be pushed back to View1. If view2 had been navigated to view3 and the view3 had been updating the environmentObject, then it would also be pushed back to View1. } } } }

Yes, but why??? I'd actually like to know a sound technical reason why Xcode 14.3.1 should not be able to run under Sonoma. Many developers work at places where a specific version of Xcode is required for development and release pipelines and this "historical" practice prevents them from moving forward to new versions of macOS. Or is Apple signaling that this is a "best practice" and that we too should cripple our older applications such that a new version is required whenever a user upgrades their OS?

We need something, especially since the new @Observable macro throws these non-initialized errors and breaks quite a few property wrappers in the process, including the @Injected property wrapper types used in Factory and other dependency injection systems. @Observable class SplashScreenViewModel { @Injected(\.loginService) private var loginService: LoginServices ... } In Factory, the keypath initializer points to a DI container/factory that will provide the requested service. An initialized variable isn't needed (or even possible). The @Observable macro basically breaks any property wrapper like this one whose job it is to pull a keyed value from a container, database, or other backing store. You can "fix" the problem with @ObservationIgnored, but that needs to be done every single time a property wrapper is used, which in turn greatly discourages their use. @Observable class SplashScreenViewModel { @ObservationIgnored @Injected(\.loginService) private var loginService: LoginServices ... } It would be better if, as mentioned in this proposal, there was a away to mark the property wrapper itself as fulfilling any needed requirements.

I see. I should change the name of a library known and used by thousands of people, and/or rename the service within that library breaking hundreds of apps... all to fix a bug in DocC. Seriously guys, "Don't do that" is NOT an acceptable answer.

ColGrenfell is correct. Had same problem. Moving property from a published property on the view model to a state variable on the view fixed the issue.

So, I have the same exact issue when attempting to build to a device.--process launch failed: failed to get the task for process 2834Domain: IDEDebugSessionErrorDomainCode: 3--App will build and attach to simulator, but will not build and attach to device.I can do Edit Scheme -> Run -> Debug executable == falseAnd it will then build to a device, but w/o debugger support.Executable == true gives the above error.sudo DevToolsSecurity -enable does nothing either way. Should note that this is app secific. If I run up a new demo app it will build to the device just fine.