Exercise 2: Why the StoreKit Sandbox Pass Must Come Before a Live Purchase Test — Possible Solution
=========================================================================================================

Chapter 8 established that a real live in-app purchase test carries
genuine external overhead and risk: it requires the product to already
exist and be approved in App Store Connect, a real sandbox Apple ID
signed in on the device, and every real purchase routes through
Apple's own live App Store infrastructure - meaning a failed test could
reflect a genuine bug in TaskFlow's own purchase-handling code, or it
could just as easily reflect an unrelated, transient problem with
Apple's own live systems, with no reliable way to tell the two apart.

The chapter's own local StoreKit Testing sandbox removes every one of
those real external dependencies: it runs entirely on the simulator,
against a StoreKit Configuration file defined directly in the Xcode
project, with no live network dependency and no real money involved.
Running the Pro tier's own purchase flow - the real
.success/.userCancelled/.pending switch statement - through this local
sandbox first means every one of those three real outcomes can be
triggered deliberately and repeatedly, with any failure attributable
with confidence to TaskFlow's own code rather than to Apple's live
systems.

Only once that local pass genuinely confirms the purchase-handling
code itself is correct does it make sense to test against a real live
purchase - at that point, a live-purchase test is verifying the
remaining real, external pieces (the actual App Store Connect product
configuration, real payment processing) rather than trying to diagnose
a code bug and an infrastructure problem at the same time.

ANSWER: The local StoreKit Testing sandbox has to come first because it
lets every purchase outcome be tested reliably and repeatedly with no
external dependency, so any failure can be confidently attributed to
TaskFlow's own code - testing against a real live purchase first would
make it impossible to tell whether a failure came from a genuine code
bug or an unrelated problem with Apple's own live systems.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the real diagnostic clarity the sandbox provides
(isolating code bugs from external system issues) as the concrete
reason for the ordering, rather than simply restating that the sandbox
should be used first.