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.

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.

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.

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?

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

"The problem with this though, I like to reuse ProductDetailView also in my other NavigationStack..." You might check out the following article on building navigation destinations that allow for reuse. https://michaellong.medium.com/advanced-navigation-destinations-in-swiftui-05c3e659f64f?sk=030440d95749f5adc6d2b43ca26baee1 As for allowing subviews to access the NavigationPath, typically you want to shield the path from the subviews by providing some object that manages it. In Navigator I pass an object down through the environment as an environment value (not environment object). You might look at the project for ideas. https://github.com/hmlongco/Navigator

"is pass down the NavigationPath as Binding" I might pass a closure downstream, but by and large I believe that your child views should be ignorant as possible of the navigation mechanism being used. Exposing the path goes against that somewhat... ;)

One could argue about whether or not @Sendable or @ObservationIgnored act as compiler attributes (yes, I know ignored is a macro), but @Concurrent makes as much sense as @concurrent. Actually, @Concurrent is more in line with @MainActor, and @GlobalExecutor would at least be congruent. And what the hell is @globalActor ??? ;) Like I said, they seem all over the place.