Exercise 3: Why the Local Sandbox Beats Testing Against a Live In-App Purchase — Possible Solution
========================================================================================================

Testing directly against a live App Store Connect in-app purchase
requires real, prerequisite setup that has nothing to do with the
actual code being tested: the product must already be created and
approved in App Store Connect, a real sandbox Apple ID test account
has to be signed in on the device, and every real purchase still
routes through Apple's own live App Store infrastructure - meaning
network availability and Apple's own service state can affect whether
a test purchase even succeeds, entirely independent of whether the
app's own purchase-handling code is correct.

StoreKit Testing in Xcode removes all of that real overhead. A
StoreKit Configuration file defines test products directly inside the
Xcode project itself, with no real App Store Connect record needed at
all, and purchases run entirely on the simulator with no real network
dependency, no sandbox Apple ID sign-in required, and no real money or
live App Store systems involved anywhere in the process.

This genuinely matters for iteration speed and reliability during
development specifically: a developer testing the .success/
.userCancelled/.pending switch statement from this chapter can trigger
each real outcome directly and repeatedly, on demand, without waiting
on Apple's own live systems or worrying about whether a failed test
purchase reflects a real bug in the app's own code versus a transient
problem with the sandbox environment itself.

ANSWER: The local StoreKit Testing sandbox removes every real
dependency a live in-app purchase test carries - no App Store Connect
product setup, no sandbox Apple ID, no live network or Apple service
involved - letting a developer test every purchase outcome (success,
cancellation, pending) repeatedly and reliably on the simulator, with
any failure clearly attributable to the app's own code rather than an
external system.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the specific, real overhead and reliability risk of
testing against a live purchase (external setup, network dependency,
ambiguous failure causes) and explains concretely why removing all of
it genuinely speeds up and clarifies development testing.