[E2E] Prove ready preload cache hits on both native samples

[kyle-schellen]

What changed

Proves that presentation actually reused the preloaded WebView, and exposes that proof to Maestro on both native samples.

• Swift SDK: emit a debug-only diagnostic through the configured Logger when presentation selects a matching cached WebView that reached .ready. The existing OSLog message is preserved for dashboard compatibility.
• Swift sample: observe that diagnostic as it is written and republish it as an invisible preload-cache-hit-* identifier. Normal launches hide the diagnostic marker from the accessibility tree; [E2E] Prepare native preload ready-flow validation #631 enables preload observability only for diagnostic runs.
• Android SDK/sample: keep the existing cache-hit log behavior, pin its exact internal diagnostic in an SDK test, read the app's own Logcat, and republish the same identifier only when the latest observed preload state is Ready. The debug-only watcher owns and closes its reader/process with the CartViewModel.
• Tests cover ready hits, still-loading entries, non-debug logging, fresh presentation, URL mismatch, exact diagnostic strings, Android Ready gating, Logcat failures, and reader/process shutdown.

Why

preload-state-ready proves background preload completed. It does not prove presentation used that cached WebView — a fresh one looks identical on screen. This closes that gap.

The .ready condition matters: a cached entry that matches but is still loading would otherwise count as a hit.

Both samples end up exposing the same identifier, so the E2E flow has no platform branch. Getting there differs only because the SDKs differ:

	How the sample sees the cache hit
Swift	Installs a Logger, so it observes the message directly
Kotlin	SDK log sink is internal, so it reads its own Logcat — Android scopes that to the calling UID, so it needs no permission and sees only itself

Each sample matches the message text against its own copy because the SDK diagnostics are not public API. SDK emission tests and sample parser tests pin the exact literals, so accidental drift fails close to the change instead of surfacing as a 30-second E2E timeout.

Testing

• dev swift test CheckoutWebViewTests
• dev swift test sample
• dev android test demo, dev android check detekt
• dev swift lint
• dev android e2e --tags preload
• dev swift e2e --tags preload
• Asserted end to end by [E2E] Prepare native preload ready-flow validation #631 on both platforms: preload ready → present → real checkout content → close → preload-cache-hit-observed, with preload-cache-hit-none asserted beforehand so a stuck marker cannot pass.

Stack

1. [E2E] Expose native preload state markers #626 — preload state markers in the samples
2. [E2E] Prove ready preload cache hits on both native samples #627 — this PR: proof that the ready cache entry was reused
3. [E2E] Prepare native preload ready-flow validation #631 — the E2E test and matrix wiring

---

Before you merge

Important

• I've added tests to support my implementation
• I have read and agree with the Contribution Guidelines
• I have read and agree with the Code of Conduct
• I've updated the relevant platform README (platforms/swift/README.md and/or platforms/android/README.md)

---

Releasing a new Swift version?

• I have bumped the version in ShopifyCheckoutKit.podspec
• I have bumped the version in platforms/swift/Sources/ShopifyCheckoutKit/ShopifyCheckoutKit.swift
• I have updated the SwiftPM/CocoaPods version snippets in platforms/swift/README.md (major version only)

Releasing a new Embedded Checkout Protocol version?

• I have bumped embeddedCheckoutProtocolAndroid in platforms/android/gradle/libs.versions.toml
• I have updated protocol/languages/kotlin/embedded-checkout-protocol/api/embedded-checkout-protocol.api if the public API changed

Releasing a new Android version?

• I have bumped checkoutKitAndroid in platforms/android/gradle/libs.versions.toml
• I have updated the Gradle/Maven version snippets in platforms/android/README.md

Tip

See the Contributing documentation for the full release process per platform.

[kyle-schellen]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• [E2E] Prepare native preload ready-flow validation #631
• [E2E] Prove ready preload cache hits on both native samples #627 👈 (View in Graphite)
• [E2E] Expose native preload state markers #626
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[bitrise]

Install this build

Open Tophat, select your target device, then click Install. Links open on the Mac running Tophat.

SDK	Install
Swift	Install with Tophat
Kotlin	Install with Tophat

Checkout Kit E2E results

Status	Suite	Target	Platform	OS version tag	Device
✅	kotlin-android	kotlin	android	latest	Google Pixel 9 Android 17.0
✅	swift-ios	swift	ios	latest	iPhone 15 iOS 27 Beta

[kieran-osgood-shopify]

Dropping it here based on our slack convo
We're going to explore an approach using the log screen as this avoids us having to add conditional logs entries to the SDK

[github-actions]

Package Size

Platform	Artifact	Base	Head	Delta
Android	release AAR	279.8 KiB	280.0 KiB	+160 B

Android file breakdown

File	Base	Head	Delta
classes.jar	295.6 KiB	295.7 KiB	+152 B
res/layout/checkout_view_content.xml	2.6 KiB	2.6 KiB	0 B
res/layout/checkout_sheet_content.xml	2.0 KiB	2.0 KiB	0 B
res/values/values.xml	1.3 KiB	1.3 KiB	0 B
R.txt	1.2 KiB	1.2 KiB	0 B
AndroidManifest.xml	922 B	922 B	0 B
proguard.txt	798 B	798 B	0 B
res/drawable/close.xml	431 B	431 B	0 B
res/menu/checkout_menu.xml	354 B	354 B	0 B
META-INF/com/android/build/gradle/aar-metadata.properties	157 B	157 B	0 B

Measured from the PR base SHA and PR head SHA. The file breakdown shows uncompressed sizes within each package artifact, so individual files do not sum to the compressed artifact total. This comment reports package artifact sizes only; it is not a final app binary-size report.