[iOS, macOS] Shell: Fix RTL flow direction for flyout, menu cells, tab bar, and Locked flyout position

[NanthiniMahalingam]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Issues

• Flyout menu items do not update correctly for RTL direction
• Tab bar and its content do not update correctly for RTL direction
• When flyout behavior is in locked state, flyout X position is not aligned correctly for RTL direction

Root Cause

• Flow direction is not set for menu item cells of UITableViewCell, flyout header, footer, tab bar items and their content
• Flyout X position is incorrectly calculated in flyout locked state for right-to-left direction

Description of Changes

• Ensured that Shell flyout headers and footers inherit the parent Shell's FlowDirection when set to MatchParent, and applied the flow direction to their platform views
• Updated the flow direction for Shell section views, navigation bars, and tab bars to respect the Shell's flow direction, including handling cases where tab bar items are present
• Modified ShellTableViewSource to inherit flow direction from Shell for menu item cells when set to MatchParent, and applied the correct flow direction to the platform view
• Adjusted flyout positioning logic in RTL mode to correctly handle the Locked flyout behavior

Validated the behaviour in the following platforms

• Android
• Windows ,
• iOS,
• MacOS

Issues Fixed

Fixes #32419

Output

iOS

Before	After
Issue_32419_iOS_before.mov	Issue_32419_iOS_after.mov

macOS

Before	After
Issue_32419_mac_before.mov	Issue_32419_mac_after.mov

[sheiksyedm]

/rebase

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Added the output snapshots · 8612998

---

Issue: #32419 - [iOS, Mac Catalyst] Shell Flyout and Content Do Not Fully Support RightToLeft (RTL)
PR: #32701 - [iOS, macOS] Fixed Shell menu and flyout items do not update correctly in RTL mode
Status: DRAFT PR
Author: NanthiniMahalingam
Platforms Affected: iOS, macOS
Files Changed: 5 implementation files, 2 test files, 6 snapshot images

Issue Summary

When FlowDirection="RightToLeft" is set on a Shell, two problems occur on iOS/macOS:

1. Content Layout Issue: Only Shell navigation elements (hamburger icon) respect RTL; page content (Labels, etc.) continues rendering LTR.
2. Flyout Locked State Issue: When FlyoutBehavior="Locked" with RTL, the flyout X position is miscalculated, causing incorrect alignment.

Files Changed

Fix Files (iOS implementation):

• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellFlyoutContentRenderer.cs (+18) - Apply flow direction to header and footer views
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellSectionRenderer.cs (+5) - Update flow direction for tab bar when tab bar items present
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellSectionRootRenderer.cs (+10) - Propagate flow direction to tracker page
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellTableViewSource.cs (+14) - Apply flow direction to flyout menu item cells
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/SlideFlyoutTransition.cs (+6) - Fix flyout X position for Locked behavior in RTL

Test Files:

• src/Controls/tests/TestCases.HostApp/Issues/Issue32419.cs (+99) - UI test host page
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32419.cs (+32) - NUnit screenshot tests

Snapshot Images:

• iOS: VerifyShellFlyoutContentAlignedInRTL.png, VerifyShellMenuItemsAlignedInRTL.png, ShellFlowDirectionUpdate.png
• Android: VerifyShellFlyoutContentAlignedInRTL.png, VerifyShellMenuItemsAlignedInRTL.png
• Windows: VerifyShellFlyoutContentAlignedInRTL.png, VerifyShellMenuItemsAlignedInRTL.png, ShellFlowDirectionUpdate.png

PR Discussion

• 1 comment: /rebase from sheiksyedm (Dec 30, 2025) - maintenance comment
• No reviewer feedback or inline comments

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #32701	Propagate Shell FlowDirection to header/footer/tabbar/cells via UpdateFlowDirection; fix Locked flyout X PENDING (Gate)	5 files (+53 lines)	Original PR, DRAFT status	pos

---

🚦 Gate — Test Verification

---

📝 Review Session — Added the output snapshots · 8612998

---

Result PASSED:
Platform: ios
Mode: Full Verification

• Tests FAIL without fix
• Tests PASS with fix

Test Filter: Issue32419
Tests: VerifyShellFlyoutContentAlignedInRTL, VerifyShellMenuItemsAlignedInRTL
Blockers: None

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Added the output snapshots · 8612998

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-sonnet-4.5)	Set UISemanticContentAttribute directly on native UIViews (headers, footers, cells, FAIL	4 files	Why: Bypassing MAUI FlowDirection system loses layout invalidation and recursive propagation	tabbar)
2	try-fix (claude-opus-4.6)	Container-level RTL propagation: SemanticContentAttribute on container views + FlowDirection on tracked pages/cell views + Locked flyout fix PASS	5 files	Works but mixes MAUI and native approaches
3	try-fix (gpt-5.2-codex)	Apply UpdateFlowDirection to root platform views + reload table without mutating FlowDirection FAIL	3 files	Why: Missing key insight - MatchParent resolution fails because Shell items' MAUI parent chain doesn't connect to Shell's native view	values
PR	PR #32701	Propagate Shell FlowDirection to header/footer/tabbar/cells via UpdateFlowDirection calls; fix Locked flyout X pos by positionX=shellWidth PASS (Gate)	5 files	Original PR - idiomatic MAUI approach

Skipped models (rate-limited): gpt-5.2, gemini-3-pro-preview, gpt-5.1-codex (429 Too Many Requests after retry)

Cross-Pollination Results

Model	Round 2 Response
claude-sonnet-4.5	NEW IDEA: Coordinate mirroring - intercept Frame/Bounds in renderers to mirror X coords (complex/risky, not pursued)
claude-opus-4.6	NO NEW IDEAS - correctly identifies all approaches exhausted
gpt-5.2	SKIPPED (rate-limited)
gpt-5.2-codex	SKIPPED (rate-limited)
gemini-3-pro-preview	SKIPPED (rate-limited)

Exhausted: Yes (available models confirmed exhaustion; rate limits prevented others)

Selected Fix: PR's fix - It is simpler, cleaner, and uses the established UpdateFlowDirection pattern that is consistent with the existing codebase. Attempt #2 also passes but mixes MAUI's FlowDirection system with direct UISemanticContentAttribute manipulation, which is less maintainable. The PR's fix uses the proper MAUI abstraction.

Root Cause: Shell sub-elements (header, footer, cells, tracked pages) have a disconnected MAUI visual tree that prevents MatchParent FlowDirection resolution from propagating the Shell's RTL setting. Additionally, the SlideFlyoutTransition incorrectly calculated the flyout X position in Locked mode for RTL.

---

📋 Report — Final Recommendation

---

📝 Review Session — Added the output snapshots · 8612998

---

Final Recommendation: APPROVE (with comments)

Summary

PR #32701 fixes Shell RTL (Right-to-Left) layout propagation for iOS/macOS. When FlowDirection="RightToLeft" is set on a Shell, page content, flyout header/footer, tab bar items, and menu cells now correctly mirror to RTL. Additionally, the locked flyout X position calculation is fixed.

The PR's fix was validated by Gate (tests FAIL without fix, PASS with fix on iOS). An independent alternative (Attempt #2) also passed, but the PR's approach is more idiomatic to the MAUI codebase.

Root Cause

Shell sub-elements (header, footer, cells, tracked pages, tab bar) have a disconnected MAUI visual tree. When these elements have FlowDirection=MatchParent, the MatchParent resolution cannot traverse up to the Shell's flow direction because their parent chain is broken in the compatibility renderer layer. As a result, UpdateFlowDirection calls on these elements would not propagate the Shell's RTL setting.

