Two of my apps, Sortes and VaultSnap, each ship a regression test that exists to fail if the Google ad SDKs ever come back. Both were green. Both lockfiles still had the packages pinned in them while those tests ran.
The markers were written by a person and the file was written by SwiftPM, and the two do not agree on what the package is called. VaultSnap's test did scan Package.resolved. It looked for GoogleMobileAds, and SwiftPM had written the identity lowercase and hyphenated.
# what the test looked for
"GoogleMobileAds"
# what SwiftPM had written in the file the test was reading
"identity" : "swift-package-manager-google-mobile-ads"
# the red proof, and it was free: the pins were still in the lockfile,
# so the fixed guard was run BEFORE clearing them
xcodebuild test -only-testing:SortesTests/AdRetirementRegressionTests
# failed on both markers, naming Package.resolved
# pins cleared -> 85 XCTest + 27 Swift Testing, 0 failures| Item | VaultSnap | Sortes |
|---|---|---|
| What was wrong | Scanned the lockfile with markers that could not match it | Never scanned the lockfile at all |
| What it needed | The lowercase markers | The path as well as the markers |
| Given the marker-only patch | Actually fixed | Looks fixed in the diff, still checks nothing |
The check that would have caught it
Has anyone watched this assertion go red? A guard that reads the right file and reports the opposite of its contents is worse than no guard, because it gets cited as evidence. The cheapest red is the one already sitting there: run the fixed check against the mess before you clean it up.
The thing the guard protects
Twelve apps, no ads, no ad SDK
The guards in this issue exist because the whole portfolio is ad-free and stays that way. No ad or tracking SDK is linked in any of the twelve, and no shipped binary was affected by the defect above. What was broken was the proof, not the product.
See the apps