[iOS] Delegate large-title safe area to scroll content

[jfversluis]

Description

Fixes the remaining non-Shell large-title transition reported in #33037 on iOS 26.

A root MAUI Layout currently applies its Container safe area by physically moving nested scroll content as the navigation bar changes height. UIKit requires the active vertical scroll host to remain edge-to-edge to transition from the leading large title to the centered compact title. The bar therefore collapsed while the approximately 42pt large title remained clipped instead of becoming the native approximately 22pt compact title.

This change introduces explicit safe-area layout ownership:

• MauiView supplies full bounds and resolved safe-area insets through an internal ISafeAreaLayout contract.
• Layout first performs its normal safe-area arrangement, then delegates the top safe-area gap to one unambiguous vertical native UIScrollView by extending its frame edge-to-edge and transferring the gap to UIKit content/indicator insets.
• Inset ownership is delta-based, preserves live side/bottom and keyboard-related values, preserves relative scroll position outside active gestures, and is restored during disconnect or when eligibility changes.
• Explicit SafeAreaEdges remains authoritative. Ambiguous layouts retain the existing behavior rather than guessing.
• The final boundary is native UIKit capability, not a MAUI control allow-list: custom and third-party controls backed by a vertical UIScrollView, UITableView, or UICollectionView participate without framework-specific dependencies. A custom MAUI View backed directly by UITableView covers this path.

The old renderer-level SetContentScrollView investigation has been removed; this fix uses standard UIKit frames and UIScrollView inset APIs only.

Eligibility safeguards

Delegation requires iOS 26+, an implicit top Container safe area, a visible translucent navigation bar that prefers large titles, one exclusive vertical scroll subtree, and valid overlay stacking for fixed top siblings. Hidden, transparent, horizontal, explicitly safe-area-configured, or ambiguous candidates are rejected.

Runtime validation

Verified on iPhone 17 Pro / iOS 26.5:

• Modal nested ListView: leading large title collapses to a centered compact title and expands again on return to top.
• Direct/wrapped ScrollView, ListView, TableView, CollectionView, CarouselView, and WebView scenarios.
• Fixed-header and programmatic-scroll scenarios.
• Custom third-party-like MAUI View whose handler exposes a native UITableView.
• Scroll-host frame remains stable and edge-to-edge throughout the transition.
• Repeated close/reopen after scrolling does not crash.

Original nested scenario

Expanded	Collapsed

Custom native-scroll control

Expanded	Collapsed

Tests

• iOS Controls device tests, Category=Layout: 31 passed, 1 skipped, 0 failed.
• Controls HostApp iOS simulator build: succeeded with 0 warnings/errors.
• Shared UI test assembly build: succeeded with 0 warnings/errors.
• Full maui-pr and Build Analysis checks: passed, including Windows/macOS builds, Helix unit tests, and integration legs.

Note

This remains a draft architectural spike for maintainer review of the new safe-area ownership contract.

[MauiBot]

Expert Review — 13 findings

See inline comments for details.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[critical] Regression Prevention and Test Coverage — The added test block is structurally unbalanced: the try opened in HiddenNavigationBarPreservesTopSafeArea is closed by a bare } with no catch/finally, so the following [Test] public void OrdinaryHeaderPreservesSafeAreaLayout() (and the ones after it) are parsed as nested local declarations. The whole TestCases.Shared.Tests assembly fails to compile: CS1524: Expected catch or finally at the closing brace above, CS0106: The modifier 'public' is not valid for this item at 230/249/272/298, and CS1513: } expected at 317/322.

Concrete consequence: pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform ios -TestFilter "Issue33037NonShell" fails to build both with and without the fix, so this PR currently ships zero executable regression coverage for #33037 — the fix is unverified end-to-end. Add the missing finally { App.Back(); } to close each try at its intended method boundary (matching the pattern used at line 208) and re-balance the trailing braces.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[critical] Safe Area and Window Insets — When top-inset delegation is active this branch hard-forces ContentInsetAdjustmentBehavior = Never and return trues before the per-edge region switch below. Never disables UIKit's automatic adjustment for every edge, not just Top, but ApplyDelegatedTopInset only re-adds a Top inset — nothing re-applies Left/Right/Bottom.

Concrete scenario: a NavigationPage page whose root Layout hosts a ScrollView with the default SafeAreaRegions.Container (which previously mapped to Always, i.e. UIKit supplied the bottom inset). On an iOS 26 device with a home indicator, as soon as delegation engages the bottom safe-area inset drops to 0 and the last item scrolls under the home indicator / is unreachable. The same applies to landscape left/right notch insets.

The delegated path needs to preserve the non-Top edge insets — either fall through to the existing region switch and layer the delegated Top inset on top of the resulting ContentInset, or explicitly compute and apply Left/Right/Bottom manual insets before returning.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[major] Safe Area and Window Insets — Same non-Top-inset loss as the MauiScrollView delegated path, but here it is applied to a foreign UIScrollView that MAUI does not own — WKWebView.ScrollView (via the WebView fallback in ResolveNativeScrollView), UITableView from ListView/TableView, or a third-party handler's scroll view. Forcing ContentInsetAdjustmentBehavior = Never on those cancels the bottom/side safe-area insets that UIKit was supplying for them, and only the Top inset is re-added on the following lines.

Concrete scenario: Layout > WebView under a large-title NavigationPage on iOS 26 — page content now runs under the home indicator, and the web view's own scroll indicator insets no longer clear the bottom edge. Additionally, _previousInsetAdjustmentBehavior is captured only inside the identity-change branch at line 96, so if the same scroll view instance is re-delegated after an external component changed its behavior, ResetNativeScrollInsetOwnership restores a stale value.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[major] Regression Prevention and Test Coverage — This PR deletes the entire large-title proxy scroll view implementation from ParentingViewController (_largeTitleProxyScrollView, _largeTitleObservedScrollView, _largeTitleContentOffsetObserver, UpdateLargeTitleProxyScrollView, TearDownLargeTitleProxyScrollView, ScheduleLargeTitleProxyScrollObservation, and the _isAppeared gating in ViewDidAppear/ViewDidDisappear/ViewDidLayoutSubviews), plus this UpdateCurrentPageLargeTitleProxy() call.

