Exercise 3: Why App and View Being Protocols (Not Base Classes) Is a Meaningful Design Choice — Possible Solution
=======================================================================================================================

Many older, class-based UI frameworks (including Apple's own earlier
UIKit, and object-oriented UI frameworks in other ecosystems generally)
require a screen or app entry point to be built by INHERITING from a
specific base class, gaining that class's own default behavior and
overriding only the pieces that need to differ. Inheritance like that
comes with real, well-known costs: a type can only inherit from one
base class at a time in Swift, and inheriting pulls in the base
class's own full implementation, whether every piece of it is actually
wanted or not.

App and View being real Swift PROTOCOLS instead means a type
CONFORMS TO them by satisfying a small, explicit contract - in both
cases, providing a computed body property of the required associated
type - rather than inheriting a full implementation from anywhere. A
struct that conforms to View isn't secretly built on some hidden
shared base class carrying default behavior along with it; it's a
plain, independent Swift struct that simply promises "I can supply a
body," and that's the entire real contract.

This has real, practical consequences that follow directly from being a
protocol rather than a base class:

1. SwiftUI's own views can be lightweight, immutable value types
   (structs), not the more expensive, mutable reference types
   (classes) that class-based inheritance usually requires -
   genuinely cheaper for SwiftUI to create and recreate as the UI
   updates.

2. A single custom type can conform to MULTIPLE protocols at once
   (View plus others), something Swift's single-inheritance rule
   would rule out if View were a base class instead.

3. Conforming to View doesn't drag along any unwanted default
   behavior or hidden internal state - only the exact, explicit
   contract the protocol actually defines.

ANSWER: App and View being protocols, not base classes, means a type
satisfies them by conforming to a small, explicit contract (supplying
a body property) rather than by inheriting a full implementation from
a shared base class. This lets SwiftUI's own views be lightweight,
independent structs rather than requiring more expensive class-based
inheritance, allows a single type to conform to multiple protocols at
once (which single inheritance would rule out), and avoids pulling in
any unwanted default behavior a base class might otherwise carry.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the real structural difference between protocol
conformance and class inheritance, and connects that difference to
concrete, real consequences (lightweight struct-based views, multiple
conformance, no inherited unwanted behavior) rather than treating the
protocol-vs-class choice as merely a naming convention.