[Swift] Evict preloaded checkout under memory pressure

[markmur]

Adds memory-pressure handling for the preloaded checkout WebView, plus related hardening surfaced in review.

A preloaded checkout keeps an idle WKWebView resident in memory until its TTL expires. Under memory pressure iOS asks apps to free memory voluntarily; an app that doesn't free enough is jetsam-killed as a whole process. This adds a DispatchSourceMemoryPressure on the shared cache that proactively releases the idle preloaded WebView when the system signals pressure, lowering the host app's jetsam risk.

What's included

• Memory-pressure eviction: routed through a single evict() funnel that only reclaims an idle preload. A presented checkout is tagged via a new isPresented flag (set when the view controller takes ownership, cleared on teardown) and is always skipped, so the handler can never tear down an active session.
• Observable eviction reason: eviction surfaces as PreloadState.evicted(reason:) — .memoryPressure or .webContentProcessTerminated — so consumers can distinguish why the cache was reclaimed.
• Web content process termination: WKWebView renders out-of-process and the system can jettison that process independently. An idle preload whose content process dies is evicted (.webContentProcessTerminated); a presented checkout surfaces an error to the delegate rather than sitting blank.
• invalidate() respects presentation: the public invalidate() no longer detaches the bridge of a presented checkout — it only clears an idle preload.
• No re-warm under pressure: while the system is signalling pressure, preload() declines to warm the cache, so re-warming can't refill a starved system. present() is unaffected and always loads.

Eviction is automatic — consumers observe .evicted to know the cache was reclaimed and can re-warm at the next appropriate opportunity:

checkoutPreload = ShopifyCheckoutKit.preload(checkout: url) { state in
    if case .evicted = state {
        // Cache was reclaimed. Re-warm later, once pressure has cleared —
        // re-warming immediately would fight the reclaim that just happened.
    }
}

Why ship this

• Platform contract: honoring DispatchSourceMemoryPressure and web-content-process termination is the idiomatic iOS behaviour for a reclaimable cache; proactively releasing an idle checkout WebView lowers the host app's jetsam risk under pressure.
• Safe for active sessions: the isPresented guard ensures neither the pressure handler nor invalidate() can tear down a presented checkout.
• Bounded and low-risk: the cache is single-slot and TTL-bounded, so eviction can only ever reclaim one idle preload.
• Parity and lifecycle: aligns with the Android eviction ([Android] Evict preloaded checkout under memory pressure #453) and completes the PreloadState lifecycle from [Swift] Add preload state observability #445, keeping the kits — and the React Native wrapper on top of them — symmetric.

[markmur]

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

• [Android] Evict preloaded checkout under memory pressure #453
• [Swift] Evict preloaded checkout under memory pressure #447 👈 (View in Graphite)
• [Android] Add preload state observability #451 : 1 other dependent PR (#455 )
• main

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

[github-actions]

React Native — Coverage Report

Lines	Statements	Branches	Functions
	91.85% (327/356)	87.98% (183/208)	100% (86/86)

[kieran-osgood-shopify]

"Correctness: without the evict() funnel and isPresented guard, a live checkout could be torn down mid-session under memory pressure. This closes that hole, which is the change's main justification."

Have you been able to reproduce iOS tearing down the preload cache? I believe the premise may be slightly off, though your changes still make sense to respond to the system warning, just want to ensure framing is correct / for anyone else following along

Responding to low memory warnings

Under system pressure, iOS will alert running applications to it with the listener you added, it's then on app developers to free up memory, if they dont free up enough memory then the System will start killing apps to free up enough memory.

Notably the System will kill an entire app, on a process by process basis, not individual memory allocations like the cache entry which would lead to app instability.

xcode/responding-to-low-memory-warnings

---

Valid gap - Missing coverage

The Web Content rendered in the web view (not the cache entry, but the out of process web content) is a unique case as its a separate process and up for collection

We should look at whether we can inform the user that the system tore down the content process (I think this can be acheived with `webViewWebContentProcessDidTerminate``
Then we can explore the UX to recovery

---

On the PR body, I think the example is a bit misleading for any users that might discover the PR, it demonstrates repopulating the cache immediately after an eviction, which would be counter to the eviction we'd want to recommend they use the DispatchSource to listen for a .normal event before preloading again

checkoutPreload = ShopifyCheckoutKit.preload(checkout: url) { state in
    if state == .evicted {
        // freed under memory pressure — re-warm on the next runloop tick,
        // not synchronously from inside this callback
        DispatchQueue.main.async { 
           preloadCheckoutIfNeeded() 
        }
    }
}

---

A few questions

1. Should we consider guarding the preload fn under memory pressure, and always respect .present?

2. this is tangential to your PR, with the introduction of isPresented guarding teardown under memory pressure should invalidate be guarding against isPresented itself? It seems like a gap that we allow invalidating (detaching communication channel) whilst the checkout is presented right? Not sure if this has happened to anyone before, but feels like it'd be an easy thing to shore up now

[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

Checkout Kit E2E results

Status	Suite	Target	Platform	OS version tag	Device
✅	tests/shared/launch-smoke.yaml	swift	ios	latest	iPhone 15 iOS 27 Beta

[markmur]

Thanks Kieran, this was spot on - you're right that the framing was off 👍

I've rewritten the description to lead with the accurate reason (proactively releasing an idle WebView lowers the host app's jetsam risk) and dropped the circular "closes a hole" justification. The isPresented guard is now framed as guarding a risk this handler would otherwise introduce, not a pre-existing one. Also fixed the misleading code example! (Good catch)

On the web content process gap: good catch, this was the real missing coverage. Decided to add webViewWebContentProcessDidTerminate to this PR so that an idle preload whose content process is jettisoned is now evicted, and a presented checkout surfaces an error to the delegate instead of sitting blank.

I stopped short of auto-reloading a presented session on termination - that recovery UX feels like a follow up.

---

One more thing that came out of this: .evicted now carries a reason (.memoryPressure / .webContentProcessTerminated) so consumers can distinguish why the cache was reclaimed.