Exercise 3: Why "Convention, Not Mandate" Matters Before Adopting MVVM — Possible Solution
=================================================================================================

If MVVM were genuinely enforced by the compiler or by SwiftUI itself -
the way, for instance, Swift's real type system enforces that a View's
body must return a single conforming value (Fundamentals Chapter 5) -
there would be no real judgment involved in applying it: either code
follows the pattern correctly and compiles, or it doesn't and fails to
build. There would be one real right answer, discoverable by simply
trying to compile the code.

Because MVVM is genuinely a community convention rather than a
framework-enforced rule, applying it well requires real, ongoing human
judgment rather than following a fixed, mechanically-checked
structure. A small SwiftUI view showing one static piece of data
doesn't need a dedicated ViewModel at all - forcing every single View
in an app through a full Model/View/ViewModel split regardless of its
own real complexity would add genuine, unnecessary boilerplate for no
real benefit, exactly the kind of premature abstraction this site's
own Software Development Subject (Clean Code, SOLID & Refactoring)
warns against elsewhere. Knowing MVVM isn't compiler-enforced is what
makes it clear this is a real design choice to weigh case by case,
not a rule to blindly apply everywhere out of a mistaken belief that
skipping it would be "wrong" in some checkable sense.

There's a second, related real consequence: because nothing in
Swift or SwiftUI itself validates "did I actually follow MVVM
correctly," a codebase can drift into calling something MVVM while
its ViewModels quietly accumulate real UI-specific code, or its Views
quietly accumulate real business logic, with no compiler warning ever
flagging the drift. Recognizing MVVM as a human convention rather than
an enforced one is what makes it clear that maintaining the separation
over time is an ongoing, deliberate discipline - not something that,
once set up correctly, simply stays correct on its own.

ANSWER: Because MVVM is a community convention rather than something
Swift or SwiftUI itself enforces, applying it well requires real,
ongoing human judgment - deciding when a screen is genuinely complex
enough to warrant a dedicated ViewModel, and actively maintaining the
Model/View/ViewModel separation over time, since nothing in the
compiler will ever flag a codebase that has quietly drifted away from
it. Treating MVVM as an enforced rule rather than a deliberate choice
risks both unnecessary boilerplate on simple screens and an
undetected, gradual erosion of the pattern on complex ones.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the real practical consequence of MVVM's own
unenforced, conventional status - the need for ongoing human judgment
and discipline, rather than a one-time mechanically-verified setup.