[iOS] Fix SwipeView stays open on iOS after updating content

[devanathan-vaithiyanathan]

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!

Issue Details

On iOS, when a SwipeView is placed inside a CollectionView and its content is updated, the swipe items remain in the open state.

Description of Change

When the BindingContext changes, manually close the open state of the SwipeView.

Issues Fixed

Fixes #19541

Tested the behavior in the following platforms.

• Android
• Windows
• iOS
• Mac

Before	After
iOS Before.mov	iOS After.mov

[dotnet-policy-service]

Hey there @@devanathan-vaithiyanathan! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull Request Overview

This PR fixes an iOS-specific issue where SwipeView controls remain open after their content is updated in a CollectionView. The issue occurs because iOS reuses cells in CollectionView, maintaining the SwipeView's open state when the BindingContext changes, unlike Android and Windows which create new cells and reset the state.

• Added logic to automatically close SwipeView when BindingContext changes on iOS
• Included comprehensive test case to validate the fix
• Ensures consistent behavior across platforms

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/Controls/src/Core/SwipeView/SwipeView.cs	Added automatic close logic in OnBindingContextChanged to fix iOS cell reuse issue
src/Controls/tests/TestCases.HostApp/Issues/Issue19541.cs	Added UI test page with CollectionView and SwipeView to reproduce the issue
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue19541.cs	Added automated test to verify SwipeView closes after collection refresh

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jsuarezruiz]

Should use a compilation directive and only do this on iOS?

[jsuarezruiz]

And Catalyst

[devanathan-vaithiyanathan]

@jsuarezruiz , Based on suggestion, I have modified the changes.

[jsuarezruiz]

/azp run MAUI-UITests-public

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jsuarezruiz]

/rebase

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — condition added · fc467b1

---

Issue: #19541 - [iOS] SwipeView with CollectionView issue
PR: #31248 - [iOS] Fix SwipeView stays open on iOS after updating content
Platforms Affected: iOS (primary), MacCatalyst
Files Changed: 1 fix file, 3 snapshot files, 2 test files

Issue Summary

On iOS, when a SwipeView is open inside a CollectionView and the CollectionView's ItemsSource is refreshed, the SwipeView remains in the open state. This happens because iOS/MacCatalyst CollectionViews reuse cells (unlike Android/Windows which create new cells), so the old swipe open state persists after rebinding. On Android, this works correctly because new cells are created on rebind.

Fix Description

