Thank you for the suggestion. I tested capturing the entire UIWindow using drawHierarchy(in:afterScreenUpdates: true) into a full-window bitmap, then cropping the tab bar region. Unfortunately, this did not improve the result compared with drawing the same window into a smaller bitmap covering that region. The attached system screenshots show the difference on physical devices: Left: iPhone 15 Pro Max, iOS 27.2 Right: iPad mini (6th generation), iPadOS 27.2 Within each screenshot, the top tab bar is the captured image displayed in WKWebView, and the bottom is the live UIKit tab bar, shown at the same size. The differences are particularly visible in the refraction and blending of the background stripes, as well as the edge highlights. On the iPhone, I also displayed the captured image directly in a native UIImageView, before PNG encoding or WebView rendering. The appearance difference was already present at that stage. Is there an additional capture configuration or hierarchy requirement I may be missing, even when drawing the entire window? I would appreciate any guidance on preserving these effects through a supported application-level capture API, without requiring a screen-recording session.

@Frameworks Engineer Thank you for clarifying both the rendering security restriction and the return-value behavior. That explains the difference we observed between physical devices and Simulator. The reason we explored snapshot views is that capturing the original view directly with drawHierarchy(in:afterScreenUpdates:) also loses part of the on-screen appearance: the reflective highlights around the edges of Liquid Glass controls are missing from the resulting image on a physical iPhone. Is there a supported public API or capture approach that preserves those highlights when rendering the original view into a UIImage, without starting a screen-recording session? Or are those effects composed at a stage that application-level image capture cannot access?

Additional physical-device verification (October 27, 2026) The snapshot-replica bitmap readback issue also reproduces in these configurations: iPhone 15 Pro Max (iPhone16,2), iOS 27.2 (24B119). This is the SAME physical iPhone previously tested on iOS 27.0.1 (24A446), now updated to 27.2. iPad mini (6th generation, iPad14,1), iPadOS 26.6.1 (23G83). Both configurations were tested with the same standalone public-API App.swift used in the original report, built in Release and launched normally without a debugger or XCTest. Two independent launches on each configuration produced identical measurement results within that configuration. Results on both configurations: The original 240 x 160 UIView renders correctly: all 38,400 pixels are nontransparent. Its snapshot replica produces zero nontransparent pixels on a transparent target; all 38,400 pixels remain cyan on a cyan-prefilled target. UIWindow and UIScreen replicas also omit their cached contents. A normal 30 x 30 red child added to a replica does render (899 red pixels). drawHierarchy returns true even when the cached contents are missing. Pixel counts are measured before PNG encoding. On the same iPhone, replica measurements on 27.2 match those on 27.0.1. The original UIView positive control remains fully rendered; its red-pixel count changes by four pixels (37,952 to 37,948). The omission therefore persists after updating the same iPhone to 27.2, and also occurs on a physical iPad running the 26 series. A physical iPhone on the 26 series is unavailable. These tests concern snapshot-replica bitmap readback, not a new measurement of Liquid Glass appearance or alternative capture APIs. Measurement summaries are attached below. Full two-run PNG/JSON evidence for both devices has also been added to FB25336445.