git log shows that code was added by #36511 "[iOS] NavigationPage: Fix large-title collapse for wrapped scroll content". The mechanical regression scan reported CLEAN (it only matches labeled bug-fix PRs), so this revert is unflagged. The proxy path covered all iOS versions, whereas the replacement (ShouldDelegateTopSafeAreaToScrollContent) is gated on OperatingSystem.IsIOSVersionAtLeast(26) and on the host being a Microsoft.Maui.Controls.Layout implementing ISafeAreaLayout.

Concrete scenario: on iOS 18, or on any page whose root is a ContentView/ScrollView rather than a Layout, #36511's wrapped-scroll-content large-title collapse no longer works and there is nothing left to restore it. Please confirm the #36511 scenarios are still covered (or intentionally regressed) and keep its regression test green.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[major] Performance-Critical Path Optimization — FindNativeScrollView performs an unbounded, uncached, recursive walk of the entire native UIView subtree, and it is reachable from FindVerticalScrollContent for every child of the layout on every CrossPlatformArrange pass (line 39 loop → line 187 ResolveNativeScrollView). ResolveNativeScrollView may run the walk twice for a WebView (once with verticallyScrollableOnly: true, once with false).

Arrange runs on every LayoutSubviews, i.e. on every scroll-driven relayout, rotation, keyboard show/hide, and safe-area change. For a page with a deep native tree (CollectionView cells, WebView, nested Borders) this is a per-frame O(native-subtree) traversal on the layout hot path. Cache the resolved UIScrollView alongside the existing _delegatedNativeScrollView weak reference and invalidate on child/handler change, or bail out of the search before the recursive descent when the candidate is already known.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[moderate] Logic and Correctness Verification — The delegation eligibility test is driven by four undocumented magic numbers with no named constants or rationale: tolerance = 1 (point? pixel? device-scale independent?), frame.Height >= safeBounds.Height / 2 ("occupies most of"), and Opacity <= 0.01 repeated at lines 41, 172, and 217.

Concrete scenario: a page with a header taking 55% of the height and a scroll view taking 45% silently loses large-title collapse, with nothing in the code explaining that 50% is the cut-off. On a 3x device a 1-point tolerance is 3 physical pixels, which is a different tolerance than on a 2x device — the codebase's existing convention for this (see EqualsAtPixelLevel in the iOS safe-area code) is pixel-level comparison. Please extract these to named constants with comments justifying each threshold.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[moderate] Regression Prevention and Test Coverage — TransferNativeScrollInsetOwnership/ResetNativeScrollInsetOwnership contain the riskiest logic in the PR — save/restore of ContentInset, VerticalScrollIndicatorInsets, ContentInsetAdjustmentBehavior, and ContentOffset compensation via distanceFromTop — yet the only coverage added is the UI test file that currently does not compile (see Issue33037NonShell.cs:227).

This math is unit-testable without a device: repeated Transfer calls must be idempotent (the baseContentTop = contentInset.Top - _delegatedTopInset subtraction is what prevents inset accumulation), and Reset must return the scroll view to exactly its pre-delegation insets/behavior. Add device tests in Core.DeviceTests (iOS) asserting round-trip inset restoration and no accumulation across N arrange passes, so a regression here is caught without relying on screenshot UI tests.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[moderate] Handler Mapper and Property Patterns — DisconnectSafeArea() is invoked here on every LayoutSubviews pass for any ISafeAreaLayout whose _appliesSafeAreaAdjustments is false, not just on an actual disconnect. That conflates two different lifecycle events on the same entry point, and it means the reset path (which reads ContentOffset/AdjustedContentInset and writes ContentInset on the previously delegated scroll view) is on the arrange hot path.

