The percentage comes out of the comparator, not out of the design. diff_report.py compares PNGs with Pillow, draws boxes around the pixels that differ, and writes an HTML report plus summary.json [12]. Nothing on that path can separate an intended edit from a consequence of one. Padding on the badge changed its footprint, the rows below it moved, and the comparator counted all of it [2][3].
That is what makes a diff threshold unportable between projects. For a percentage measured on one codebase to mean the same thing on another, edits would have to stay inside their own region, the fixtures would have to be fixed, and the baseline would have to have been accepted under the same rendering conditions [4][8]. Reordering subscription rows violates the first of those by definition, so the number moves with the layout's coupling rather than with the count of mistakes.
The assertion is narrow by construction: given specified inputs and rendering conditions, how does the current static appearance differ from the appearance previously accepted [8]. According to the dev.to walkthrough it does not show that a purchase succeeds, that a button responds, or that a price description is correct, and an unchanged screenshot can sit on top of broken business logic [9]. A screenshot suite is the wrong instrument for asking whether the purchase went through, and it will answer anyway.
The constraint that shapes the whole design is that simctl offers no state control. capture.py launches the app with arguments such as -VRScreen paywall, -VRLang ja and -VRStyle dark [15], and those are application-defined: simctl forwards them and never reads -VRLang as a localization instruction [16]. So the harness owns the sequence end to end, in this order: parse the request, prepare fixed data, select the language, synchronize the theme, construct the controller, display the window [17]. Select the language after the labels exist and the screen renders with old text [18]. It renders that way every run, which is the part that matters, because run.sh's baseline step will accept it as the reference [13].
Coverage identity follows from the same problem. The case ran four languages, two appearance modes and four screens for 32 screenshot states [5]; divide by the four screens and each screen name stands for eight distinct renderings [7]. That is why the author treats language and appearance as part of a state's identity rather than metadata [6].
The toolchain bill is modest: no extra Swift testing library inside the app, and Xcode with simulator support, Python and Pillow on the capture host [19]. The per-project bill is the harness, the screen builders, the language and theme wiring, and the fixed test data [20]. Point-Free's swift-snapshot-testing already covers view controllers, device configurations and trait collections [23]; the choice here was an in-app entry point driven by an external script [24]. The author's own limit on the work, useful locally but not yet an unattended gate [21], is the honest read of the evidence, and the missing checks are legible from the mechanism: verify that the requested language and appearance were actually applied before the shutter fires.