In SwipeView.OnBindingContextChanged(), close the SwipeView when _isOpen == true, but only on iOS/MacCatalyst (using #if IOS || MACCATALYST compiler directive). This prevents the stale open state when cells are recycled.

Files Changed

File	Type	Description
src/Controls/src/Core/SwipeView/SwipeView.cs	Fix	Add close logic in OnBindingContextChanged for iOS/MacCatalyst
src/Controls/tests/TestCases.HostApp/Issues/Issue19541.cs	Test	Host app reproduction page
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue19541.cs	Test	NUnit UI test
src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/SwipeItemShouldBeCloseWhenUpdateTheCollectionView.png	Snapshot	iOS screenshot baseline
src/Controls/tests/TestCases.Android.Tests/snapshots/android/SwipeItemShouldBeCloseWhenUpdateTheCollectionView.png	Snapshot	Android screenshot baseline
src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/SwipeItemShouldBeCloseWhenUpdateTheCollectionView.png	Snapshot	macOS screenshot baseline

PR Discussion Summary

File:Line	Reviewer	Comment	Status
	jsuarezruiz	Should use a compilation directive and only do this on iOS? And Catalyst	RESOLVED (author implemented #if IOS || MACCATALYST)

No other review disagreements or edge cases noted. Azure Pipelines UI tests were run. PR was rebased on 2025-10-10.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #31248	Close SwipeView in OnBindingContextChanged for iOS/MacCatalyst when `_isOpen == PENDING (Gate)	SwipeView.cs (+12)	Original PR	true`

---

🚦 Gate — Test Verification

---

📝 Review Session — condition added · fc467b1

---

Result PASSED:
Platform: iOS (iPhone 11 Pro simulator)
Mode: Full Verification

• Tests FAIL without fix (bug detected correctly)
• Tests PASS with fix (fix validated)

Test: SwipeItemShouldBeCloseWhenUpdateTheCollectionView in Issue19541
Fix files reverted for test-without-fix run: src/Controls/src/Core/SwipeView/SwipeView.cs

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — condition added · fc467b1

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix	Add IsOpen property mapper on iOS handler; use in handler; set in	PASS	3 files + 2 API files	More complex; requires new public API surface
2	try-fix	Unconditionally set and call in (no guard)	PASS	1 file	Slight risk: fires even when not open
3	try-fix	Listen for parent CollectionView PropertyChanged and call when open	PASS	1 file	Targets refresh path directly; couples to CollectionView type
4	try-fix	Close SwipeView when Parent becomes null in (cell return to reuse pool)	PASS	1 file	Too broad; fires on any parent detachment, not just ItemsSource refresh
PR	PR #31248	In , close with guard + check via	PASS (Gate)	1 file (+12 lines)	Most minimal and targeted

Exhausted: Yes (cross-pollination: all 4 models say NO NEW IDEAS after Round 1)
Selected Fix: PR's It is the most minimal change (single file, 12 lines), correctly platform-gated to iOS/MacCatalyst using compiler directives, guards against unnecessary calls with if (_isOpen), and uses the established ISwipeView interface for requesting close. All alternatives add complexity or have unintended side effects.fix

---

📋 Report — Final Recommendation

---

📝 Review Session — condition added · fc467b1

---

Final Recommendation: APPROVE

Summary

PR #31248 fixes issue #19541 where SwipeView stays open on iOS after CollectionView content is updated. The fix is minimal, targeted, and correctly platform-gated. Gate verification confirmed tests fail without the fix and pass with it. Four independent fix alternatives were explored via try-fix - all passed but the PR's approach is the simplest and most appropriate.

Root Cause

On iOS/MacCatalyst, CollectionView reuses cells (UITableView/UICollectionView cell reuse pattern). When ItemsSource is refreshed, existing cells are recycled and their BindingContext is updated - but the SwipeView._isOpen state from the previous binding persists visually. On Android and Windows, new cells are created on rebind, so _isOpen naturally starts as false.

Fix Quality

The fix is well-designed:

• Minimal: 12 lines added to a single file (SwipeView.cs)
• Platform-gated: Uses #if IOS || MACCATALYST - correct for this iOS-specific cell reuse behavior
• Guarded: if (_isOpen) prevents unnecessary RequestClose calls on already-closed SwipeViews
• Uses correct API: ((ISwipeView)this).RequestClose(new SwipeViewCloseRequest(false)) - uses the established interface with animated: false (no animation needed during data refresh)
• Well-commented: Explains the platform difference (cell reuse vs new cells)

Test Quality

• HostApp page (Issue19541.cs): Creates a CollectionView with SwipeViews, with Open and Refresh buttons. Correctly uses AutomationId for test automation.
• NUnit test: Opens SwipeView, triggers refresh, verifies via screenshot. Simple and direct.
• Platform guard: #if TEST_FAILS_ON_WINDOWS correctly excludes Windows (iOS-specific bug).
• Snapshots: Added for iOS, Android, and Mac.

Reviewer Thread Status

One review thread from asking for a compilation directive for iOS/Catalyst - already addressed by the author. Thread is marked unresolved in the UI but the code change was made.

Fix Comparison

Approach	Complexity	Files	Verdict
PRs Minimal	1 (+12 lines Best	)	fix
Attempt 1 (IsOpen mapper)	High	3 + 2 API files	New public API required
Attempt 2 (unconditional reset)	Low	1	Fires even when not open
Attempt 3 (ItemsSource listener)	Medium	1	Couples to CollectionView
Attempt 4 (Parent=null)	Low	1	Too broad

---

📋 Expand PR Finalization Review

---

Title: ✅ Good

Current: [iOS] Fix SwipeView stays open on iOS after updating content

Description: ✅ Good

Description needs updates. See details below.

✨ 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

On iOS and Mac Catalyst, UICollectionView reuses cells when the ItemsSource is refreshed. This means the same SwipeView instance is rebound with a new BindingContext while still in the open state (_isOpen = true). The swipe items remain visually open even though the underlying data has changed.

On Android and Windows, new cells are created for each item on rebind, so _isOpen is always false for new instances — no issue.

Description of Change

In SwipeView.OnBindingContextChanged(), added an iOS/MacCatalyst-only check: if the SwipeView is currently open when the BindingContext changes, RequestClose is called (without animation) to reset the open state.

#if IOS || MACCATALYST
    if (_isOpen)
    {
        ((ISwipeView)this).RequestClose(new SwipeViewCloseRequest(false));
    }
#endif

This closes the stale swipe state before the view is reused with the new binding context.

Key Technical Details

• _isOpen — internal field on SwipeView tracking open state
• ISwipeView.RequestClose — dispatches to the platform handler via Handler?.Invoke(...), so it's safe to call even if no handler is attached
• SwipeViewCloseRequest(false) — false = no animation, appropriate for a reset during rebind
• The #if IOS || MACCATALYST conditional is consistent with existing patterns in SwipeView.cs

Issues Fixed

Fixes #19541

Platforms Tested

• Android
• Windows
• iOS
• Mac

Code Review: ✅ Passed

Code Review — PR #31248

🟡 Suggestions

1. Inconsistent field naming in HostApp test (Issue19541.cs)

File: src/Controls/tests/TestCases.HostApp/Issues/Issue19541.cs

_swipeView uses the conventional underscore prefix, but collectionView does not.

// Current (inconsistent)
SwipeView _swipeView;
CollectionView collectionView;

// Suggested (consistent)
SwipeView _swipeView;
CollectionView _collectionView;

This is a minor style issue and won't affect functionality.

---

2. Behavioral edge case: closes on any BindingContext change

File: src/Controls/src/Core/SwipeView/SwipeView.cs

The fix closes the SwipeView whenever _isOpen && BindingContext changes on iOS/MacCatalyst — not just when inside a CollectionView. This means if a user manually updates the BindingContext of a SwipeView that the user intentionally opened (outside of a list), it will be silently closed.

This is a reasonable tradeoff: the reported scenario (CollectionView cell reuse) is the primary and known use case. However, it's a behavior change worth documenting.

Recommendation: The code comment already explains the reasoning well. No code change needed, but the PR description should mention this tradeoff (addressed in recommended-description.md).

---

3. swipeView_Loaded captures only the first SwipeView

File: src/Controls/tests/TestCases.HostApp/Issues/Issue19541.cs

void swipeView_Loaded(object sender, EventArgs e)
{
    if (_swipeView is null)
        _swipeView = (SwipeView)sender;
}

This assigns _swipeView only once (the first to load). The "Open" button then opens specifically that first cell's SwipeView, which is fine for the test scenario. The test verifies that after refresh, the SwipeView is closed — the exact cell tracked is sufficient.

No action needed, but this is worth noting for future test modifications.

---

✅ Looks Good

• Fix scope is correct: #if IOS || MACCATALYST is the right conditional. The existing file already uses #if IOS for platform-specific logic, so this is consistent.
• RequestClose is null-safe: Uses Handler?.Invoke(...) so it won't throw if called before the handler is attached.
• No animation on close (false): Appropriate for a background reset during cell reuse — no visual flash.
• UI test covers the scenario: The test opens a SwipeView, refreshes the CollectionView, and verifies via screenshot — directly reproducing the reported bug.
• Test excluded from Windows (#if TEST_FAILS_ON_WINDOWS): Correct, as the issue is iOS-specific.
• Snapshot baselines added for iOS, Android, and Mac — the test infrastructure is complete.

---