It is also asymmetric with LayoutHandler.iOS.cs:125, which calls the same method from DisconnectHandler. Consider naming the per-layout call something like ReleaseDelegatedSafeArea() and keeping DisconnectSafeArea for the handler teardown, so a future change to teardown semantics does not silently alter arrange behavior.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[minor] Safe Area and Window Insets — GetSafeAreaRegionsForEdge(1) uses a bare magic int for the Top edge. The rest of this same file annotates these calls (see line 471: GetSafeAreaRegionsForEdge(3); // 3 = bottom edge) or assigns them to named locals (lines 108-111). Add the // 1 = top edge comment or a shared named constant so a future edge-index change does not silently invert this gate.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[minor] Architectural Layer Placement — ISafeAreaLayout is declared unconditionally for all target frameworks, but its only implementer is Layout.iOS.cs and its only consumers are MauiView.cs (iOS) and LayoutHandler.iOS.cs (iOS). The companion ISafeAreaScrollView in the same file is guarded by #if IOS. The inconsistency ships an unused interface into the Android/Windows/Tizen builds of Microsoft.Maui.dll and invites a future non-iOS implementation of a contract whose delegateTopInset parameter has iOS-only meaning. Either put both interfaces behind #if IOS, or drop the guard from both and document the cross-platform contract.

[MauiBot]

Expert Review — 12 findings

See inline comments for details.

[MauiBot]

🔍 AI-Generated Review (multi-model)

❌ [critical] Logic and Correctness / Safe Area — This new branch calls ValidateSafeArea() directly and returns, bypassing AdjustForSafeArea(bounds) entirely. AdjustForSafeArea is not just _safeArea.InsetRect(bounds) — it also contains the keyboard hook:

if (KeyboardAutoManagerScroll.ShouldIgnoreSafeAreaAdjustment)
    KeyboardAutoManagerScroll.ShouldScrollAgain = true;

ValidateSafeArea();
return _safeArea.InsetRect(bounds);

Because CrossPlatformLayout is ISafeAreaLayout is true for every Microsoft.Maui.Controls.Layout (Grid/StackLayout/etc.) that applies safe-area adjustments — i.e. the overwhelmingly common page-content root — ShouldScrollAgain is now never set from this path. Concrete scenario: a page whose content is a Grid with safe-area insets; an Entry near the bottom is focused while the keyboard is animating in. KeyboardAutoManagerScroll sets ShouldIgnoreSafeAreaAdjustment, expects the subsequent arrange to flag ShouldScrollAgain, and never gets it, so the follow-up scroll that brings the focused field above the keyboard is skipped.

The delegateTopInset feature is scoped to iOS 26 + large titles, but this bypass is unconditional. Route this branch through AdjustForSafeArea (or hoist the keyboard block above the ISafeAreaLayout check) so the keyboard path is preserved.

[MauiBot]

🔍 AI-Generated Review (multi-model)

⚠️ [major] Performance-Critical Path — ShouldDelegateTopSafeAreaToScrollContent() is evaluated on every CrossPlatformArrange of every safe-area-adjusting Layout, and each call does a responder-chain walk (FindResponder<UIViewController>()) plus five separate ObjC bridge property reads (NavigationController, NavigationBar, Hidden, Translucent, PrefersLargeTitles, NavigationItem.LargeTitleDisplayMode). Arrange runs on every layout pass, on rotation, on keyboard show/hide, and on every scroll-induced relayout.

The cheap, high-selectivity guards already come first (OperatingSystem.IsIOSVersionAtLeast(26), _safeArea.Top <= 0), which limits the damage, but the responder walk still runs on every arrange for any iOS 26 page with a top inset — including pages with no NavigationPage at all, where FindResponder<UIViewController>() walks the full chain only to return a controller with a null NavigationController.

Cache the resolved UIViewController/UINavigationBar (they only change on MovedToWindow/re-parenting) and invalidate on window/superview transitions rather than re-walking per arrange.

[MauiBot]

🔍 AI-Generated Review (multi-model)

⚠️ [major] Regression Prevention — The removed ParentingViewController code re-evaluated the large-title state reactively, from OnPropertyChanged for NavigationPage.PrefersLargeTitles, NavigationPage.HasNavigationBar, LargeTitleDisplay, and ContentPage.Content (UpdateLargeTitleProxyScrollView() / RestartLargeTitleProxyScrollView()). This replacement is evaluated only during CrossPlatformArrange.

None of those four property changes is guaranteed to invalidate the content Layout and force an arrange pass — PrefersLargeTitles and LargeTitleDisplay change the navigation bar, not the layout's measured size. Concrete scenario: a page has the delegated top inset applied, then user code calls NavigationPage.SetPrefersLargeTitles(navPage, false) (or sets LargeTitleDisplay = Never, or NavigationPage.SetHasNavigationBar(page, false)). ShouldDelegateTopSafeAreaToScrollContent() is not re-run, so ResetNativeScrollInsetOwnership() never fires and the scroll view keeps a stale ContentInset.Top sized for a large title that no longer exists — content is pushed down by a phantom inset until an unrelated relayout happens.

Add an explicit invalidation path (e.g. InvalidateSafeArea()/SetNeedsLayout() on the content view) driven by those navigation-bar property changes, and a regression test that toggles PrefersLargeTitles/HasNavigationBar at runtime after the inset has been delegated.

[MauiBot]

🔍 AI-Generated Review (multi-model)

💡 [minor] Safe Area — GetSafeAreaRegionsForEdge(1) uses a bare magic index for the Top edge. The same magic indices appear throughout MauiView/MauiScrollView (0=Left, 1=Top, 2=Right, 3=Bottom), but this is new code adding another unlabeled call site in a file where an off-by-one silently reads the wrong edge with no compile-time signal. Introduce named constants (or an enum) for the edge indices rather than propagating the literal.

[MauiBot]

🔍 AI-Generated Review (multi-model)

❌ [critical] Layout Measure-Arrange / Safe Area — The bool returned by UpdateContentInsetAdjustmentBehavior() is discarded here (and again in ResetDelegatedTopInset, line 354). Every other caller uses it — ValidateSafeArea() does:

if (UpdateContentInsetAdjustmentBehavior())
{
    InvalidateConstraintsCache();
    _safeAreaInvalidated = true;
}

Because this call also latches _previousTopSafeAreaDelegation = _isTopSafeAreaDelegated, the true return that signals the delegation transition is consumed and thrown away here. The next ValidateSafeArea() sees _previousEdges.Equals(safeAreaEdges) && _previousTopSafeAreaDelegation == _isTopSafeAreaDelegated and returns false, so InvalidateConstraintsCache() / _safeAreaInvalidated = true are never run for the transition.

Concrete consequence: switching ContentInsetAdjustmentBehavior from Always (the SafeAreaRegions.Container case) to Never flips UIKitCompensatesForSafeArea, which changes which source ValidateSafeArea reads (SafeAreaInsets vs SystemAdjustedContentInset) — but _safeArea is not recomputed and the measurement cache is not invalidated. _blockedEdgesCacheValid is likewise left untouched, even though the delegated scroll view's frame is simultaneously extended up under the navigation bar (Layout.iOS.cs:77), which changes its raw SafeAreaInsets.Top from 0 to non-zero. The scroll view keeps measuring against the pre-delegation safe area for at least one pass, and if nothing else dirties it, indefinitely.

Call InvalidateSafeArea() (or honor the return value the way ValidateSafeArea does) from both ApplyDelegatedTopInset and ResetDelegatedTopInset.

[MauiBot]

🔍 AI-Generated Review (multi-model)

⚠️ [major] Complexity Reduction / Architectural Layer — TransferNativeScrollInsetOwnership (lines 89–137) and ResetNativeScrollInsetOwnership (lines 141–186) duplicate, line for line, the inset-transfer math in MauiScrollView.ApplyDelegatedTopInset / ResetDelegatedTopInset — same distanceFromTop computation, same baseContentTop/baseIndicatorTop subtraction, same UIEdgeInsets reconstruction, same !Dragging && !Decelerating offset restore. Two copies of subtle scroll-inset arithmetic will drift; the ISafeAreaScrollView copy in Core has already grown a _previousTopSafeAreaDelegation latch that this copy does not have.

The non-ISafeAreaScrollView fallback also carries two state bugs of its own:

• _previousInsetAdjustmentBehavior is captured only when the delegated target changes (line 98), but line 115 forces Never on every call. If anything else legitimately changes that scroll view's ContentInsetAdjustmentBehavior while delegation is active, ResetNativeScrollInsetOwnership restores the stale captured value instead of the current one.
• ClearNativeScrollInsetOwnership() resets _delegatedTopInset and _delegatedScrollIndicatorTopInset but leaves _previousInsetAdjustmentBehavior stale, so it survives into an unrelated later delegation of an ISafeAreaScrollView target (which never reassigns it).

Extract the shared math into one helper (e.g. a UIScrollView extension) that both paths call, and reset _previousInsetAdjustmentBehavior in ClearNativeScrollInsetOwnership.

[MauiBot]

🔍 AI-Generated Review (multi-model)

⚠️ [major] Performance-Critical Path — This candidate scan runs inside CrossPlatformArrange — the arrange hot path — and allocates on every pass:

• foreach (var child in this) enumerates Layout through IEnumerable<IView>, boxing/allocating an enumerator per arrange pass.
• FixedTopSiblingsAreOverlays (line 218) re-enumerates all siblings for each candidate child, making this O(n²) with another enumerator allocation per candidate.
• FindVerticalScrollContent (line 239) is called for every child and recurses via visualElement.GetVisualChildren() (line 281), which allocates a fresh IReadOnlyList at every node of the subtree, every pass.

For a page with a moderately deep Grid/StackLayout tree this is dozens of allocations and a full visual-tree walk per layout pass, repeated on every scroll-induced relayout and every keyboard/rotation transition. Per the hot-path rule, use indexed for (int i = 0; i < Count; i++) over this[i], hoist the sibling scan out of the per-candidate loop (single pass computing the topmost non-overlay sibling bottom), and cache the resolved scroll host, invalidating on child-collection changes rather than re-deriving it every arrange.

[MauiBot]

🔍 AI-Generated Review (multi-model)

⚠️ [major] Performance-Critical Path / iOS Platform — FindNativeScrollView does an unbounded recursive depth-first walk of the native view hierarchy, and every level reads view.Subviews, which marshals a fresh UIView[] across the ObjC bridge (NSArray → managed array) for each node. This is invoked from ResolveNativeScrollView, which is called both inside FindVerticalScrollContent (line 265) and again on the winning candidate (line 68) — so the subtree is walked at least twice per arrange pass, and for WebView a third time via the verticallyScrollableOnly: false fallback (line 195) whenever the first walk misses.

There is no depth limit and no early-out, so for a CollectionView/WebView with a populated cell tree this walks the entire realized native subtree on every layout pass. Cache the resolved UIScrollView per host (weakly, as is already done for _delegatedNativeScrollView) and re-resolve only when the host's handler changes, and bound the recursion depth.

[MauiBot]

🔍 AI-Generated Review (multi-model)

⚠️ [major] Logic and Correctness / CollectionView iOS — IsVerticallyScrollable will report false for a genuinely vertical scroller in two reachable cases:

1. The UICollectionView branch only matches UICollectionViewFlowLayout. MAUI's active iOS CollectionView handler (Items2/) uses UICollectionViewCompositionalLayout, which is not a UICollectionViewFlowLayout, so any nested/native UICollectionView reached through FindNativeScrollView falls through to the heuristic below instead of being recognised.
2. The fallback scrollView.AlwaysBounceVertical || (!AlwaysBounceHorizontal && ContentSize.Height > Bounds.Height) is evaluated during arrange. On the first arrange pass ContentSize is typically still 0 (content not yet realized/sized) and Bounds may also be 0, so 0 > 0 is false and AlwaysBounceVertical defaults to false — the scroll view is classified as non-vertical and delegation is skipped for that pass.

Concrete symptom: on first navigation to the page the large title does not collapse (or the top inset is not delegated), and the behavior only corrects itself once some later relayout happens after content size is known — a visible one-frame jump or a permanently wrong state if no further arrange occurs. Add an explicit UICollectionViewCompositionalLayout check (via Configuration.ScrollDirection), and re-evaluate delegation when the scroll view's ContentSize first becomes non-zero.

[MauiBot]

🔍 AI-Generated Review (multi-model)

⚠️ [major] Regression Prevention / Handler Disconnect — This is the only teardown path that releases delegated scroll-inset ownership when a Layout is torn down, and it has no test coverage. The PR's tests (Issue33037NonShell) are all iOS-26-gated UI tests that exercise the happy path — they scroll and assert the title collapses. None of them exercises the negative/release cases that this state machine depends on:

• handler disconnect while an inset is applied (this line);
• the scroll host being removed or hidden so candidateCount drops to 0, or a second candidate appearing so candidateCount > 1 → ResetNativeScrollInsetOwnership() (Layout.iOS.cs:60);
• navigating away and back (Shell/NavigationPage remove and re-add platform views — DisconnectHandler runs, then the view is re-connected), where a missed reset leaves a doubled ContentInset.Top.

A passing green suite here does not prove the inset is ever released, because every current test asserts only that the inset was applied. Add at least one test that applies delegation, removes/replaces the scroll host (or pops and re-pushes the page), and asserts ContentInset.Top / the host's on-screen Y returns to its undelegated value.

[MauiBot]

AI Review Summary

@jfversluis — new AI review results are available based on commit d65e6e8.

---

🗂️ Review Sessions — click to expand

🚦 Gate — Test Before & After Fix

Gate Result: ❌ FAILED

Platform: IOS · Base: inflight/current · Merge base: ac5c53f5

🩺 The PR's test does not compile — the build error is in one of the PR's own test files, which the gate never reverts, so it fails identically without and with the fix. This is NOT a pre-existing/environment failure — the PR must fix its test (e.g. an ambiguous using / type collision). Investigate the PR's test code.

/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(226,3): error CS1524: Expected catch or finally [/Users/cloudtest/vss/_work/1/s/src/Controls...

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🖥️ Issue33037NonShell Issue33037NonShell	🛠️ BUILD ERROR	🛠️ BUILD ERROR

🔴 Without fix — 🖥️ Issue33037NonShell: 🛠️ BUILD ERROR · 247s

Error-relevant lines (filtered from the build log):

/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(226,3): error CS1524: Expected catch or finally [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(230,3): error CS0106: The modifier 'public' is not valid for this item [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(245,4): error CS1524: Expected catch or finally [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(249,4): error CS0106: The modifier 'public' is not valid for this item [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(272,4): error CS0106: The modifier 'public' is not valid for this item [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(298,4): error CS0106: The modifier 'public' is not valid for this item [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(317,5): error CS1513: } expected [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(322,4): error CS1513: } expected [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]

🟢 With fix — 🖥️ Issue33037NonShell: 🛠️ BUILD ERROR · 98s

Error-relevant lines (filtered from the build log):

/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(226,3): error CS1524: Expected catch or finally [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(230,3): error CS0106: The modifier 'public' is not valid for this item [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(245,4): error CS1524: Expected catch or finally [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(249,4): error CS0106: The modifier 'public' is not valid for this item [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(272,4): error CS0106: The modifier 'public' is not valid for this item [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(298,4): error CS0106: The modifier 'public' is not valid for this item [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(317,5): error CS1513: } expected [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(322,4): error CS1513: } expected [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj]

⚠️ Failure Details

• 🛠️ Issue33037NonShell without fix: build failed before tests could run
  • /Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(226,3): error CS1524: Expected catch or finally [/Users/cloudtest/vss/_work/1/s/src/Controls...
• 🛠️ Issue33037NonShell with fix: build failed (fix does not compile)
  • /Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs(226,3): error CS1524: Expected catch or finally [/Users/cloudtest/vss/_work/1/s/src/Controls...

📁 Fix files reverted (5 files)

• src/Controls/src/Core/Compatibility/Handlers/NavigationPage/iOS/NavigationRenderer.cs
• src/Controls/src/Core/Layout/Layout.iOS.cs
• src/Core/src/Handlers/Layout/LayoutHandler.iOS.cs
• src/Core/src/Platform/iOS/MauiScrollView.cs
• src/Core/src/Platform/iOS/MauiView.cs

New files (not reverted):

• src/Core/src/Core/ISafeAreaLayout.cs

---

📋 Pre-Flight — Context & Validation

PR #37548 Pre-Flight

Context

• Title: [iOS] Delegate large-title safe area to scroll content
• Issue: #33037, iOS Large Title display disappears
• Target: inflight/current
• Head: jfversluis-fix-33037-follow-up (d65e6e865c8e295f40c082d4bf192d1dd681101b)
• Platform: iOS 26+
• Problem: In a non-Shell NavigationPage, a root MAUI Layout consumes the top container safe area and moves a nested native scroll host below the navigation bar. UIKit therefore cannot observe the expected edge-to-edge scroll geometry and collapses the bar while leaving the large title clipped instead of transitioning to the compact title.

Existing PR Approach

The PR removes the prior NavigationRenderer proxy-scroll-view implementation and introduces layout-owned safe-area delegation:

1. MauiView supplies its full bounds and resolved safe-area insets through a new internal ISafeAreaLayout contract.
2. Layout.iOS.cs performs normal safe-area arrangement, searches for exactly one eligible vertical scroll subtree, extends that host to the top edge, and transfers the displaced top gap into native content and indicator insets.
3. MauiScrollView tracks delegated inset ownership, forces ContentInsetAdjustmentBehavior.Never while delegated, preserves the relative scroll position outside active gestures, and restores its previous state.
4. LayoutHandler.iOS.cs resets delegated ownership on disconnect.
5. Eligibility is limited to iOS 26+, implicit top Container safe area, a visible translucent large-title navigation bar, one unambiguous vertical scroll subtree, and compatible fixed-sibling stacking. Explicit safe-area ownership and ambiguous layouts retain existing behavior.

PR Diff

File	Change
src/Controls/src/Core/Compatibility/Handlers/NavigationPage/iOS/NavigationRenderer.cs	Removes the 342-line proxy UIScrollView workaround and its lifecycle/KVO hooks.
src/Controls/src/Core/Layout/Layout.iOS.cs	Adds candidate discovery, frame extension, inset transfer/reset, native scroll resolution, and ambiguity/overlay checks.
src/Controls/tests/TestCases.HostApp/Issues/Issue33037NonShell.cs	Adds host scenarios for native and MAUI scroll controls plus eligibility safeguards.
src/Controls/tests/TestCases.HostApp/MauiProgram.cs	Registers the custom native-scroll test handler.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33037NonShell.cs	Adds iOS UI tests; the current file has malformed nested try/test blocks.
src/Core/src/Core/ISafeAreaLayout.cs	Adds internal safe-area layout and iOS scroll-inset contracts.
src/Core/src/Handlers/Layout/LayoutHandler.iOS.cs	Resets delegated safe-area state during disconnect.
src/Core/src/Platform/iOS/MauiScrollView.cs	Implements delegated top-inset ownership and restoration.
src/Core/src/Platform/iOS/MauiView.cs	Routes eligible safe-area arrangement through ISafeAreaLayout.

Gate Evidence

Gate verification already failed and must not be rerun. Both without-fix and with-fix runs stopped while compiling:

Issue33037NonShell.cs(226,3): error CS1524: Expected catch or finally
Issue33037NonShell.cs(230,3): error CS0106: The modifier 'public' is not valid for this item

The first missing finally begins after HiddenNavigationBarPreservesTopSafeArea; subsequent tests are nested inside its try block. The gate never reached runtime behavior.

The gate identified these production fix files:

• src/Controls/src/Core/Compatibility/Handlers/NavigationPage/iOS/NavigationRenderer.cs
• src/Controls/src/Core/Layout/Layout.iOS.cs
• src/Core/src/Core/ISafeAreaLayout.cs (new in the PR)
• src/Core/src/Handlers/Layout/LayoutHandler.iOS.cs
• src/Core/src/Platform/iOS/MauiScrollView.cs
• src/Core/src/Platform/iOS/MauiView.cs

EstablishBrokenBaseline.ps1 can revert the five pre-existing files, but reports src/Core/src/Core/ISafeAreaLayout.cs as a PR-added file. Under the try-fix baseline-file boundary, a non-empty NewFiles array is an explicit blocker and must be recorded rather than bypassed.

Bounded Validation

Detected primary test:

pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform ios -TestFilter "Issue33037NonShell"

No additional mandatory regression command was supplied in the STEP 5a request. Do not run the gate again or any full suite. Each candidate is limited to one implementation/test pass and at most one focused correction/retest.

---

🔬 Code Review — Deep Analysis

Code Review — PR #37548

Verdict: NEEDS_CHANGES
Confidence: low

Independent Assessment

What this changes: The PR removes the NavigationRenderer proxy-scroll implementation and moves iOS 26 large-title handling into layout. MauiView passes full bounds plus resolved safe-area insets to Layout, which selects one vertical native scroll host, extends only its native frame under the navigation bar, transfers the displaced top gap to scroll-content and indicator insets, and restores those values when eligibility or handler lifetime changes.

Inferred motivation: UIKit only performs the native large-to-compact title transition when the active vertical scroll view remains edge-to-edge. The submitted approach tries to preserve MAUI's existing logical safe-area layout while exposing the required native geometry.

Approach assessment: The ownership direction addresses the demonstrated root cause and is more general than a MAUI control allow-list, but the current implementation is not safe to merge. It splits logical and native frame ownership, mutates UIKit's all-edge inset policy to solve a top-edge problem, and performs expensive discovery in the arrange hot path. The submitted UI-test source also does not compile, so none of the new regression scenarios executed in the trusted Gate.

Reconciliation with PR Narrative

The description accurately explains the intended geometry, eligibility boundary, and supported control families. It overstates verification for the submitted HEAD: the checked-in test file is structurally malformed, the trusted Gate stopped at compiler errors, and the claimed all-edge/live-inset preservation is not established when ContentInsetAdjustmentBehavior changes from UIKit-managed adjustment to Never.

Prior Review Reconciliation

Prior ❌ finding	Status	Evidence
Added UI tests do not compile because HiddenNavigationBarPreservesTopSafeArea has an unterminated try	❌ Unresolved	Issue33037NonShell.cs:221-228 still transitions directly from the try block to another [Test]; Gate reports CS1524/CS0106.
Delegation forces ContentInsetAdjustmentBehavior.Never, losing UIKit-provided non-top safe areas	❌ Unresolved	Both the MAUI and foreign-scroll paths preserve raw ContentInset.Left/Bottom/Right, but those values do not include side/bottom contributions previously supplied only through AdjustedContentInset.
Generic layout code writes behind MauiScrollView's own inset pipeline	✅ Fixed in current HEAD	Current HEAD introduces ISafeAreaScrollView; MAUI scroll views now route through their own state machine. The foreign-scroll fallback remains separate and risky.
Native-only PlatformArrange desynchronizes the platform frame from IView.Frame	❌ Unresolved	Layout.iOS.cs:25 performs normal managed arrange, then line 77 overwrites only the native frame.

Blast Radius Assessment

• Runs for all instances: The new interface branch runs for every safe-area-adjusting MAUI Layout; large-title delegation is gated, but the bypass of AdjustForSafeArea is not.
• Startup/page initialization: Yes. Candidate discovery and inset transfer run during initial page arrange, before native ContentSize is necessarily stable.
• Static/shared state: No new static state. Ownership is retained per Layout/MauiScrollView.
• Lifecycle: Reset is wired to layout ineligibility and LayoutHandler.DisconnectHandler, but release paths lack executable regression coverage.

CI Status

• Trusted Gate: ❌ PR-caused compile failure; required UI-test validation never ran.
• Current remote HEAD: maui-pr and Build Analysis are red; most legs pass, while MultiProject macOS and RunOniOS MauiRelease ARM64 report failure.
• Classification: The trusted Gate failure is conclusively PR-caused. Remote failing legs are not sufficient to establish runtime correctness and remain unclassified here.
• Action: No Gate rerun, per execution contract. Confidence is capped at low.

Findings

❌ Error — Keyboard auto-scroll follow-up is bypassed

MauiView.CrossPlatformArrange now returns from the ISafeAreaLayout branch without calling AdjustForSafeArea. That helper also maps KeyboardAutoManagerScroll.ShouldIgnoreSafeAreaAdjustment to ShouldScrollAgain; losing this side effect affects every safe-area root Layout, not only eligible iOS 26 large-title pages.

❌ Error — Delegation drops UIKit-managed side and bottom insets

Both delegation paths force ContentInsetAdjustmentBehavior.Never but transfer only the top gap. When UIKit had supplied left/right/bottom safe areas through AdjustedContentInset, preserving the raw ContentInset fields does not preserve those system contributions. Landscape notch and home-indicator avoidance can regress.

❌ Error — Submitted regression tests cannot compile

The missing finally after HiddenNavigationBarPreservesTopSafeArea nests subsequent test declarations in a try block. This directly caused the trusted Gate to fail before runtime validation.

❌ Error — MauiScrollView delegation transition consumes invalidation state

ApplyDelegatedTopInset and ResetDelegatedTopInset call UpdateContentInsetAdjustmentBehavior() but discard its transition result after latching _previousTopSafeAreaDelegation. The safe-area source and native geometry change at the same time; the state machine must explicitly invalidate its safe-area and measure caches rather than rely on callback timing.

⚠️ Warning — Managed and native frames intentionally diverge

The normal arrange records the safe-area-inset IView.Frame, then Handler.PlatformArrange extends only the native frame. This gives UIKit the desired geometry but leaves managed bounds, hit-test/gesture coordinates, and rendered bounds with different origins and heights. The architectural tradeoff needs explicit resolution or targeted proof.

⚠️ Warning — Eligibility and native discovery are unstable and expensive

The arrange path repeatedly scans managed siblings and recursively marshals native Subviews; generic vertical detection also depends on first-pass ContentSize and does not identify compositional collection layouts directly. This can switch delegation after initial layout and creates O(n²)/subtree work in a hot path.

⚠️ Warning — Runtime navigation-state changes have no explicit invalidation path

The deleted renderer reacted to PrefersLargeTitles, HasNavigationBar, LargeTitleDisplay, and content changes. The replacement re-evaluates only during arrange, so a runtime eligibility change can leave ownership stale until an unrelated layout occurs.

Failure-Mode Probing

• Ordinary non-large-title pages: They skip top delegation, but safe-area root layouts still take the new interface branch and therefore still miss the keyboard hook.
• Disconnect/reconnect: Teardown attempts to restore ownership, but the malformed tests provide no executable proof against doubled or stale insets.
• Initial layout: Generic native scroll views can report empty bounds/content and be rejected, then become eligible on a later pass, producing a visible geometry change.
• Landscape/home indicator: Switching adjustment behavior to Never removes system-managed non-top contributions unless they are transferred explicitly.
• Repeated arrange/programmatic animation: Identical inset and offset values are rewritten without an idempotency guard; an animated programmatic scroll is neither dragging nor decelerating and can be snapped.

External Output Contract

Not applicable.

Trim/AOT Evidence Chain

Not applicable.

Verdict: NEEDS_CHANGES

The raw PR cannot be approved because its required tests do not compile and concrete safe-area/keyboard regressions remain. A consolidated reviewer candidate may repair the compile failure and the bounded production defects, but it must be treated as a changed candidate and validated once under the execution contract.

---

🛠️ Try-Fix — Analysis & Comparison

PR #37548 — Bounded Try-Fix Aggregate

Candidate 1 — Native UIKit Safe-Area Ownership

• Model: claude-opus-5
• Result: Blocked
• Approach: For an eligible non-Shell NavigationPage, stop MauiView from consuming the implicit top Container safe area and preserve native UIScrollView.ContentInsetAdjustmentBehavior.Automatic. This would make the real scroll host edge-to-edge from the outset and let UIKit calculate AdjustedContentInset and drive the large-title transition, rather than compensating after MAUI layout with either a proxy scroll view or the PR's ISafeAreaLayout inset-transfer contract.
• Mechanism-level distinction: The PR accepts an already-consumed safe area and repairs the child frame/insets downstream. Candidate 1 instead proposed preventing the initial managed top-inset consumption so no recursive candidate discovery, frame rewrite, manual inset transfer, or delegated state restoration would be required.
• Files changed / diff: None; the captured diff is empty.
• Validation: Not run. EstablishBrokenBaseline.ps1 rejected the pre-existing dirty worktree before creating .github/.baseline-state.json, so the skill's modification allow-list did not exist. The PR-added src/Core/src/Core/ISafeAreaLayout.cs would independently make NewFiles non-empty. Both conditions require a Blocked result before editing. Re-running the primary UI test on unchanged code would also only repeat the gate's known test-compilation failure.
• Failure analysis: This is a deterministic restoration-boundary blocker, not evidence for or against the proposed mechanism. The malformed Issue33037NonShell.cs test remains an independent validation blocker.
• Self-review: 0 findings; one inline self-review pass over an empty diff.
• Artifacts: CustomAgentLogsTmp/PRState/37548/PRAgent/try-fix/attempt-1/
• Narrative: CustomAgentLogsTmp/PRState/37548/PRAgent/try-fix-1/content.md

Candidate 2 — Explicit iOS 26 Top-Edge Scroll Association

• Model: gpt-5.6-sol
• Result: Blocked
• Approach: Have NavigationRenderer resolve the real eligible descendant UIScrollView and explicitly register that instance as the page view controller's iOS 26 top-edge content scroll view. Refresh the association when the visible page or native host changes and clear it during disappearance/disposal, while leaving MAUI safe-area arrangement and native inset behavior unchanged.
• Mechanism-level distinction: Unlike the deleted proxy, this identifies the real scroll source. Unlike the PR, it does not extend frames, transfer insets, force ContentInsetAdjustmentBehavior.Never, or add layout ownership state. Unlike candidate 1, it neither suppresses root safe-area consumption nor relies on automatic descendant discovery; it hypothesizes that failed UIKit scroll-host identification is the root cause and supplies that identity directly.
• Files changed / diff: None; the captured diff is empty.
• Validation: Not run. Baseline establishment again stopped before producing .github/.baseline-state.json; the known PR-added file would independently violate the skill's NewFiles boundary. The unchanged primary UI test also remains unable to compile.
• Failure analysis: The restoration constraints prevented implementation, so the candidate remains an untested design rather than a validated fix.
• Self-review: 0 findings over an empty diff.
• Artifacts: CustomAgentLogsTmp/PRState/37548/PRAgent/try-fix/attempt-2/
• Narrative: CustomAgentLogsTmp/PRState/37548/PRAgent/try-fix-2/content.md

Aggregate Status

The bounded two-candidate budget is exhausted. Both alternatives are mechanism-level designs only; neither could be implemented or tested because the mandatory baseline script rejected the pre-existing dirty worktree and created no restoration allow-list. The PR-added ISafeAreaLayout.cs and malformed Issue33037NonShell.cs test are independent blockers. No candidate source changes remain in the worktree.

---

📝 PR Finalize — Recommended Title & Description

Assessment: ✏️ Recommend updating — the title can name NavigationPage more precisely, and the current description incorrectly presents stale successful test/CI claims even though the submitted HEAD's added UI-test source does not compile.

Recommended title

[iOS] NavigationPage: Delegate large-title safe area to scroll content

Recommended description

## Description

Fixes the remaining non-Shell large-title transition reported in #33037 on iOS 26.

A root MAUI `Layout` currently applies its `Container` safe area by physically moving nested scroll content as the navigation bar changes height. UIKit requires the active vertical scroll host to remain edge-to-edge to transition from the leading large title to the centered compact title. The bar therefore collapsed while the approximately 42pt large title remained clipped instead of becoming the native approximately 22pt compact title.

This change introduces explicit safe-area layout ownership:

- `MauiView` supplies full bounds and resolved safe-area insets through an internal `ISafeAreaLayout` contract.
- `Layout` first performs its normal safe-area arrangement, then delegates the top safe-area gap to one unambiguous vertical native `UIScrollView` by extending its frame edge-to-edge and transferring the gap to UIKit content/indicator insets.
- Inset ownership is delta-based, preserves live side/bottom and keyboard-related values, preserves relative scroll position outside active gestures, and is restored during disconnect or when eligibility changes.
- Explicit `SafeAreaEdges` remains authoritative. Ambiguous layouts retain the existing behavior rather than guessing.
- The final boundary is native UIKit capability, not a MAUI control allow-list: custom and third-party controls backed by a vertical `UIScrollView`, `UITableView`, or `UICollectionView` participate without framework-specific dependencies. A custom MAUI `View` backed directly by `UITableView` covers this path.

The old renderer-level `SetContentScrollView` investigation has been removed; this fix uses standard UIKit frames and `UIScrollView` inset APIs only.

## Eligibility safeguards

Delegation requires iOS 26+, an implicit top `Container` safe area, a visible translucent navigation bar that prefers large titles, one exclusive vertical scroll subtree, and valid overlay stacking for fixed top siblings. Hidden, transparent, horizontal, explicitly safe-area-configured, or ambiguous candidates are rejected.

## Runtime validation

Manual validation was performed on iPhone 17 Pro / iOS 26.5:

- Modal nested `ListView`: leading large title collapses to a centered compact title and expands again on return to top.
- Direct/wrapped `ScrollView`, `ListView`, `TableView`, `CollectionView`, `CarouselView`, and `WebView` scenarios.
- Fixed-header and programmatic-scroll scenarios.
- Custom third-party-like MAUI `View` whose handler exposes a native `UITableView`.
- Scroll-host frame remains stable and edge-to-edge throughout the transition.
- Repeated close/reopen after scrolling does not crash.

### Original nested scenario

| Expanded | Collapsed |
|---|---|
| ![Expanded large title](https://github.com/user-attachments/assets/71a53518-906e-4555-91b0-8f9c0e985d51) | ![Centered compact title](https://github.com/user-attachments/assets/1189ae7f-468f-4c79-8370-f42521918f91) |

### Custom native-scroll control

| Expanded | Collapsed |
|---|---|
| ![Custom native UITableView with expanded title](https://github.com/user-attachments/assets/19555321-918e-4cdc-b96d-222d7fd1e927) | ![Custom native UITableView with compact title](https://github.com/user-attachments/assets/7f13ce3d-4977-4717-b5c1-2ae622f5bf48) |

## Automated test status

The submitted HEAD adds focused `Issue33037NonShell` iOS UI scenarios, but the test file currently has malformed nested `try` blocks and does not compile (`CS1524`/`CS0106`). The trusted Gate therefore did not reach runtime validation, and the current `maui-pr`/Build Analysis checks must not be described as passing.

> [!NOTE]
> This remains a draft architectural spike for maintainer review of the new safe-area ownership contract.

---

🏁 Report — Final Recommendation

⚠️ Final Recommendation: REQUEST CHANGES

Winner: pr-plus-reviewer

The reviewer-enhanced PR is the strongest candidate because it fixes the submitted test-compilation blocker and several concrete correctness/performance defects while retaining the only implemented mechanism. It is still not mergeable: its one permitted focused validation failed 11 of 20 tests, including direct large-title regression assertions.

Candidate comparison

Rank	Candidate	Implementation	Validation	Assessment
1	pr-plus-reviewer	Submitted layout-delegation design plus one consolidated reviewer patch	Failed: 9 passed, 11 failed	Best evidence and clear improvement: the test project now builds, the keyboard hook is preserved, delegated inset transitions are idempotent/invalidated, and the managed eligibility scan is cheaper. It still fails modal ListView, candidate-selection, and programmatic WebView title-collapse assertions and leaves architectural findings unresolved.
2	pr	Submitted layout-owned frame/inset delegation	Gate failed before execution: malformed test source	Cannot be approved. The regression suite does not compile, and expert review found concrete keyboard, lifecycle/state, frame-coherency, first-layout, and hot-path risks.
3	try-fix-1	Design only: stop consuming the implicit root top safe area and retain UIKit Automatic adjustment	Blocked; not implemented or run	Architecturally simpler and avoids manual inset ownership, but it has no diff or empirical evidence and could broaden edge-to-edge behavior beyond one unambiguous scroll host.
4	try-fix-2	Design only: explicitly associate the real descendant scroll view with the iOS 26 controller top edge	Blocked; not implemented or run	Narrower in theory, but no code or test evidence exists, and prior investigation already found that scroll-view association alone did not repair compact-title geometry while the host remained below the bar.

No candidate passed the required regression validation. The two try-fix-* entries are unimplemented hypotheses and therefore cannot outrank an executable candidate, while the raw PR is strictly dominated by pr-plus-reviewer: it contains the same underlying fix but cannot compile its own tests and lacks the reviewer corrections.

Expert-review comparison

The raw PR correctly identifies the root geometric requirement, but its implementation makes UIKit's frame edge-to-edge only after managed layout has recorded a different frame. It also replaces a reactive renderer lifecycle with arrange-time polling and performs managed/native subtree discovery on a layout hot path. The consolidated candidate addresses only findings that could be corrected safely in one bounded patch; it records the remaining uncertainty rather than claiming completion.

The failed focused run is decisive. In particular:

• ModalListViewLargeTitleRemainsVisibleAfterScrollRoundTrip retained a 54pt title where the test requires the compact title to be under 30pt.
• Candidate-selection and programmatic-WebView scenarios did not collapse their titles.
• Several later scenarios timed out after navigation cleanup could no longer find expected elements, so their individual production-code attribution is uncertain.
• A Grid visual baseline differed by 5.26%, which may be expected visual drift or a regression, but was not investigated under the no-iteration contract.

Required disposition

Keep the PR in draft/request-changes state. pr-plus-reviewer is the winner for comparison purposes, not a merge recommendation; the submitted PR must incorporate an improved fix and obtain passing focused regression evidence before approval.

---

🧭 Next Steps — reviewer changes required

The reviewer-enhanced candidate identified changes that are not yet in the submitted PR.

Why: The consolidated reviewer candidate fixes the submitted test-compilation blocker and several concrete keyboard, inset-state, and arrange-path defects, so it strictly improves the raw PR. It remains unfit to merge because the sole focused validation still failed 11 of 20 tests, while both try-fix alternatives were blocked design proposals with no implementation or test evidence.

Address the actionable findings in this review before merging.

[MauiBot]

⚠️ Merge Conflict Detected — This PR conflicts with its target branch inflight/current. Please rebase onto the target branch and resolve the conflicts.

[kubaflo]

Could you please resolve the merge conflicts?

[kubaflo]

Looks like this PR doesn't work - could you create a new PR

[AlleSchonWeg]

Hi @jfversluis ,
will you open a new PR? I'm ready to test so we can get a good result for maui devs.