Additionally, SlideFlyoutTransition.LayoutViews calculated positionX = shellWidth - openPixels for RTL, which is correct for the Flyout behavior but incorrect for Locked behavior where openPixels = flyoutWidth gives positionX = shellWidth - flyoutWidth (off by one "flyout width" unit).

Fix Quality Assessment

The PR's approach is clean and consistent with the existing UpdateFlowDirection pattern in the codebase:

• Extends existing UpdateFlowDirection() calls to cover flyout header/footer, tab bar, and cells
• Resolves the MatchParent disconnection by explicitly setting FlowDirection before calling UpdateFlowDirection
• Fixes the Locked flyout position with a minimal targeted check

---

Title/Description Review

Current Title: [iOS, macOS] Fixed Shell menu and flyout items do not update correctly in RTL mode

Recommended Title: [iOS, macOS] Shell: Fix RTL layout propagation for flyout, tab bar, and menu cells

Reasons:

• Use present-tense verb form ("Fix" not "Fixed")
• More descriptive of what changed

Description Needs improvementsAssessment:

• Missing NOTE block at (actually has it) top
• Good description of changes
• Missing root cause explanation
• PR is marked as DRAFT

---

Code Review Findings

1. FlowDirection mutation on MAUI elements (Medium)
In ShellFlyoutContentRenderer.cs, ShellSectionRootRenderer.cs, and ShellTableViewSource.cs, the code permanently mutates the element's FlowDirection from MatchParent to the Shell's direction:

if (header.FlowDirection == FlowDirection.MatchParent)
{
    header.FlowDirection = _shellContext.Shell.FlowDirection;
}

This is a one-way change. If Shell's FlowDirection later changes (e.g., dynamically switched from RTL to LTR), these elements won't revert to MatchParent and won't pick up the new direction. Consider whether this is intentional given the Shell architecture, or whether a non-destructive approach (e.g., storing original value) is needed.

2. Missing test to open flyout and verify menu items (Medium)
VerifyShellFlyoutContentAlignedInRTL takes a screenshot of the home page without opening the flyout. This verifies the navigation bar alignment but NOT the flyout menu item alignment. The issue specifically reports flyout item alignment problems. Consider adding a test that:

• Opens the flyout (taps the hamburger/flyout button)
• Verifies the flyout items are correctly right-aligned

3. SlideFlyoutTransition locked position comment missing (Low)

if (behavior == FlyoutBehavior.Locked)
{
    positionX = shellWidth;
}

The value shellWidth is not immediately obvious as the correct value for RTL locked mode. A comment explaining why this is correct (e.g., "In RTL with ForceRightToLeft, iOS mirrors coordinates so the flyout appears at the left edge") would help maintainers understand this.

4. Missing newline at end of file (Low)
TestCases.HostApp/Issues/Issue32419.cs is missing a newline at the end of file (the diff shows \ No newline at end of file).

Looks Good

• Implementation follows the established UpdateFlowDirection pattern consistently
• ShellSectionRenderer.cs change correctly guards with TabBarItem is not null && TabBarController?.TabBar is not null
• ShellTableViewSource.cs correctly handles both the MAUI FlowDirection and the native platform view
• Test structure uses TestShell, [Category(UITestCategories.Shell)], and VerifyScreenshot() correctly
• Snapshot baselines provided for iOS, Android, and Windows

---

Fix Candidates Summary

#	Source	Approach	Test Result
1	try-fix	UISemanticContentAttribute directly on native FAIL	views
2	try-fix	Container-level SemanticContentAttribute + FlowDirection on pages/cells PASS
3	try-fix	UpdateFlowDirection on root views without FlowDirection FAIL	mutation
PR	PR #32701	UpdateFlowDirection extensions with MatchParent resolution PASS (Gate)

Selected Fix: PR's fix - more idiomatic to MAUI codebase, uses established UpdateFlowDirection pattern

What NOT to Do (for future agents)

Don't set UISemanticContentAttribute only - Without MAUI's FlowDirection system, child views won't get proper layout invalidation-
Don't call UpdateFlowDirection on root views without resolving MatchParent - Shell sub-elements have disconnected visual trees; MatchParent resolution fails without explicit propagation-
Don't use bounds.Width in RTL flyout positioning - It gives the same result as shellWidth; the fix correctly uses shellWidth directly-

Draft Status

This PR is currently marked as DRAFT. Before merging, the author should address:

