Not sure if this is the same issue, but we noticed this behavior when app was going from foreground->background->foreground and making Metal calls. When an iOS app goes to the background or a system sheet (Share, Photo picker, etc.) appears, Unity can still tick managed code long enough to issue draw calls. Metal treats that as “rendering while not in the foreground,” which can trigger validation errors or crashes. Our pattern is to pause Unity’s rendering whenever the app loses foreground or a system UI sheet is shown, and resume once it returns. Concretely: subscribe to iOS lifecycle events (pause/focus changes) plus the system-sheet presentation callbacks, call Application.pauseStateChanged/OnApplicationFocus/native hooks to detect those transitions, then gate or pause the render loop until we’re truly foreground again. That keeps Metal from receiving draw calls in invalid states and stabilizes app state transitions.
I assumed this was an iOS 26 thing, but looks like you're seeing it on older versions of iOS as well.

I'm on 6000.0.62f1 and I haven't really noticed it happening on that version. I was the one who originally reported ts bug

any workarounds for this issue?

This never should have been an issue in the first place, what even prompted them to change the splash screen code?

When can we expect a fix?

Also happens on Unity 6000.0.58f2

upd: 1) scene loading from asset bundle

Have similar issue: during runtime after some steps bug can be reproduced.
important note: repro with these steps isn't 100%
1) scene loading from addressable. after changing device orientation (landscape to portrait or portrait to landscape) -> screen blinking
2) app session interrupted by telephone call, runs in background for a while, after call end -> screen blinking
3) accidentally making double screenshot