I contribute to Flutter, which renders its whole UI into one CAMetalLayer instead of composing UIKit views. The automatic fold adaptation UIKit components get never reaches its dialogs and sheets, so the engine has to read the geometry itself and hand it to the framework, which is what positions them away from the fold. Reading it works. UIView.reservedRegions(kind:options:) returns the fold division and the camera region, and UIHingeInteraction reports the angle. On the iOS 27.1 simulator the inner display is 951×669 pt with a 40 pt division, and hinge.angle runs from 0 shut to π open. Three things I can't answer from the API surface. How does an app learn that a reserved region changed? The hinge interaction covers the fold, but the inner display's front camera region can become active or inactive for reasons that have nothing to do with the hinge, and re-reading in layoutSubviews only catches that if something else happens to trigger layout. Is there a notification or a delegate callback for a region change, or is a layout pass the intended trigger? Is the ordering between the hinge status and a region's isActive defined? isActive seems to lag the hinge: in the update that reports the device fully open, the fold division can still read active. A client that trusts both in the same frame ends up reporting a division that is no longer there. Is there a point where the two are guaranteed to agree? Is the frame of an inactive region meaningful? It keeps its 40 pt frame while flat in my measurements, which would let an app lay out ahead of a fold instead of reflowing when it happens. Is that guaranteed, or incidental? For context, this feeds a proposal to populate Flutter's display feature model on iOS (flutter/flutter#192515) and the implementation under review (flutter/flutter#193025). Happy to post whatever I learn back there.