A global object in a global variable is a design pattern known as a “Singleton” and Singletons have some well known drawbacks.

They introduce global state to the application and they tightly couple the classes that access them.

Another disadvantage of using singletons is that they make unit testing very hard and, for that matter, they make reuse difficult as well. When any internal method can reach out and snag a global object unknown to the caller then its going to be very hard to test the parent object or pull it out to reuse elsewhere.

EnvironmentObjects, on the other hand, have to be defined up front in the View struct and make it readily apparent that view V is dependent upon service S or model M.

Further, while they may appear “global”, EnvironmentObjects only affect views further down the view chain. This means, for example, that a payment system could create a payment model that’s used by the payment system, but that model isn’t a global that’s visible to the rest of the application.

Globals are insidious things best used sparingly, and only in times of great need… ;)