When NOT to Use `@EnvironmentObject` in SwiftUI

@EnvironmentObject is a SwiftUI property wrapper for accessing shared data that conforms to ObservableObject. It injects an object into the environment, allowing descendant views to access it without explicit passing. Changes to published properties in the object trigger re-renders in observing views. However, a crucial drawback is that if the object isn't found in the environment, the app will crash at runtime. This often happens with reusable components or when testing views in isolation. @EnvironmentObject is not suitable when a dependency is only needed by a few views, as explicit parameters make dependencies clear. For reusable components, prefer explicit dependencies via initializers or closures to maintain portability and testability. Testing views becomes significantly easier with explicit dependencies, avoiding the need to set up the entire environment for each test. Conditional dependencies are also awkward with @EnvironmentObject, as it assumes the object always exists. Passing data into NavigationLink destinations using @EnvironmentObject can lead to subtle runtime crashes and tight coupling with the DI strategy. Fine-grained observation is also a concern, as any published property change re-evaluates all observing views. Previews also become cumbersome due to the repeated need to inject environment objects. Alternatives include explicit initializer parameters, closures for actions, @StateObject for owned state, @Observable for more efficient observation, and custom EnvironmentKeys with default values. @EnvironmentObject remains useful for truly app-wide concerns like authentication or theme settings, but careful consideration of its trade-offs is essential.