Is your issue the same as the one that's called out in the Xcode 12 release notes - https://developer.apple.com/documentation/xcode-release-notes/xcode-12-beta-release-notes? Rebuilding against the iOS 14, macOS 11, watchOS 7, and tvOS 14 SDKs changes uses of GeometryReader to reliably top-leading align the views inside the GeometryReader. This was the previous behavior, except when it wasn’t possible to detect a single static view inside the GeometryReader. (59722992) (FB7597816)

Question #2: Why does the Xcode report the type of an async let as the type of value after an await instead of some metaphysical type representing the presence of "awaitable" context? Why isn't the type of async let displayed as Task<UIImage>? Why didn't the language go the ECMAScript path where an async function is supposed to return a Promise that can be both subscribed to and awaited? Not exposing async let child tasks in the type system was a deliberate decision to maintain the structured concurrency invariants, i.e. that child tasks are not allowed to escape their scope. The Swift Evolution proposal for async let has some background: Alternatives considered Explicit futures As discussed in the structured concurrency proposal, we choose not to expose futures or Tasks for child tasks in task groups, because doing so either can undermine the hierarchy of tasks, by escaping from their parent task group and being awaited on indefinitely later, or would result in there being two kinds of future, one of which dynamically asserts that it's only used within the task's scope. async let allows for future-like data flow from child tasks to parent, without the need for general-purpose futures to be exposed. If you need an explicit task handle, you must create an unstructured task with Task { … } or a detached task with Task.detached { … } (in Xcode 13 beta 1 these are named async { … } and detach { … }, respectively). These return a Task.Handle value, which is like a future.