A support ticket said that “Safari cannot finish checkout.” The first screenshot looked like a normal browser page and the User-Agent contained familiar WebKit and Safari markers. The reproduction changed when the team split the report by container. macOS Safari completed the payment hand-off, iPhone Safari returned to the order page, and the app-embedded WebKit view stopped after the external authentication step. The token was a useful lead, but the container was the actual boundary.

Split the matrix before reading the token

Use separate rows for macOS Safari, iPhone Safari, iPad Safari in desktop mode, and the WebKit view inside the host application. Add the operating-system version, device class, viewport, network condition, and exact feature under test. A row that says only Safari hides the difference between a browser navigation problem and an app hand-off problem.

The distinction is especially important for storage, viewport sizing, media playback, file access, and external links. Two contexts can share an engine marker while applying different policies around the journey that failed. Treat the UA as routing evidence, not as a complete environment description.

A concrete reproduction record

The following is an illustrative record for the checkout case. It captures the comparison that support needs without pretending that a header identifies the device owner.

feature: payment return
contexts: macOS Safari 17 / iPhone Safari 17 / embedded WebKit in host app
step: return from identity provider
macOS: order page restored
iPhone Safari: order page restored after one redirect
embedded WebKit: spinner remains, no return event observed
next test: inspect app hand-off and cookie policy

The next test is more precise than “try another Safari version.” It asks whether the host app receives the callback, whether the cookie is available in that context, and whether the WebView allows the same navigation. The browser family remains useful, but the engineering task now has a clear owner.

Pair identity with capability checks

Use feature detection for the feature being tested. Check whether a file input can open the required picker, whether the media element reports the expected capability, whether the storage operation succeeds, and whether the redirect event fires. A UA token can select the first device to reproduce on; it should not replace the capability check.

For iPad desktop mode, test both the reported desktop-like string and the touch or viewport behaviour. A desktop label does not make the interaction equivalent to a mouse-and-keyboard session. For embedded WebKit, run the flow inside the host application rather than copying the UA into a desktop browser and calling it done.

Make the bug easy to hand off

A good Safari ticket contains the URL or a redacted route, exact steps, expected and observed result, screen recording or screenshot, viewport dimensions, browser context, operating-system version, and the smallest working comparison. Do not ask a customer to paste cookies or private account details into a public community post. If a raw header is needed, redact tokens and store it in the restricted support system.

Support copy should say “this flow fails in the embedded WebKit container” when that is what the evidence shows. “Safari is broken” is shorter but sends QA toward the wrong matrix row and teaches readers to overtrust a label.

Check the return path in isolation

An external identity provider can make a browser report look like a Safari rendering bug. Build a fixture that replaces the provider with a local callback page and sends the same redirect shape. First test the page without authentication, then test the callback, then test the full provider hand-off in a controlled account. If the local callback succeeds but the provider flow fails, inspect cookie scope, redirect policy, and the host container before changing Safari-specific CSS.

For a reproducible record, keep the route name, status code, redirect count, storage result, and visible outcome. A useful example might show one redirect and a restored order page in standalone iPhone Safari, versus two redirects and a missing callback event in embedded WebKit. These values are illustrative; the point is to name the boundary where the journeys diverge.

Do not overfit to one device

Repeat the smallest reproduction on a second iPhone, an iPad, and macOS when the feature is important. Note whether the result follows the operating system, the host app, the account state, or the network. If only one device fails, preserve that fact. A broad “Safari issue” label can send a team into an expensive compatibility project when the real problem is a stale service worker, an account fixture, or an app-specific navigation policy.

Before closing the ticket, rerun the journey after clearing only the relevant site state and then in a fresh test account. This separates a browser policy from a poisoned cookie or cached asset. Keep the result in the reproduction record, because a successful clean run is evidence about state even when it does not explain the original customer case.

Our editorial position is that Safari compatibility work begins at the platform boundary because that is where the user journey changes. The string helps choose the first reproduction; the container, capability result, and failed step explain the bug.