1. The FlowDirection mutation concern ([Draft] Readme WIP #1 above)
2. The missing flyout-open test (Update README.md #2 above)
3. The trailing newline in test file (Aloha System.Maui! #4 above)
4. Mark PR as ready for review

---

📋 Expand PR Finalization Review

---

Title: ⚠️ Needs Update

Current: [iOS, macOS] Fixed Shell menu and flyout items do not update correctly in RTL mode

Issues:

• Uses "Fixed" verb prefix — titles should describe the fix, not the bug
• Phrase "do not update correctly" describes the broken behavior rather than the solution
• Verbose; can be made more scannable

Recommended: [iOS, macOS] Shell: Fix RTL flow direction for flyout, menu cells, tab bar, and Locked flyout position

Description: ✅ Good

• Uses "Fixed" verb prefix — titles should describe the fix, not the bug
• Phrase "do not update correctly" describes the broken behavior rather than the solution
• Verbose; can be made more scannable

✨ Suggested PR Description

[!NOTE]
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Root Cause

• Shell flyout headers, footers, and menu item cells (UITableViewCell) were not propagating the Shell's FlowDirection to their platform views. When FlowDirection was set to MatchParent, the underlying UIKit views never received the resolved (Right-to-Left) direction.
• The TabBar within a ShellSectionRenderer was not updated when UpdateFlowDirection was called, so tab bar items remained in the default LTR layout.
• In ShellSectionRootRenderer, the tracked page's FlowDirection was not resolved when set to MatchParent, leaving page content in LTR layout.
• SlideFlyoutTransition.LayoutViews computed the flyout's X position using shellWidth - openPixels, which is correct for the sliding flyout case, but incorrect when FlyoutBehavior.Locked is used in RTL mode, resulting in a misaligned flyout.

Description of Change

ShellFlyoutContentRenderer.cs

• In UpdateFlyoutHeader: when the header view's FlowDirection is MatchParent, it is now resolved to the Shell's FlowDirection before UpdateFlowDirection is called on the header's platform view.
• In UpdateFlyoutFooter: same fix applied to the footer view.

ShellSectionRenderer.cs

• In UpdateFlowDirection: added propagation to TabBarController.TabBar when a TabBarItem is present, ensuring the tab bar is mirrored in RTL.

ShellSectionRootRenderer.cs

• In UpdateFlowDirection: when the current section is active, if the tracked page's FlowDirection is MatchParent, it is resolved to the Shell's concrete flow direction before the view update, ensuring page content renders in the correct direction.

ShellTableViewSource.cs

• In GetCell: when the cell's View.FlowDirection is MatchParent, it is resolved to the Shell's FlowDirection. The resolved direction is then applied to the cell's platform UIView via UpdateFlowDirection.

SlideFlyoutTransition.cs

• In LayoutViews: for RTL (ForceRightToLeft), when FlyoutBehavior.Locked is active, the flyout X position is set to shellWidth so the flyout is correctly anchored at the trailing edge in RTL layout.

Issues Fixed

Fixes #32419

Platforms Tested

• Android
• Windows
• iOS
• macOS (Mac Catalyst)

Output

⚠️ Before/After screenshots were not included in the original PR. Please add them to the Output section for reviewer context.

iOS

Before	After
Add screenshot	Add screenshot

macOS

Before	After
Add screenshot	Add screenshot

Code Review: ⚠️ Issues Found

Code Review — PR #32701

PR: #32701 - [iOS, macOS] Shell RTL Flow Direction Fix

---

🔴 Critical Issues

1. SlideFlyoutTransition.cs: Locked RTL flyout X position may place flyout off-screen

File: src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/SlideFlyoutTransition.cs

Problem:

// RTL branch
var positionX = shellWidth - openPixels;

if (behavior == FlyoutBehavior.Locked)
{
    positionX = shellWidth;  // ← places flyout at x = shellWidth (right edge / off-screen)
}

flyout.Frame = new CGRect(positionX, 0, flyoutWidth, flyoutHeight);

Setting positionX = shellWidth positions the flyout's leading edge at shellWidth — entirely off-screen to the right in iOS screen coordinates (origin is top-left). The fix resolves the previously reported misalignment, and this is the author's stated intent, but the chosen value is surprising.

Expected behavior for RTL Locked:
In RTL mode, the flyout should appear anchored to the right side of the screen, visible to the user. The correct value depends on whether openPixels equals flyoutWidth in the Locked state. If openPercent is always 1.0 for Locked, then positionX = shellWidth - openPixels = shellWidth - flyoutWidth, which would correctly anchor the flyout at the right. Setting it to shellWidth (without subtracting flyoutWidth) would put it one flyout-width off-screen.

Recommendation:
Verify with a device/simulator that this value is correct (the author's before/after screenshots would confirm). If openPercent is something other than 1.0 for Locked, document why shellWidth is the right value. Consider adding a comment explaining the geometry.

---

🟡 Suggestions

1. Mutating FlowDirection from MatchParent to a concrete value is permanent and won't re-resolve on Shell FlowDirection change

Files:

• ShellFlyoutContentRenderer.cs (header and footer)
• ShellSectionRootRenderer.cs
• ShellTableViewSource.cs

Pattern:

if (view.FlowDirection == FlowDirection.MatchParent)
{
    view.FlowDirection = _shellContext.Shell.FlowDirection;  // ← permanent mutation
}

This overwrites the element's FlowDirection from MatchParent to a concrete value (e.g., RightToLeft). If the Shell's FlowDirection changes dynamically at runtime, these views won't re-resolve — they'll be stuck with the first resolved value. MatchParent is a sentinel/lazy value and should ideally be preserved so subsequent UpdateFlowDirection calls can re-resolve it.

Note: This pattern does appear in other places in the iOS Shell renderer codebase, so this PR is consistent with existing patterns. However, the underlying fragility should be acknowledged.

Recommendation: Consider whether this is acceptable given current usage patterns, or whether a non-mutating resolution (reading Shell's direction without writing it back to the element) would be safer.

---

2. ShellTableViewSource.GetCell: Flow direction applied on every GetCell call (including reused cells)

File: src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellTableViewSource.cs

Problem:

public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
{
    // ...
    if (cell.View.FlowDirection == FlowDirection.MatchParent)
    {
        cell.View.FlowDirection = _context.Shell.FlowDirection;
    }
    if (cell.View.Handler?.PlatformView is UIView platformView)
    {
        platformView.UpdateFlowDirection(cell.View);
    }
    // ...
}

GetCell is called every time a cell is requested (including dequeued/reused cells). Since FlowDirection has already been overwritten from MatchParent to a concrete value on first use, the MatchParent guard won't fire on subsequent reuse — meaning UpdateFlowDirection will be called on every GetCell. This is not harmful (idempotent) but is a minor inefficiency.

Recommendation: No action required if behavior is correct. Low priority.

---

3. Issue32419.cs UI Test — Missing wait after tapping Locked button before screenshot

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32419.cs

Problem:

[Test, Order(2)]
[Category(UITestCategories.Shell)]
public void VerifyShellMenuItemsAlignedInRTL()
{
    App.WaitForElement("homePageLabel");
    App.Tap("FlyoutLockedButton");
    VerifyScreenshot();  // ← no wait after layout change
}

After tapping FlyoutLockedButton, Shell.SetFlyoutBehavior(this, FlyoutBehavior.Locked) triggers a layout change. If the screenshot is taken before the layout settles, this test may be flaky.

Recommendation: Use VerifyScreenshot(retryTimeout: TimeSpan.FromSeconds(2)) to allow the layout to settle:

App.Tap("FlyoutLockedButton");
VerifyScreenshot(retryTimeout: TimeSpan.FromSeconds(2));

---

✅ Looks Good

• ShellSectionRenderer.cs — TabBar flow direction propagation is guarded with both TabBarItem is not null and TabBarController?.TabBar is not null null checks. Clean and safe.
• ShellFlyoutContentRenderer.cs — The refactoring to add braces around the single-line if for the header is not null case is a good readability improvement that avoids future single-line if bugs.
• Test coverage — New Issue32419.cs HostApp page and test class are well-structured, use TestShell base class correctly, and snapshot files are provided for iOS, Android, and Windows platforms.

---

[Vignesh-SF3580]

🤖 AI Summary

📊 Expand Full Review
🔍 Pre-Flight — Context & Validation
📝 Review Session — Added the output snapshots · 8612998
Issue: #32419 - [iOS, Mac Catalyst] Shell Flyout and Content Do Not Fully Support RightToLeft (RTL) PR: #32701 - [iOS, macOS] Fixed Shell menu and flyout items do not update correctly in RTL mode Status: DRAFT PR Author: NanthiniMahalingam Platforms Affected: iOS, macOS Files Changed: 5 implementation files, 2 test files, 6 snapshot images

Issue Summary

When FlowDirection="RightToLeft" is set on a Shell, two problems occur on iOS/macOS:

1. Content Layout Issue: Only Shell navigation elements (hamburger icon) respect RTL; page content (Labels, etc.) continues rendering LTR.
2. Flyout Locked State Issue: When FlyoutBehavior="Locked" with RTL, the flyout X position is miscalculated, causing incorrect alignment.

Files Changed

Fix Files (iOS implementation):

• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellFlyoutContentRenderer.cs (+18) - Apply flow direction to header and footer views
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellSectionRenderer.cs (+5) - Update flow direction for tab bar when tab bar items present
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellSectionRootRenderer.cs (+10) - Propagate flow direction to tracker page
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellTableViewSource.cs (+14) - Apply flow direction to flyout menu item cells
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/SlideFlyoutTransition.cs (+6) - Fix flyout X position for Locked behavior in RTL

Test Files:

• src/Controls/tests/TestCases.HostApp/Issues/Issue32419.cs (+99) - UI test host page
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32419.cs (+32) - NUnit screenshot tests

Snapshot Images:

• iOS: VerifyShellFlyoutContentAlignedInRTL.png, VerifyShellMenuItemsAlignedInRTL.png, ShellFlowDirectionUpdate.png
• Android: VerifyShellFlyoutContentAlignedInRTL.png, VerifyShellMenuItemsAlignedInRTL.png
• Windows: VerifyShellFlyoutContentAlignedInRTL.png, VerifyShellMenuItemsAlignedInRTL.png, ShellFlowDirectionUpdate.png

PR Discussion

• 1 comment: /rebase from sheiksyedm (Dec 30, 2025) - maintenance comment
• No reviewer feedback or inline comments

Fix Candidates

Source Approach Test Result Files Changed Notes

PR PR #32701 Propagate Shell FlowDirection to header/footer/tabbar/cells via UpdateFlowDirection; fix Locked flyout X PENDING (Gate) 5 files (+53 lines) Original PR, DRAFT status pos
🚦 Gate — Test Verification
📝 Review Session — Added the output snapshots · 8612998
Result PASSED: Platform: ios Mode: Full Verification

• Tests FAIL without fix
• Tests PASS with fix

Test Filter: Issue32419 Tests: VerifyShellFlyoutContentAlignedInRTL, VerifyShellMenuItemsAlignedInRTL Blockers: None

🔧 Fix — Analysis & Comparison
📝 Review Session — Added the output snapshots · 8612998

Fix Candidates

Source Approach Test Result Files Changed Notes

1 try-fix (claude-sonnet-4.5) Set UISemanticContentAttribute directly on native UIViews (headers, footers, cells, FAIL 4 files Why: Bypassing MAUI FlowDirection system loses layout invalidation and recursive propagation tabbar)
2 try-fix (claude-opus-4.6) Container-level RTL propagation: SemanticContentAttribute on container views + FlowDirection on tracked pages/cell views + Locked flyout fix PASS 5 files Works but mixes MAUI and native approaches
3 try-fix (gpt-5.2-codex) Apply UpdateFlowDirection to root platform views + reload table without mutating FlowDirection FAIL 3 files Why: Missing key insight - MatchParent resolution fails because Shell items' MAUI parent chain doesn't connect to Shell's native view values
PR PR #32701 Propagate Shell FlowDirection to header/footer/tabbar/cells via UpdateFlowDirection calls; fix Locked flyout X pos by positionX=shellWidth PASS (Gate) 5 files Original PR - idiomatic MAUI approach
Skipped models (rate-limited): gpt-5.2, gemini-3-pro-preview, gpt-5.1-codex (429 Too Many Requests after retry)

Cross-Pollination Results

Model Round 2 Response
claude-sonnet-4.5 NEW IDEA: Coordinate mirroring - intercept Frame/Bounds in renderers to mirror X coords (complex/risky, not pursued)
claude-opus-4.6 NO NEW IDEAS - correctly identifies all approaches exhausted
gpt-5.2 SKIPPED (rate-limited)
gpt-5.2-codex SKIPPED (rate-limited)
gemini-3-pro-preview SKIPPED (rate-limited)
Exhausted: Yes (available models confirmed exhaustion; rate limits prevented others)

Selected Fix: PR's fix - It is simpler, cleaner, and uses the established UpdateFlowDirection pattern that is consistent with the existing codebase. Attempt #2 also passes but mixes MAUI's FlowDirection system with direct UISemanticContentAttribute manipulation, which is less maintainable. The PR's fix uses the proper MAUI abstraction.

Root Cause: Shell sub-elements (header, footer, cells, tracked pages) have a disconnected MAUI visual tree that prevents MatchParent FlowDirection resolution from propagating the Shell's RTL setting. Additionally, the SlideFlyoutTransition incorrectly calculated the flyout X position in Locked mode for RTL.

📋 Report — Final Recommendation
📝 Review Session — Added the output snapshots · 8612998

Final Recommendation: APPROVE (with comments)

Summary

PR #32701 fixes Shell RTL (Right-to-Left) layout propagation for iOS/macOS. When FlowDirection="RightToLeft" is set on a Shell, page content, flyout header/footer, tab bar items, and menu cells now correctly mirror to RTL. Additionally, the locked flyout X position calculation is fixed.

The PR's fix was validated by Gate (tests FAIL without fix, PASS with fix on iOS). An independent alternative (Attempt #2) also passed, but the PR's approach is more idiomatic to the MAUI codebase.

Root Cause

Shell sub-elements (header, footer, cells, tracked pages, tab bar) have a disconnected MAUI visual tree. When these elements have FlowDirection=MatchParent, the MatchParent resolution cannot traverse up to the Shell's flow direction because their parent chain is broken in the compatibility renderer layer. As a result, UpdateFlowDirection calls on these elements would not propagate the Shell's RTL setting.

Additionally, SlideFlyoutTransition.LayoutViews calculated positionX = shellWidth - openPixels for RTL, which is correct for the Flyout behavior but incorrect for Locked behavior where openPixels = flyoutWidth gives positionX = shellWidth - flyoutWidth (off by one "flyout width" unit).

Fix Quality Assessment

The PR's approach is clean and consistent with the existing UpdateFlowDirection pattern in the codebase:

• Extends existing UpdateFlowDirection() calls to cover flyout header/footer, tab bar, and cells
• Resolves the MatchParent disconnection by explicitly setting FlowDirection before calling UpdateFlowDirection
• Fixes the Locked flyout position with a minimal targeted check

Title/Description Review

Current Title: [iOS, macOS] Fixed Shell menu and flyout items do not update correctly in RTL mode

Recommended Title: [iOS, macOS] Shell: Fix RTL layout propagation for flyout, tab bar, and menu cells

Reasons:

• Use present-tense verb form ("Fix" not "Fixed")
• More descriptive of what changed

Description Needs improvementsAssessment:

• Missing NOTE block at (actually has it) top
• Good description of changes
• Missing root cause explanation
• PR is marked as DRAFT

Code Review Findings

1. FlowDirection mutation on MAUI elements (Medium) In ShellFlyoutContentRenderer.cs, ShellSectionRootRenderer.cs, and ShellTableViewSource.cs, the code permanently mutates the element's FlowDirection from MatchParent to the Shell's direction:

if (header.FlowDirection == FlowDirection.MatchParent)
{
    header.FlowDirection = _shellContext.Shell.FlowDirection;
}

This is a one-way change. If Shell's FlowDirection later changes (e.g., dynamically switched from RTL to LTR), these elements won't revert to MatchParent and won't pick up the new direction. Consider whether this is intentional given the Shell architecture, or whether a non-destructive approach (e.g., storing original value) is needed.

2. Missing test to open flyout and verify menu items (Medium) VerifyShellFlyoutContentAlignedInRTL takes a screenshot of the home page without opening the flyout. This verifies the navigation bar alignment but NOT the flyout menu item alignment. The issue specifically reports flyout item alignment problems. Consider adding a test that:

• Opens the flyout (taps the hamburger/flyout button)
• Verifies the flyout items are correctly right-aligned

3. SlideFlyoutTransition locked position comment missing (Low)

if (behavior == FlyoutBehavior.Locked)
{
    positionX = shellWidth;
}

The value shellWidth is not immediately obvious as the correct value for RTL locked mode. A comment explaining why this is correct (e.g., "In RTL with ForceRightToLeft, iOS mirrors coordinates so the flyout appears at the left edge") would help maintainers understand this.

4. Missing newline at end of file (Low) TestCases.HostApp/Issues/Issue32419.cs is missing a newline at the end of file (the diff shows \ No newline at end of file).

Looks Good

• Implementation follows the established UpdateFlowDirection pattern consistently
• ShellSectionRenderer.cs change correctly guards with TabBarItem is not null && TabBarController?.TabBar is not null
• ShellTableViewSource.cs correctly handles both the MAUI FlowDirection and the native platform view
• Test structure uses TestShell, [Category(UITestCategories.Shell)], and VerifyScreenshot() correctly
• Snapshot baselines provided for iOS, Android, and Windows

Fix Candidates Summary

Source Approach Test Result

1 try-fix UISemanticContentAttribute directly on native FAIL views
2 try-fix Container-level SemanticContentAttribute + FlowDirection on pages/cells PASS
3 try-fix UpdateFlowDirection on root views without FlowDirection FAIL mutation
PR PR #32701 UpdateFlowDirection extensions with MatchParent resolution PASS (Gate)
Selected Fix: PR's fix - more idiomatic to MAUI codebase, uses established UpdateFlowDirection pattern

What NOT to Do (for future agents)

Don't set UISemanticContentAttribute only - Without MAUI's FlowDirection system, child views won't get proper layout invalidation- Don't call UpdateFlowDirection on root views without resolving MatchParent - Shell sub-elements have disconnected visual trees; MatchParent resolution fails without explicit propagation- Don't use bounds.Width in RTL flyout positioning - It gives the same result as shellWidth; the fix correctly uses shellWidth directly-

Draft Status

This PR is currently marked as DRAFT. Before merging, the author should address:

1. The FlowDirection mutation concern ([Draft] Readme WIP #1 above)
2. The missing flyout-open test (Update README.md #2 above)
3. The trailing newline in test file (Aloha System.Maui! #4 above)
4. Mark PR as ready for review

📋 Expand PR Finalization Review

I’ve updated PR title and addressed the valid suggestions by adding comments in the relevant places. There are no major concerns with the remaining comments.

[MauiBot]

🚦 Gate - Test Before and After Fix

📊 Expand Full Gate — 584278b · addressed copilot comments.

---

Gate Result: ✅ PASSED

Platform: IOS · Base: main · Merge base: 720a9d4a

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🖥️ Issue32419 Issue32419	✅ FAIL — 281s	✅ PASS — 93s

🔴 Without fix — 🖥️ Issue32419: FAIL ✅ · 281s

  Determining projects to restore...
  Restored /Users/cloudtest/vss/_work/1/s/src/Graphics/src/Graphics/Graphics.csproj (in 655 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/src/BindingSourceGen/Controls.BindingSourceGen.csproj (in 655 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Essentials/src/Essentials.csproj (in 5.3 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Core/src/Core.csproj (in 5.78 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/src/Core/Controls.Core.csproj (in 6.49 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/src/Xaml/Controls.Xaml.csproj (in 6.49 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj (in 6.5 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/BlazorWebView/src/Maui/Microsoft.AspNetCore.Components.WebView.Maui.csproj (in 6.5 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/Foldable/src/Controls.Foldable.csproj (in 6.52 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/Maps/src/Controls.Maps.csproj (in 6.54 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Core/maps/src/Maps.csproj (in 6.55 sec).
/Users/cloudtest/vss/_work/1/s/.dotnet/packs/Microsoft.iOS.Sdk.net10.0_26.0/26.0.11017/targets/Xamarin.Shared.Sdk.targets(309,3): warning : RuntimeIdentifier was set on the command line, and will override the value for RuntimeIdentifiers set in the project file. [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-ios]
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Graphics -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Graphics/Debug/net10.0-ios26.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Essentials -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Essentials/Debug/net10.0-ios26.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Core/Debug/net10.0-ios26.0/Microsoft.Maui.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Maps -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Maps/Debug/net10.0-ios26.0/Microsoft.Maui.Maps.dll
  Controls.BindingSourceGen -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Controls.Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Core/Debug/net10.0-ios26.0/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Microsoft.AspNetCore.Components.WebView.Maui -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Microsoft.AspNetCore.Components.WebView.Maui/Debug/net10.0-ios26.0/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Xaml -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Xaml/Debug/net10.0-ios26.0/Microsoft.Maui.Controls.Xaml.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Controls.Foldable -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Foldable/Debug/net10.0-ios26.0/Microsoft.Maui.Controls.Foldable.dll
  Controls.Maps -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Maps/Debug/net10.0-ios26.0/Microsoft.Maui.Controls.Maps.dll
  Detected signing identity:
    Code Signing Key: "" (-)
    Provisioning Profile: "" () - no entitlements
    Bundle Id: com.microsoft.maui.uitests
    App Id: com.microsoft.maui.uitests
  Controls.TestCases.HostApp -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-ios/iossimulator-arm64/Controls.TestCases.HostApp.dll
  Optimizing assemblies for size may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
  Optimizing assemblies for size. This process might take a while.

Build succeeded.

/Users/cloudtest/vss/_work/1/s/.dotnet/packs/Microsoft.iOS.Sdk.net10.0_26.0/26.0.11017/targets/Xamarin.Shared.Sdk.targets(309,3): warning : RuntimeIdentifier was set on the command line, and will override the value for RuntimeIdentifiers set in the project file. [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-ios]
    1 Warning(s)
    0 Error(s)

Time Elapsed 00:02:32.05
  Determining projects to restore...
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/tests/CustomAttributes/Controls.CustomAttributes.csproj (in 1.22 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/src/BindingSourceGen/Controls.BindingSourceGen.csproj (in 1.22 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/TestUtils/src/VisualTestUtils/VisualTestUtils.csproj (in 2 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/TestUtils/src/UITest.Core/UITest.Core.csproj (in 2 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Graphics/src/Graphics/Graphics.csproj (in 1.59 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Essentials/src/Essentials.csproj (in 358 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/src/Core/Controls.Core.csproj (in 1.77 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/TestUtils/src/UITest.NUnit/UITest.NUnit.csproj (in 1.79 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Core/src/Core.csproj (in 498 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/TestUtils/src/UITest.Appium/UITest.Appium.csproj (in 2.56 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/TestUtils/src/VisualTestUtils.MagickNet/VisualTestUtils.MagickNet.csproj (in 4.16 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.iOS.Tests/Controls.TestCases.iOS.Tests.csproj (in 4.31 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/TestUtils/src/UITest.Analyzers/UITest.Analyzers.csproj (in 4.48 sec).
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Controls.CustomAttributes -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.CustomAttributes/Debug/net10.0/Controls.CustomAttributes.dll
  Graphics -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Essentials -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Controls.Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  UITest.Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/UITest.Core/Debug/net10.0/UITest.Core.dll
  VisualTestUtils -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/VisualTestUtils/Debug/netstandard2.0/VisualTestUtils.dll
  VisualTestUtils.MagickNet -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/VisualTestUtils.MagickNet/Debug/netstandard2.0/VisualTestUtils.MagickNet.dll
  UITest.NUnit -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/UITest.NUnit/Debug/net10.0/UITest.NUnit.dll
  UITest.Appium -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/UITest.Appium/Debug/net10.0/UITest.Appium.dll
  UITest.Analyzers -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/UITest.Analyzers/Debug/netstandard2.0/UITest.Analyzers.dll
  Controls.TestCases.iOS.Tests -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.iOS.Tests/Debug/net10.0/Controls.TestCases.iOS.Tests.dll
Test run for /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.iOS.Tests/Debug/net10.0/Controls.TestCases.iOS.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (arm64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.iOS.Tests/Debug/net10.0/Controls.TestCases.iOS.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.05]   Discovering: Controls.TestCases.iOS.Tests
[xUnit.net 00:00:00.13]   Discovered:  Controls.TestCases.iOS.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.iOS.Tests/Debug/net10.0/Controls.TestCases.iOS.Tests.dll
   NUnit3TestExecutor discovered 2 of 2 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 4/1/2026 7:23:10 AM FixtureSetup for Issue32419(iOS)
>>>>> 4/1/2026 7:23:13 AM VerifyShellFlyoutContentAlignedInRTL Start
>>>>> 4/1/2026 7:23:15 AM VerifyShellFlyoutContentAlignedInRTL Stop
>>>>> 4/1/2026 7:23:15 AM Log types: syslog, crashlog, performance, safariConsole, safariNetwork, server
  Failed VerifyShellFlyoutContentAlignedInRTL [1 s]
  Error Message:
   VisualTestUtils.VisualTestFailedException : 
Snapshot different than baseline: VerifyShellFlyoutContentAlignedInRTL.png (3.60% difference)
If the correct baseline has changed (this isn't a a bug), then update the baseline image.
See test attachment or download the build artifacts to get the new snapshot file.

More info: https://aka.ms/visual-test-workflow

  Stack Trace:
     at VisualTestUtils.VisualRegressionTester.Fail(String message) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 162
   at VisualTestUtils.VisualRegressionTester.VerifyMatchesSnapshot(String name, ImageSnapshot actualImage, String environmentName, ITestContext testContext) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 123
   at Microsoft.Maui.TestCases.Tests.UITest.<VerifyScreenshot>g__Verify|13_0(String name, <>c__DisplayClass13_0&) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 477
   at Microsoft.Maui.TestCases.Tests.UITest.VerifyScreenshot(String name, Nullable`1 retryDelay, Nullable`1 retryTimeout, Int32 cropLeft, Int32 cropRight, Int32 cropTop, Int32 cropBottom, Double tolerance) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 309
   at Microsoft.Maui.TestCases.Tests.Issues.Issue32419.VerifyShellFlyoutContentAlignedInRTL() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32419.cs:line 20
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

>>>>> 4/1/2026 7:23:15 AM VerifyShellMenuItemsAlignedInRTL Start
>>>>> 4/1/2026 7:23:18 AM VerifyShellMenuItemsAlignedInRTL Stop
>>>>> 4/1/2026 7:23:18 AM Log types: syslog, crashlog, performance, safariConsole, safariNetwork, server
  Failed VerifyShellMenuItemsAlignedInRTL [3 s]
  Error Message:
   VisualTestUtils.VisualTestFailedException : 
Snapshot different than baseline: VerifyShellMenuItemsAlignedInRTL.png (8.28% difference)
If the correct baseline has changed (this isn't a a bug), then update the baseline image.
See test attachment or download the build artifacts to get the new snapshot file.

More info: https://aka.ms/visual-test-workflow

  Stack Trace:
     at Microsoft.Maui.TestCases.Tests.UITest.VerifyScreenshot(String name, Nullable`1 retryDelay, Nullable`1 retryTimeout, Int32 cropLeft, Int32 cropRight, Int32 cropTop, Int32 cropBottom, Double tolerance) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 296
   at Microsoft.Maui.TestCases.Tests.Issues.Issue32419.VerifyShellMenuItemsAlignedInRTL() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32419.cs:line 30
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

NUnit Adapter 4.5.0.0: Test execution complete

Total tests: 2
     Failed: 2
Test Run Failed.
 Total time: 1.2760 Minutes

🟢 With fix — 🖥️ Issue32419: PASS ✅ · 93s

  Determining projects to restore...
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/src/BindingSourceGen/Controls.BindingSourceGen.csproj (in 520 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Graphics/src/Graphics/Graphics.csproj (in 530 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Essentials/src/Essentials.csproj (in 483 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/src/Core/Controls.Core.csproj (in 529 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Core/src/Core.csproj (in 591 ms).
  6 of 11 projects are up-to-date for restore.
/Users/cloudtest/vss/_work/1/s/.dotnet/packs/Microsoft.iOS.Sdk.net10.0_26.0/26.0.11017/targets/Xamarin.Shared.Sdk.targets(309,3): warning : RuntimeIdentifier was set on the command line, and will override the value for RuntimeIdentifiers set in the project file. [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-ios]
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Graphics -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Graphics/Debug/net10.0-ios26.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Essentials -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Essentials/Debug/net10.0-ios26.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Core/Debug/net10.0-ios26.0/Microsoft.Maui.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Maps -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Maps/Debug/net10.0-ios26.0/Microsoft.Maui.Maps.dll
  Controls.BindingSourceGen -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Controls.Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Core/Debug/net10.0-ios26.0/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Microsoft.AspNetCore.Components.WebView.Maui -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Microsoft.AspNetCore.Components.WebView.Maui/Debug/net10.0-ios26.0/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Foldable -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Foldable/Debug/net10.0-ios26.0/Microsoft.Maui.Controls.Foldable.dll
  Controls.Xaml -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Xaml/Debug/net10.0-ios26.0/Microsoft.Maui.Controls.Xaml.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Controls.Maps -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Maps/Debug/net10.0-ios26.0/Microsoft.Maui.Controls.Maps.dll
  Detected signing identity:
    Code Signing Key: "" (-)
    Provisioning Profile: "" () - no entitlements
    Bundle Id: com.microsoft.maui.uitests
    App Id: com.microsoft.maui.uitests
  Controls.TestCases.HostApp -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-ios/iossimulator-arm64/Controls.TestCases.HostApp.dll
  Optimizing assemblies for size may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
  Optimizing assemblies for size. This process might take a while.

Build succeeded.

/Users/cloudtest/vss/_work/1/s/.dotnet/packs/Microsoft.iOS.Sdk.net10.0_26.0/26.0.11017/targets/Xamarin.Shared.Sdk.targets(309,3): warning : RuntimeIdentifier was set on the command line, and will override the value for RuntimeIdentifiers set in the project file. [/Users/cloudtest/vss/_work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-ios]
    1 Warning(s)
    0 Error(s)

Time Elapsed 00:00:48.15
  Determining projects to restore...
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/src/BindingSourceGen/Controls.BindingSourceGen.csproj (in 582 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Essentials/src/Essentials.csproj (in 582 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Graphics/src/Graphics/Graphics.csproj (in 582 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/src/Core/Controls.Core.csproj (in 554 ms).
  Restored /Users/cloudtest/vss/_work/1/s/src/Core/src/Core.csproj (in 621 ms).
  8 of 13 projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Controls.CustomAttributes -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.CustomAttributes/Debug/net10.0/Controls.CustomAttributes.dll
  Graphics -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Essentials -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13712679
  Controls.Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  VisualTestUtils -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/VisualTestUtils/Debug/netstandard2.0/VisualTestUtils.dll
  UITest.Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/UITest.Core/Debug/net10.0/UITest.Core.dll
  VisualTestUtils.MagickNet -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/VisualTestUtils.MagickNet/Debug/netstandard2.0/VisualTestUtils.MagickNet.dll
  UITest.Appium -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/UITest.Appium/Debug/net10.0/UITest.Appium.dll
  UITest.NUnit -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/UITest.NUnit/Debug/net10.0/UITest.NUnit.dll
  UITest.Analyzers -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/UITest.Analyzers/Debug/netstandard2.0/UITest.Analyzers.dll
  Controls.TestCases.iOS.Tests -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.iOS.Tests/Debug/net10.0/Controls.TestCases.iOS.Tests.dll
Test run for /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.iOS.Tests/Debug/net10.0/Controls.TestCases.iOS.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (arm64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.iOS.Tests/Debug/net10.0/Controls.TestCases.iOS.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.07]   Discovering: Controls.TestCases.iOS.Tests
[xUnit.net 00:00:00.16]   Discovered:  Controls.TestCases.iOS.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.TestCases.iOS.Tests/Debug/net10.0/Controls.TestCases.iOS.Tests.dll
   NUnit3TestExecutor discovered 2 of 2 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 4/1/2026 7:24:48 AM FixtureSetup for Issue32419(iOS)
>>>>> 4/1/2026 7:24:52 AM VerifyShellFlyoutContentAlignedInRTL Start
>>>>> 4/1/2026 7:24:52 AM VerifyShellFlyoutContentAlignedInRTL Stop
>>>>> 4/1/2026 7:24:52 AM VerifyShellMenuItemsAlignedInRTL Start
>>>>> 4/1/2026 7:24:53 AM VerifyShellMenuItemsAlignedInRTL Stop
  Passed VerifyShellFlyoutContentAlignedInRTL [278 ms]
  Passed VerifyShellMenuItemsAlignedInRTL [926 ms]
NUnit Adapter 4.5.0.0: Test execution complete

Test Run Successful.
Total tests: 2
     Passed: 2
 Total time: 17.6116 Seconds

📁 Fix files reverted (6 files)

• eng/pipelines/ci-copilot.yml
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellFlyoutContentRenderer.cs
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellSectionRenderer.cs
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellSectionRootRenderer.cs
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellTableViewSource.cs
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/SlideFlyoutTransition.cs

New files (not reverted):

• github-merge-flow-release-11.jsonc

---

[MauiBot]

🤖 AI Summary

📊 Expand Full Review — 584278b · addressed copilot comments.

---

🔍 Pre-Flight — Context & Validation

---

Issue: #32419 - [iOS, Mac Catalyst] Shell Flyout and Content Do Not Fully Support RightToLeft (RTL)
PR: #32701 - [iOS, macOS] Shell: Fix RTL flow direction for flyout, menu cells, tab bar, and Locked flyout position
Platforms Affected: iOS, macOS (Mac Catalyst)
Files Changed: 5 implementation, 2 test, 9 snapshot images

Issue Summary

When FlowDirection="RightToLeft" is set on a Shell, two problems occur on iOS/macOS:

1. Content Layout Issue: Only Shell navigation elements (hamburger icon) respect RTL; page content (Labels, etc.) continues rendering LTR. Root cause: Shell sub-elements (header, footer, cells, tracked pages, tab bar) have a disconnected MAUI visual tree, so MatchParent FlowDirection resolution cannot traverse up to the Shell automatically.
2. Flyout Locked State Issue: When FlyoutBehavior="Locked" with RTL, the flyout X position is miscalculated. positionX = shellWidth - openPixels gives shellWidth - flyoutWidth instead of shellWidth, causing incorrect placement.

Files Changed

Fix Files (iOS implementation):

• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellFlyoutContentRenderer.cs (+19) - Resolve MatchParent and call UpdateFlowDirection for header and footer views; also add footer to UpdateFlowDirection()
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellSectionRenderer.cs (+5) - Update flow direction for tab bar unconditionally when it exists
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellSectionRootRenderer.cs (+13) - Resolve MatchParent and propagate flow direction to tracker page
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellTableViewSource.cs (+15) - Resolve MatchParent and apply flow direction to flyout menu item cells
• src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/SlideFlyoutTransition.cs (+11) - Fix flyout X position for Locked behavior in RTL mode (positionX = shellWidth)

Test Files:

• src/Controls/tests/TestCases.HostApp/Issues/Issue32419.cs (+100) - TestShell host page with RTL and FlyoutBehavior; two content pages
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32419.cs (+33) - 2 NUnit screenshot tests: VerifyShellFlyoutContentAlignedInRTL and VerifyShellMenuItemsAlignedInRTL

Snapshot Images (9):

• iOS: VerifyShellFlyoutContentAlignedInRTL.png (new), VerifyShellMenuItemsAlignedInRTL.png (new), ShellFlowDirectionUpdate.png (modified)
• macOS: ShellFlowDirectionUpdate.png (modified)
• Android: VerifyShellFlyoutContentAlignedInRTL.png (new), VerifyShellMenuItemsAlignedInRTL.png (new)
• Windows: VerifyShellFlyoutContentAlignedInRTL.png (new), VerifyShellMenuItemsAlignedInRTL.png (new), ShellFlowDirectionUpdate.png (modified)

Key Findings

• Current commit 584278b addresses all prior Copilot inline review comments (all resolved):
  • Added _footerView?.UpdateFlowDirection(_shellContext.Shell) to UpdateFlowDirection()
  • Removed TabBarItem is not null guard; now uses TabBarController?.TabBar is not null only
  • One-way MatchParent mutation pattern preserved (documented in comments) for header/cells/page
  • Footer uses Shell as context without mutating _footer.FlowDirection (as suggested)
• Prior agent review (commit 2d58996) was APPROVED; this is a re-review of the latest commit 584278b addressing those comments
• PR has labels: s/agent-reviewed, s/agent-approved, s/agent-fix-pr-picked
• PR is no longer DRAFT
• Gate: ✅ PASSED on iOS (tests FAIL without fix, PASS with fix)

Edge Cases from Issue/Discussion

• Dynamic FlowDirection change at runtime — one-way mutation means elements with resolved FlowDirection keep the initial value, but native UIView updates are correct since UpdateFlowDirection() uses Shell as context
• MacCatalyst "Locked" flyout positioning in RTL

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #32701	Resolve MatchParent → UpdateFlowDirection on header/footer/cells/tabbar; fix Locked flyout positionX=shellWidth	✅ PASSED (Gate)	5 files	Original PR

---

🔧 Fix — Analysis & Comparison

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-opus-4.6)	Centralized ShellFlowDirectionCoordinator static helper — no FlowDirection mutation, direct SemanticContentAttribute + child propagation	✅ PASS	6 files	Avoids MatchParent mutation; needed 2 iterations to add child propagation
2	try-fix (claude-sonnet-4.6)	UpdateFlowDirection(view, effectiveParent) overload in ViewExtensions — resolves MatchParent via Shell without mutation, minimal infrastructure extension	✅ PASS	6 files	Cleanest no-mutation approach; touches core ViewExtensions.cs
3	try-fix (gpt-5.3-codex)	ShellRenderer-centric propagation through existing renderer hierarchy on FlowDirectionProperty changed	❌ FAIL	8 files	Menu-items screenshot 8.45% diff; cells not fully covered by hierarchy traversal
4	try-fix (gpt-5.4, gemini unavailable)	Pass shell as context to existing UpdateFlowDirection() calls on disconnected surfaces — no mutation, no new types	❌ FAIL	5 files	3.42%/8.45% diffs; UpdateFlowDirection reads element.FlowDirection first — MatchParent+broken chain = LTR fallback
PR	PR #32701	Resolve MatchParent → UpdateFlowDirection on header/footer/cells/tabbar; fix Locked flyout positionX=shellWidth	✅ PASSED (Gate)	5 files	Original PR

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	2	NO NEW IDEAS	Solution space fully covered
claude-sonnet-4.6	2	NO NEW IDEAS	All viable strategies explored
gpt-5.3-codex	2	NEW IDEA	FlowDirection resolution fallback in GetEffectiveFlowDirection via IMauiContext handler root — variation of already-passing Attempt 2
gpt-5.4	2	NO NEW IDEAS	Fix space sufficiently covered with 3 passing alternatives

Exhausted: Yes — 3/4 models NO NEW IDEAS; new idea is a variation of passing Attempt 2
Selected Fix: PR's fix — most idiomatic to codebase, minimal (5 files, ~53 lines), well-documented comments, all prior review comments addressed, no new helper classes or core infrastructure changes

---

📋 Report — Final Recommendation

---

✅ Final Recommendation: APPROVE

Phase Status

Phase	Status	Notes
Pre-Flight	✅ COMPLETE	Issue #32419, 5 iOS fix files, 2 test files, 9 snapshots
Gate	✅ PASSED	iOS — tests FAIL without fix, PASS with fix
Try-Fix	✅ COMPLETE	4 attempts (2 ✅, 2 ❌); 3 additional passing alternatives confirmed across 2 review sessions
Report	✅ COMPLETE

Summary

PR #32701 fixes Shell RTL (Right-to-Left) layout for iOS/macOS. When FlowDirection="RightToLeft" is set on a Shell, page content, flyout header/footer, tab bar items, and menu cells now correctly mirror to RTL. The Locked flyout X position calculation is also fixed for RTL mode. All prior Copilot inline review comments have been fully addressed in commit 584278b.

Root Cause

Shell sub-elements (header, footer, cells, tracked pages, tab bar) in the iOS compatibility renderer layer have a disconnected MAUI visual tree. When these elements have FlowDirection=MatchParent, the MatchParent resolution cannot traverse up to the Shell because the parent chain is broken in the compatibility renderer layer — IVisualTreeElement.GetVisualParent() for these elements yields BaseShellItem, not the Shell itself.

For the flyout position bug: SlideFlyoutTransition.LayoutViews computed positionX = shellWidth - openPixels for RTL, where openPixels = flyoutWidth in Locked mode, giving positionX = shellWidth - flyoutWidth. This is off by one flyout width, placing the flyout incorrectly.

Fix Quality

The PR's fix is clean, minimal, and consistent with the existing UpdateFlowDirection pattern:

• 5 targeted files, ~53 lines added — minimal and focused
• Extends existing UpdateFlowDirection() call sites to cover previously missing elements: flyout header/footer, tab bar, cells, tracked page
• Resolves the MatchParent disconnection by explicitly setting FlowDirection before calling UpdateFlowDirection — a one-way mutation fully documented in code comments with architectural rationale
• Footer specifically uses Shell as context without mutating _footer.FlowDirection (cleaner approach, correctly addressed from prior review)
• TabBarController?.TabBar is not null guard (without TabBarItem check) is correct per prior review comment — ensures TabBar is always updated when it exists regardless of async TabBarItem state
• Fixes the Locked flyout position with a minimal targeted if (behavior == FlyoutBehavior.Locked) check setting positionX = shellWidth
• The MatchParent mutation is appropriate: it runs at renderer initialization/property-change time; subsequent Shell.FlowDirection changes continue to update native UIViews correctly via the existing UpdateFlowDirection() wiring

Try-Fix Results Summary

4 independent approaches attempted (2 passing):

• ✅ Attempt 1 (claude-opus-4.6): ShellFlowDirectionCoordinator — no mutation, direct SemanticContentAttribute + child propagation
• ✅ Attempt 2 (claude-sonnet-4.6): UpdateFlowDirection(view, effectiveParent) overload — no mutation, extends core infrastructure
• ❌ Attempt 3 (gpt-5.3-codex): Renderer hierarchy traversal — cells not fully reached, 8.45% screenshot diff
• ❌ Attempt 4 (gpt-5.4): Pass shell as context directly — UpdateFlowDirection reads element.FlowDirection first; MatchParent+broken chain = LTR fallback

Cross-pollination (Round 2): 3/4 models NO NEW IDEAS; 1 idea is a variation of already-passing Attempt 2. Exhausted.

Selected Fix: PR's fix — most idiomatic to the MAUI codebase, uses existing UpdateFlowDirection pattern, minimal surface area (5 files vs 6), no new helper classes or core infrastructure changes. Passing alternatives (1, 2) either add a new class (Attempt 1) or touch core ViewExtensions.cs (Attempt 2) which has broader impact. The PR's one-way MatchParent mutation is explicitly documented and acceptable for the static RTL setup scenario.

Code Review Findings

1. One-Way FlowDirection Mutation (Low Risk — Documented)

The MatchParent→concrete mutation in ShellFlyoutContentRenderer.cs (header), ShellSectionRootRenderer.cs (tracked page), and ShellTableViewSource.cs (cells) is a one-way change. However:

• Explicitly documented in code comments with full architectural rationale
• Subsequent Shell.FlowDirection changes still update native UIViews correctly via UpdateFlowDirection() which uses Shell as context
• Footer correctly avoids mutation (uses Shell as context directly) — this is the preferred pattern where applicable
• The issue reports a static RTL setup; this trade-off is acceptable

2. VerifyShellFlyoutContentAlignedInRTL Test Design

Test waits for homePageLabel but never explicitly opens the flyout — it captures the Shell content page in RTL. Test name suggests flyout content, but it's actually validating the page content RTL alignment. This was flagged in prior review; the PR author indicated VerifyShellMenuItemsAlignedInRTL handles the flyout. Acceptable, but test name could be more precise (low risk).

3. Snapshot Coverage

PR includes Android and Windows snapshots for the two new tests. No fix code for those platforms — snapshots appear to be visual validation only to confirm the fix is non-regressive on those platforms. Appropriate.

4. DRAFT Status

PR is no longer marked DRAFT (confirmed from current state).

---

[kubaflo]

Is this PR ready? :)

[sheiksyedm]

/azp run maui-pr-uitests , maui-pr-devicetests

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[Copilot]

Pull request overview

Fixes Shell RTL (Right-to-Left) behavior on iOS/macOS by ensuring flow direction is applied consistently across flyout/header/footer/menu cells/tab bar and correcting the flyout’s locked positioning in RTL, with new UI-test coverage and updated visual snapshots.

Changes:

• Correct RTL flyout positioning when FlyoutBehavior.Locked on iOS.
• Apply/propagate flow direction updates to Shell flyout header/footer, flyout menu item cells, section root views, and tab bar.
• Add Issue32419 HostApp repro + Appium/NUnit UI tests and update baseline screenshots across platforms.

Reviewed changes

Copilot reviewed 7 out of 15 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/SlideFlyoutTransition.cs	Adjusts RTL frame calculation for locked flyout positioning.
src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellTableViewSource.cs	Applies flow direction handling to flyout menu item cells.
src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellSectionRootRenderer.cs	Updates section root flow direction and tracked-page flow direction handling.
src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellSectionRenderer.cs	Ensures tab bar flow direction is updated alongside section/nav bar updates.
src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellFlyoutContentRenderer.cs	Ensures flyout header/footer use Shell flow direction and applies it to native views.
src/Controls/tests/TestCases.HostApp/Issues/Issue32419.cs	Adds HostApp repro Shell page for RTL flyout/menu alignment + locked behavior.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32419.cs	Adds Appium UI tests and screenshot verification for Issue32419.
src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyShellFlyoutContentAlignedInRTL.png	Updates iOS baseline snapshot for RTL alignment.
src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/VerifyShellMenuItemsAlignedInRTL.png	Updates iOS baseline snapshot for RTL menu alignment in locked mode.
src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/ShellFlowDirectionUpdate.png	Updates iOS baseline snapshot for flow-direction update scenario.
src/Controls/tests/TestCases.Android.Tests/snapshots/android/VerifyShellMenuItemsAlignedInRTL.png	Updates Android baseline snapshot for the new test scenario.
src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyShellFlyoutContentAlignedInRTL.png	Updates WinUI baseline snapshot for RTL alignment.
src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/VerifyShellMenuItemsAlignedInRTL.png	Updates WinUI baseline snapshot for RTL menu alignment.
src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/ShellFlowDirectionUpdate.png	Updates WinUI baseline snapshot for flow-direction update scenario.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 32701

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 32701"