[fadi-george]

Description

One Line Summary

Lay out IAMs correctly on iPhone Duo (folded and unfolded) and other resizable scenes, keeping them clear of side safe areas and hardware.

Details

Motivation

On the iPhone Duo, UIScreen bounds report a single panel while UIKit sizes windows to the scene, so IAMs were sized and positioned for the wrong display. Banners also overlapped the side camera in landscape, and full-bleed IAMs left the status bar visible when unfolded.

Scope

• UIApplication displayBounds uses the window scene's bounds instead of UIScreen bounds for the IAM window, webview, and layout.
• Each side uses the larger of the margin and the safe area inset (not their sum). On iOS 27.1+, occlusion reserved regions inside a side safe area (e.g. a foldable's camera) also keep the margin clear, matching system notification banners. Insets are updated on every layout pass. The release toolchain (Xcode 15.2) predates that API, so it's declared locally and looked up at runtime; SDK-5660 tracks bumping the release Xcode and calling it directly.
• Top and bottom use the same max(margin, safe area) through a vertical layout guide.
• Banner window sizes come from the app's full-screen window, since the IAM window's own insets shrink once banner sized and change mid-transition.
• addConstraintsForMessage removes previous messageView constraints before adding new ones, so a stale initial Y constraint can't keep the message offscreen after a size transition.
• viewDidAppear refreshes status bar appearance, since resizable scenes don't re-query prefersStatusBarHidden when the IAM window becomes key.
• Demo app: fills the top inset with the nav bar color.

Out of scope: full screen "no margin" and default HTML close buttons landing on the camera. The SDK already passes the safe area (which covers the camera) through setSafeAreaInsets; the templates ignore the side insets. Tracked in SDK-5657.

No public API changes. Behavior on non-resizable iPhones is unchanged except margins now use max(margin, safe area) instead of their sum.

Note: I did adjust the padding for safe area so things like distance to status bar (right or bottom) now are smaller.

Before:

After:

Testing

Manual testing

Captured with the IAM screenshot tool (capture.sh --all), covering every IAM type (top/bottom/center/full-screen, with and without margins, carousel) plus push banners on the demo app:

• iPhone Duo (iOS 27.1 sim): folded portrait, landscape-left, landscape-right; unfolded landscape and portrait.
• iPhone 18 Pro (iOS 27.0 sim): portrait, landscape-left, landscape-right.
• iPad Pro 11-inch M5 sim: portrait and landscape.

Also checked rotating and folding/unfolding while an IAM is shown.

Screenshots

iPhone 18 Pro

Orientation	Notification Prompt	Simple Notification	Image Notification	IAM Top	IAM Bottom	IAM Center	IAM Full Screen	IAM Full Screen Bleed	IAM Carousel	IAM Carousel Transition	IAM Carousel Bleed	IAM Carousel Bleed Transition	IAM HTML
Portrait
Landscape Left
Landscape Right

iPad Pro 11-inch

Orientation	Notification Prompt	Simple Notification	Image Notification	IAM Top	IAM Bottom	IAM Center	IAM Full Screen	IAM Full Screen Bleed	IAM Carousel	IAM Carousel Transition	IAM Carousel Bleed	IAM Carousel Bleed Transition	IAM HTML
Portrait
Landscape

iPhone Duo

Orientation	Notification Prompt	Simple Notification	Image Notification	IAM Top	IAM Bottom	IAM Center	IAM Full Screen	IAM Full Screen Bleed	IAM Carousel	IAM Carousel Transition	IAM Carousel Bleed	IAM Carousel Bleed Transition	IAM HTML
Folded Portrait
Folded Landscape Left
Folded Landscape Right
Unfolded Portrait
Unfolded Landscape

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
  • Layout depends on real scene geometry and safe areas, verified on simulators above
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

🤖 Generated with Claude Code

[abdulraqeeb33]

The layout rework reads right: scene bounds over UIScreen, the constraint teardown fixes a real per-rotation leak, and the verticalGuide is equivalent to the old anchors for every placement. Two things block, both outside what the simulator matrix can show.

1. The iOS 27.1 reserved-region branch compiles out of the release binaries (inline on the #if).
2. sceneView falls back silently to the banner window (inline).

Not inline because the line isn't in the diff: OSInAppMessageView.m:155 never calls completion on a getPageMetaData() error, so a fold whose JS call fails leaves messageView.hidden = true under a live alert-level window. Pre-existing, but fold/unfold is the hot path now. completion(nil) and rebuilding without a height change would recover it.

Smaller:

• updateHorizontalInsets never re-assigns messageView.horizontalInsets; harmless today since every remeasure is preceded by an assignment, but a one-liner closes it.
• region.frame already includes UIKit's interactive margins per the header, and we add MESSAGE_MARGIN on top. Fine if intended; worth a word in the comment.
• No log records which window sceneView chose, the scene bounds, or the computed insets. One VERBOSE line per addConstraintsForMessage (not per layout pass) would make a Duo layout report reconstructible.
• The inset math has no seam and no tests. Pulling (margin, safeArea, width, regions, isFullscreen) -> UIEdgeInsets into a pure function would let the straddling-region and useWidthMargin == NO cases be unit tested instead of screenshot-only.

[fadi-george]

Re the review summary (52f0398):

• getPageMetaData error: now restores the webview constraints and calls completion(nil); the controller keeps the previous height, so a failed fold/rotation re-shows the message instead of leaving it hidden.
• updateHorizontalInsets now keeps messageView.horizontalInsets in sync.
• Noted in the comment that region frames already include UIKit's margins and the message margin goes on top (intended, matches system banners).
• addConstraintsForMessage logs the chosen scene window, its bounds/safe area and the horizontal insets at VERBOSE.
• Pure inset function + unit tests: filed as SDK-5661 to keep this PR's scope down.

[abdulraqeeb33]

Everything from both rounds is addressed. I checked the runtime shim in isolation: Class-through-protocol dispatch, nil on a missing class, and @available with a version the SDK doesn't know all behave, so the camera clearance ships under the 15.2 pin. You're right on coordinateSpace too: UIWindowSceneGeometry.coordinateSpace is 26+, not 16+, so keeping the deprecated property is the right call on a 15.0 target.

One non-blocking ask inline (ticket link for the toolchain bump). Merge once CI reports green on this head.

[nan-li]

Edit: removed. I posted based on the PR before the last push 13 min ago

[nan-li]

Looks good. Three notes inline, none blocking. The Scope list has no bullet for the full screen insets change, and the manual testing section predates it.

[nan-li]

non-blocking: This only fires when the insets change. On a home-button iPhone the message window's insets are all zero once the bar hides, so if the view attaches after that, the app's 20pt top inset stays in the HTML. Was this checked on an SE?

[abdulraqeeb33]

One cheap way to make this order-independent: also call updateContentInsets from the existing isFullscreen branch in viewDidAppear. That covers attach-after-hide; this callback covers hide-after-attach.

[nan-li]

non-blocking: The header declares newHeight non-null (it's under NS_ASSUME_NONNULL_BEGIN), but this passes nil. NSNumber * _Nullable newHeight in the .h would match the caller's nil check.

[nan-li]

non-blocking: The vertical position comes from the guide constants in updateVerticalInsets, which aren't logged here. Adding them would make a Duo layout report complete.

[abdulraqeeb33]

Looked at eaa970c. The own-window source is right for full-bleed and the guard ordering holds: didPageRenderingComplete is set on the WK callback before the window exists, so setSafeAreaInsets is defined by the first insets change, and it is cleared on dismiss so a late callback cannot push app insets into a torn-down webview. Initial load and PageResize are unchanged in effect. Approval stands.

Two small asks:

1. Add a scope bullet for this in the description; the Testing matrix predates it.
2. Was full-bleed recaptured on the unfolded Duo and an SE-class sim? Those are the displays where the top inset actually moves when the bar hides.