[iOS] Fix: CollectionView does not clear selection when SelectedItem is set to null

[Tamilarasan-Paranthaman]

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

CollectionView.SelectItem was being called inside the PerformBatchUpdates completion handler, which is triggered after all other actions are completed. As a result, when SelectedItem is set to null in the SelectionChanged event handler, the deferred selection inside PerformBatchUpdates would fire afterward and re-select the item, making the null assignment ineffective.

The original implementation (from PR #25555) always wrapped SelectItem calls in PerformBatchUpdates to ensure selection happened after collection view items generation was completed. This worked for initial load scenarios but caused a timing issue for runtime selection changes.

Description of Change

The fix introduces conditional logic based on the view's loaded state using CollectionView.IsLoaded() (which checks if UIView.Window != null):

For initial load (!IsLoaded()):

• Selection still uses PerformBatchUpdates to defer until items are generated
• This preserves the original intent from PR Fixed CollectionView SelectedItem binding issue on initial loading #25555

For runtime changes (IsLoaded()):

• Selection executes immediately without PerformBatchUpdates wrapper
• Includes all existing safety checks: EmptySource verification, reference equality, index recalculation, and item equality validation
• Allows user code (like SelectedItem = null) to take effect immediately without being overridden by deferred selection

This resolves the issue where the selected item was not being cleared when SelectedItem is set to null during runtime.

Key Technical Details

IsLoaded() Extension Method:

• Definition: UIView.Window != null
• Indicates whether the view is attached to the window hierarchy
• Used to distinguish between initial load (preselection) vs. runtime selection changes

Lifecycle Distinction:

• Initial load: View isn't attached, items still being laid out → defer selection
• Runtime: View is active, items stable → select immediately to avoid race conditions

Why Immediate Selection Works:
Direct SelectItem calls execute synchronously in the current call stack, before any completion handlers fire. This prevents the race condition where user code sets SelectedItem = null, but the deferred PerformBatchUpdates completion handler re-selects the item afterward.

Files Changed

1. src/Controls/src/Core/Handlers/Items/iOS/SelectableItemsViewController.cs - Added IsLoaded() check (deprecated handler)
2. src/Controls/src/Core/Handlers/Items2/iOS/SelectableItemsViewController2.cs - Added IsLoaded() check (current handler)
3. src/Controls/tests/TestCases.HostApp/Issues/Issue30363.cs - New UI test demonstrating the fix
4. src/Controls/tests/TestCases.HostApp/Issues/Issue26187.cs - Updated existing test
5. src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue30363.cs - Appium test with screenshot verification
6. Snapshots for iOS and Android

What NOT to Do (for future agents)

• ❌ Don't always use PerformBatchUpdates for selection - This causes deferred execution that can override user code
• ❌ Don't remove PerformBatchUpdates entirely - Initial load scenarios still need it for proper item generation timing
• ❌ Don't ignore the view's loaded state - The lifecycle context (initial vs. runtime) is critical for correct timing

Edge Cases

Scenario	Risk	Mitigation
EmptySource disposal	Medium	Runtime path checks ItemsSource is EmptySource before selection
ItemsSource changes during selection	Medium	Runtime path verifies ReferenceEquals(ItemsView.ItemsSource, originalSource)
Collection mutations (add/delete)	Medium	Runtime path recalculates index and verifies item equality at updated position
Initial preselection timing	Low	Preserved PerformBatchUpdates for !IsLoaded() case

Issues Fixed

Fixes #30363
Fixes #26187

Regression PR

This fix addresses a regression introduced in PR #25555, which added PerformBatchUpdates to ensure selection timing but didn't account for runtime selection clearing scenarios.

Platforms Tested

• iOS
• Mac
• Android
• Windows

Screenshots

Issue #30363:

Before Fix	After Fix
30363-Before-Fix.mov	30363-After-Fix.mov

Issue #26187:

Before Fix	After Fix
26187-Before-Fix.mov	26187-After-Fix.mov

[bhavanesh2001]

#29940 is in inflight/current now, Could you verify if those changes are sufficient to address the issues you're referring to here?

[bhavanesh2001]

Won't this prevent item selection, if SelectedItem is pre-defined? please verify

[Tamilarasan-Paranthaman]

It will not prevent item pre-selection as long as CollectionView.SelectedItem is not set to null in the CollectionView.SelectionChanged event, as in the case reported by the user.

[Tamilarasan-Paranthaman]

#29940 is in inflight/current now, Could you verify if those changes are sufficient to address the issues you're referring to here?

@bhavanesh2001, I have checked both issues, #30363 and #26187, with the changes made in PR #29940. However, the changes in #29940 do not address these issues.

[rmarinho]

/rebase

[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 -- 30420

Or

• Run remotely in PowerShell:

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

[Copilot]

Pull request overview

This PR fixes an iOS-specific bug where CollectionView selection could not be cleared by setting SelectedItem to null in the SelectionChanged event handler. The issue occurred because the selection logic was being deferred inside PerformBatchUpdates, which re-selected items after they were meant to be cleared.

Key Changes:

• Modified selection logic to only use PerformBatchUpdates when the CollectionView is not yet loaded (preselection scenario)
• For loaded CollectionViews, selection is now applied directly without batching
• Applied fix consistently to both deprecated Items and current Items2 handler implementations

Reviewed changes

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

Show a summary per file

File	Description
src/Controls/src/Core/Handlers/Items2/iOS/SelectableItemsViewController2.cs	Added IsLoaded() check to conditionally wrap SelectItem call in PerformBatchUpdates only during initial load
src/Controls/src/Core/Handlers/Items/iOS/SelectableItemsViewController.cs	Applied same fix to deprecated Items handler for consistency
src/Controls/tests/TestCases.HostApp/Issues/Issue30363.cs	Added UI test page demonstrating selection clearing behavior
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue30363.cs	Added NUnit UI test to verify selection clearing via screenshot validation
src/Controls/tests/TestCases.HostApp/Issues/Issue26187.cs	Cleaned up test code - removed unused properties, changed async void to void
src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/CollectionViewSelectionShouldClear.png	iOS screenshot baseline for visual regression testing
src/Controls/tests/TestCases.Android.Tests/snapshots/android/CollectionViewSelectionShouldClear.png	Android screenshot baseline for visual regression testing

[kubaflo]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — added snapshots · bc8629b

---

Issue: #30363, #26187 - CollectionView does not clear selection when SelectedItem is set to null on iOS
Platforms Affected: iOS, MacCatalyst (fix touches both CV1 and CV2 iOS handlers)
Files Changed: 2 implementation files, 4 test files, 2 snapshot files

Summary

This PR fixes an iOS-specific bug where CollectionView selection could not be cleared by setting SelectedItem to null in the SelectionChanged event handler. The issue caused a visual regression where items appeared selected even after being programmatically deselected.

Root Cause (per PR):

• CollectionView.SelectItem was always called inside PerformBatchUpdates completion handler
• This completion handler fires after all other actions complete
• When user sets SelectedItem = null in SelectionChanged, the deferred batch update re-selects the item afterward, making null assignment ineffective

Fix Approach (per PR):

• Add IsLoaded() check (checks UIView.Window != null) to distinguish initial load vs runtime
• For initial load (!IsLoaded()): Keep PerformBatchUpdates to defer until items are generated
• For runtime (IsLoaded()): Direct SelectItem call with full safety checks (EmptySource, ReferenceEquals, index recalculation, item equality)
• Applied consistently to both CV1 (Items/iOS/SelectableItemsViewController.cs) and CV2 (Items2/iOS/SelectableItemsViewController2.cs)

PR Discussion

File:Line	Reviewer	Comment	Author Response	Status
SelectableItemsViewController2.cs:59	bhavanesh2001	"Won't this prevent item selection if SelectedItem is pre-defined?"	Pre-selection still works as long as user doesn't set SelectedItem=null in NEEDS GATE VERIFICATION	SelectionChanged
SelectableItemsViewController.cs:58	jsuarezruiz	"Create a shared helper method since fix is same in CV1 and CV2"	Code changes are minimal; kept in respective places consistent with other CODE STYLE - not a correctness issue	logic

Copilot review: Generated no inline comments; found changes correct

Edge Cases

• Pre-selection still works (SelectedItem set before load, !IsLoaded() path)
• Selection clearing in SelectionChanged event (primary bug scenario)
• Multiple rapid selection changes
• EmptySource disposal check (in runtime path)
• ItemsSource reference equality check (in runtime path)
• Index recalculation on collection mutation (in runtime path)

Files Classification

Fix Files:

• src/Controls/src/Core/Handlers/Items/iOS/SelectableItemsViewController.cs (CV1, deprecated) (+9/-2)
• src/Controls/src/Core/Handlers/Items2/iOS/SelectableItemsViewController2.cs (CV2, current) (+9/-2)

Test Files:

• src/Controls/tests/TestCases.HostApp/Issues/Issue30363.cs (new UI test page, +60)
• src/Controls/tests/TestCases.HostApp/Issues/Issue26187.cs (updated existing test, +2/-9)
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue30363.cs (new NUnit test, +23)
• src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/CollectionViewSelectionShouldClear.png (snapshot)
• src/Controls/tests/TestCases.Android.Tests/snapshots/android/CollectionViewSelectionShouldClear.png (snapshot)

Test Type: UI Tests with screenshot validation

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #30420	Add IsLoaded() check: use PerformBatchUpdates only during initial load (!IsLoaded()), direct SelectItem for loaded PENDING (Gate)	2 files (+18/-4)	Original PR - applied to both CV1 and CV2	views

---

🚦 Gate — Test Verification

---

📝 Review Session — added snapshots · bc8629b

---

Result PASSED:
Platform: ios
Mode: Full Verification

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

Test: CollectionViewSelectionShouldClear (Issue30363)
Duration: ~5.5 minutes total (both runs)

Fix files verified:

• src/Controls/src/Core/Handlers/Items/iOS/SelectableItemsViewController.cs
• src/Controls/src/Core/Handlers/Items2/iOS/SelectableItemsViewController2.cs

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — added snapshots · bc8629b

---

Try-Fix Summary

Attempt Results

#	Model	Approach	Result
PR	Original	IsLoaded() split: PerformBatchUpdates for !IsLoaded(), direct for PASS	loaded
1	claude-sonnet-4.6	Equals guard inside PerformBatchUpdates completion PASS
2	claude-opus-4.6	_selectionGeneration counter (increment in ClearSelection PASS	)
3	gpt-5.2	Reconcile from current ItemsView.SelectedItem at completion time PASS
4	gpt-5.3-codex	Skip PerformBatchUpdates if item already natively selected PASS
5	gemini-3-pro-preview	Compensating cleanup queued after pending selects in ClearSelection PASS
6	claude-sonnet-4.6	ShouldSelectItem delegate FAIL (UIKit does not call for programmatic selection)	override
7	gpt-5.3-codex	DesiredSelectedItem state machine + ViewDidLayoutSubviews PASS
8	gpt-5.2	WillDisplayCell cell lifecycle tracking PASS
9	gemini-3-pro-preview	Remove PerformBatchUpdates entirely, call SelectItem directly PASS

Total: 9 attempts, 8 PASS, 1 FAIL
Cross-pollination: 3 rounds completed (max reached)

Key Findings

Root Cause Confirmed

SelectItem was wrapped in PerformBatchUpdates completion (added in PR #25555 for initial load timing). The completion fires AFTER SelectionChanged event, so when user sets SelectedItem = null in SelectionChanged, the deferred completion re-selects the item.

Critical UIKit Discovery

ShouldSelectItem delegate is NOT called for programmatic UICollectionView.SelectItem() only user taps. Any fix must operate in C# managed code or inside the PerformBatchUpdates completion block.calls

Best Alternative Fix

Attempt 1 (Equals guard inside completion) is the minimal-risk alternative:

• +7 lines per file (smallest passing change besides Attempt 9)
• No new fields, no lifecycle changes
• Guards completion against re-selecting an item that was cleared during the async gap

Attempt 9 (remove PerformBatchUpdates entirely) is the simplest structurally but loses the timing guarantee for initial preselection (SelectedItem set before first layout).

PR Fix Assessment

The PR's IsLoaded() approach is semantically correct and explicitly handles both cases:

• !IsLoaded(): keep PerformBatchUpdates (initial load needs async timing)
• IsLoaded(): call directly (runtime changes are safe to apply immediately)

Recommendation: PR's fix is the right approach. The only improvement would be adding the Attempt 1 Equals guard as additional defense-in-depth inside the completion.

Cross-Pollination Rounds

Round	claude-sonnet	claude-opus	gpt-5.2	gpt-5.3-codex	gemini
1	NEW IDEAS	NEW IDEAS	NEW IDEAS	NEW IDEAS	NEW IDEAS
2	NEW IDEAS	NO NEW IDEAS	NEW IDEAS	NEW IDEAS	NEW IDEAS
3	NEW IDEAS	NO NEW IDEAS	NEW IDEAS	NEW IDEAS	NEW IDEAS

3-round maximum reached. Solution space thoroughly explored.

Selected Fix: PR's IsLoaded() approach (conditional PerformBatchUpdates)

The PR's fix correctly identifies the lifecycle boundary (initial load vs runtime) and handles each case appropriately. Best alternative is Attempt 1 (Equals guard, +7 lines) as defense-in-depth if the PR author wants additional safety.

Exhausted: 3 cross-pollination rounds completed (max reached), solution space thoroughly explored.Yes

Result: 8/9 PASS

---

📋 Report — Final Recommendation

---

📝 Review Session — added snapshots · bc8629b

---

PR #30420 Agent Review Report

Summary

PR: [iOS] Fix: CollectionView does not clear selection when SelectedItem is set to null
Gate PASSED :
Try-Fix: 9 attempts, 8 PASS, 1 FAIL
Recommendation APPROVE with minor suggestions:

---

Phase 1: Pre-Flight

• Issue: #30363 (and # CollectionView selection persists after SelectedItem = null in SelectionChanged26187)
• Root cause confirmed: SelectItem was wrapped in PerformBatchUpdates completion, which fires AFTER SelectionChanged. Setting SelectedItem = null in SelectionChanged had no effect because the deferred completion re-selected the item.
• Regression: Introduced by PR #25555 (added PerformBatchUpdates for initial load timing)
• Fix targets: Items/iOS/SelectableItemsViewController.cs and Items2/iOS/SelectableItemsViewController2.cs
• Tests added: Issue30363.cs in HostApp and Shared.Tests

---

Phase 2: Gate PASSED

Tests FAIL without fix, PASS with fix on iOS simulator.

Test: Issue30363. taps item, verifies selection cleared via screenshot.CollectionViewSelectionShouldClear

---

Phase 3: Try-Fix (9 attempts, 3 cross-poll rounds)

#	Model	Approach	Result
PR	Original	IsLoaded() split: PerformBatchUpdates only for ! PASS	IsLoaded()
1	claude-sonnet	Equals guard inside completion block PASS
2	claude-opus	_selectionGeneration counter PASS
3	gpt-5.2	Reconcile from current SelectedItem at completion time PASS
4	gpt-5.3-codex	Skip if already natively selected PASS
5	gemini	Compensating cleanup queued in ClearSelection PASS
6	claude-sonnet	ShouldSelectItem FAIL	override
7	gpt-5.3-codex	DesiredSelectedItem state machine PASS
8	gpt-5.2	WillDisplayCell lifecycle tracking PASS
9	gemini	Remove PerformBatchUpdates entirely PASS

Key discovery (Attempt 6): ShouldSelectItem delegate is NOT called for programmatic UICollectionView. UIKit only calls it for user taps. Any fix must operate in C# managed code.SelectItem()

Best alternative: Attempt 1 (Equals guard, +7 lines) provides defense-in-depth without architectural changes.

The PR's approach is the right it explicitly distinguishes initial load from runtime and preserves the PerformBatchUpdates timing guarantee for initial preselection.design

---

Phase 4: PR Finalize

Title Assessment

Current: [iOS] Fix: CollectionView does not clear selection when SelectedItem is set to null
Assessment: Good. Platform prefix, clear description. The "Fix:" sub-prefix is optional but acceptable.

Description Assessment Keep As-IsExcellent

The description has all required elements:

• NOTE block (user testing artifacts)
• Root cause with specific code path explanation
• Description of Change with conditional logic breakdown
• Key Technical Details (IsLoaded() definition, lifecycle distinction)
• Files Changed (all 6)
• What NOT to Do (3 entries)
• Edge Cases table
• Issues Fixed (#30363, #26187)
• Regression PR (#25555)
• Platforms Tested (all 4)
• Before/after screenshots (videos)

---

Code Review Findings

Files: Both SelectableItemsViewController.cs and SelectableItemsViewController2.cs

The original PerformBatchUpdates completion had 5 safety guards before calling SelectItem:

1. if (ItemsSource is EmptySource) return;
2. if (!ReferenceEquals(ItemsView.ItemsSource, originalSource)) return;
3. Recalculate updatedIndex after delay
4. if (updatedIndex == null) return;
5. Item equality check if (!Equals(updatedItem, selectedItem)) return;

The PR's !IsLoaded() branch removes ALL of them, calling CollectionView.SelectItem(index, ...) using the index captured at method entry (before any async gap), with no guards against ItemsSource disposal or collection mutations.directly

Risk: Low in practice (initial load rarely has concurrent mutations), but the guards were deliberately added and their removal is undocumented. If items are reordered during initial load, the wrong item may be visually selected even if it passes index equality.

Recommendation: Move the safety guards into the !IsLoaded() completion handler too (same as the IsLoaded() path), or add a code comment explaining why they're intentionally omitted for the initial load case.

// Suggested for !IsLoaded() path:
CollectionView.PerformBatchUpdates(null, _ =>
{
    if (ItemsSource is EmptySource)
        return;
    var originalSource = ItemsSource;
    if (!ReferenceEquals(ItemsView.ItemsSource, originalSource))
        return;
    var updatedIndex = IndexPath(selectedItem);
    if (updatedIndex == null)
        return;
    var updatedItem = GetItem(updatedIndex);
    if (!Equals(updatedItem, selectedItem))
        return;
    CollectionView.SelectItem(updatedIndex, true, UICollectionViewScrollPosition.None);
});

Unobserved Task in Issue26187.cs

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

The PR changed async void CollectionView_SelectionChanged with await Navigation.PushAsync(...) to void CollectionView_SelectionChanged with Navigation.PushAsync(...) (no await). If navigation throws, the exception is unobserved.

Recommendation: Use _ = Navigation.PushAsync(new NewPage(issue)); to explicitly discard, or keep async void.

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

VerifyScreenshot() called immediately after App.Tap("cvItem") with no retry timeout. Selection animations could cause timing differences between runs.

Recommendation:

VerifyScreenshot(retryTimeout: TimeSpan.FromSeconds(2));

Positives

• Both CV1 () and CV2 () handlers updated identically
• extension method is semantically clear and correctly defined
• All existing safety guards preserved in the (runtime) path
• Excellent PR description with root cause, edge cases, and failure guidance
• Cross-platform: fix applies to both deprecated and current handler

---

Recommendation

** APPROVE with suggestions**

The PR's core fix is correct, well-tested, and well-documented. The main concern is the missing safety guards in the !IsLoaded() completion handler. This is a low-risk issue (initial load mutations are rare) but should be addressed to maintain correctness guarantees.

---

📋 Expand PR Finalization Review

---

Title: ✅ Good

Current: [iOS] Fix: CollectionView does not clear selection when SelectedItem is set to null

Description: ✅ Excellent

Description needs updates. See details below.

Code Review: ✅ Passed

Code Review — PR #30420

Files reviewed:

• src/Controls/src/Core/Handlers/Items/iOS/SelectableItemsViewController.cs
• src/Controls/src/Core/Handlers/Items2/iOS/SelectableItemsViewController2.cs
• src/Controls/tests/TestCases.HostApp/Issues/Issue30363.cs
• src/Controls/tests/TestCases.HostApp/Issues/Issue26187.cs
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue30363.cs

---

🟡 Suggestions

1. Initial-load path lost safety guards from original implementation

Files: Both SelectableItemsViewController.cs and SelectableItemsViewController2.cs

Problem:
The original code had these safety checks inside the PerformBatchUpdates completion handler (which ran for all scenarios):

1. if (ItemsSource is EmptySource) return;
2. if (!ReferenceEquals(ItemsView.ItemsSource, originalSource)) return;
3. Index recalculation after source changes
4. Item equality check at the new index

After the PR, the !IsLoaded() (initial load) branch wraps SelectItem in PerformBatchUpdates but without any of these guards. All guards are now exclusively in the else/runtime branch.

Before:

CollectionView.PerformBatchUpdates(null, _ =>
{
    if (ItemsSource is EmptySource)
        return;
    // ... reference equality check ...
    // ... index recalculation ...
    CollectionView.SelectItem(index, true, UICollectionViewScrollPosition.None);
});

After:

if (!CollectionView.IsLoaded())
{
    CollectionView.PerformBatchUpdates(null, _ =>
    {
        // NO safety checks here
        CollectionView.SelectItem(index, true, UICollectionViewScrollPosition.None);
    });
}
else
{
    // All safety checks here
    if (ItemsSource is EmptySource) return;
    // ...
    CollectionView.SelectItem(index, true, UICollectionViewScrollPosition.None);
}

Risk: Low for typical use, but if ItemsSource is disposed or replaced before the view is loaded (edge case), a crash or stale-index selection could occur.

Recommendation: Consider also guarding the initial-load path with at minimum the EmptySource check, or add a comment explicitly acknowledging the trade-off:

if (!CollectionView.IsLoaded())
{
    CollectionView.PerformBatchUpdates(null, _ =>
    {
        // Safety checks are omitted for initial load since the source is
        // expected to be stable; runtime path includes full validation.
        CollectionView.SelectItem(index, true, UICollectionViewScrollPosition.None);
    });
}

---

2. Navigation.PushAsync changed from awaited to fire-and-forget in Issue26187.cs

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

Problem:

// Before
async void CollectionView_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    if (e.CurrentSelection.FirstOrDefault() is string issue)
    {
        await Navigation.PushAsync(new NewPage(issue));
    }
    // ...
}

// After
void CollectionView_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    if (e.CurrentSelection.FirstOrDefault() is string issue)
    {
        Navigation.PushAsync(new NewPage(issue));  // fire-and-forget
    }
    // ...
}

Risk: Low for test code, but if PushAsync throws, the exception will be unobserved. In a UI test context, this could mask failures.

Recommendation: This is test-only code and the risk is minimal. Acceptable as-is, but _ = Navigation.PushAsync(...) would make the intent explicit.

---

3. UI test uses non-unique AutomationId for CollectionView items

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue30363.cs
Related: src/Controls/tests/TestCases.HostApp/Issues/Issue30363.cs

Problem:
The DataTemplate sets AutomationId = "cvItem" on a label inside each cell. All 5 items share the same AutomationId. App.WaitForElement("cvItem") and App.Tap("cvItem") will always interact with the first matching element.

Risk: Low — tapping the first item is sufficient to reproduce the bug. The test still validates the scenario correctly via screenshot.

Recommendation: This is a common pattern in CollectionView UI tests and is acceptable. No change required.

---

4. UI test relies solely on screenshot verification without explicit deselection assertion

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

Problem:

public void CollectionViewSelectionShouldClear()
{
    App.WaitForElement("cvItem");
    App.Tap("cvItem");
    VerifyScreenshot();
}

The test taps an item (triggering SelectionChanged which sets SelectedItem = null) and then takes a screenshot. If the visual difference between "item selected" and "item deselected" is subtle (e.g., highlight color), the screenshot comparison may not robustly catch regressions.

Risk: Low for current scenarios — screenshot baselines are pre-captured and will catch visual changes. However, if items have no visible selection highlight, the screenshot wouldn't distinguish pass from fail without the baseline.

Recommendation: Consider adding an intermediate step to verify the item is visually deselected, e.g., checking a label text update or using retryTimeout for screenshot stability:

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

---

✅ Looks Good

• Symmetry: Both Items/ and Items2/ handler files are updated identically, maintaining consistency across deprecated and current iOS handlers (as expected per collectionview-handler-detection.instructions.md — Items/ is for Android/Windows, Items2/ is for iOS/MacCatalyst; both iOS implementations are correctly updated).
• Logic is correct: The IsLoaded() condition (UIView.Window != null) correctly distinguishes initial load from runtime. The description's rationale is sound.
• No breaking API changes: The fix is purely internal/behavioral.
• Both issues covered: #30363 (new test) and #26187 (existing test updated) are both addressed.
• Android snapshot added: Confirms Android behavior is unchanged (regression test).
• Platform scope: Fix is correctly scoped to iOS only ([iOS] prefix, .iOS.cs files only).

---

[Tamilarasan-Paranthaman]

🤖 AI Summary

📊 Expand Full Review

Recommendation

** APPROVE with suggestions**

The PR's core fix is correct, well-tested, and well-documented. The main concern is the missing safety guards in the !IsLoaded() completion handler. This is a low-risk issue (initial load mutations are rare) but should be addressed to maintain correctness guarantees.

📋 Expand PR Finalization Review
Title: ✅ Good

Current: [iOS] Fix: CollectionView does not clear selection when SelectedItem is set to null

Description: ✅ Excellent

Description needs updates. See details below.

Code Review: ✅ Passed

Code Review — PR #30420

Files reviewed:

• src/Controls/src/Core/Handlers/Items/iOS/SelectableItemsViewController.cs
• src/Controls/src/Core/Handlers/Items2/iOS/SelectableItemsViewController2.cs
• src/Controls/tests/TestCases.HostApp/Issues/Issue30363.cs
• src/Controls/tests/TestCases.HostApp/Issues/Issue26187.cs
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue30363.cs

🟡 Suggestions

1. Initial-load path lost safety guards from original implementation

Files: Both SelectableItemsViewController.cs and SelectableItemsViewController2.cs

Problem: The original code had these safety checks inside the PerformBatchUpdates completion handler (which ran for all scenarios):

1. if (ItemsSource is EmptySource) return;
2. if (!ReferenceEquals(ItemsView.ItemsSource, originalSource)) return;
3. Index recalculation after source changes
4. Item equality check at the new index

After the PR, the !IsLoaded() (initial load) branch wraps SelectItem in PerformBatchUpdates but without any of these guards. All guards are now exclusively in the else/runtime branch.

Before:

CollectionView.PerformBatchUpdates(null, _ =>
{
    if (ItemsSource is EmptySource)
        return;
    // ... reference equality check ...
    // ... index recalculation ...
    CollectionView.SelectItem(index, true, UICollectionViewScrollPosition.None);
});

After:

if (!CollectionView.IsLoaded())
{
    CollectionView.PerformBatchUpdates(null, _ =>
    {
        // NO safety checks here
        CollectionView.SelectItem(index, true, UICollectionViewScrollPosition.None);
    });
}
else
{
    // All safety checks here
    if (ItemsSource is EmptySource) return;
    // ...
    CollectionView.SelectItem(index, true, UICollectionViewScrollPosition.None);
}

Risk: Low for typical use, but if ItemsSource is disposed or replaced before the view is loaded (edge case), a crash or stale-index selection could occur.

Recommendation: Consider also guarding the initial-load path with at minimum the EmptySource check, or add a comment explicitly acknowledging the trade-off:

if (!CollectionView.IsLoaded())
{
    CollectionView.PerformBatchUpdates(null, _ =>
    {
        // Safety checks are omitted for initial load since the source is
        // expected to be stable; runtime path includes full validation.
        CollectionView.SelectItem(index, true, UICollectionViewScrollPosition.None);
    });
}

2. Navigation.PushAsync changed from awaited to fire-and-forget in Issue26187.cs

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

Problem:

// Before
async void CollectionView_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    if (e.CurrentSelection.FirstOrDefault() is string issue)
    {
        await Navigation.PushAsync(new NewPage(issue));
    }
    // ...
}

// After
void CollectionView_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    if (e.CurrentSelection.FirstOrDefault() is string issue)
    {
        Navigation.PushAsync(new NewPage(issue));  // fire-and-forget
    }
    // ...
}

Risk: Low for test code, but if PushAsync throws, the exception will be unobserved. In a UI test context, this could mask failures.

Recommendation: This is test-only code and the risk is minimal. Acceptable as-is, but _ = Navigation.PushAsync(...) would make the intent explicit.

3. UI test uses non-unique AutomationId for CollectionView items

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue30363.cs Related: src/Controls/tests/TestCases.HostApp/Issues/Issue30363.cs

Problem: The DataTemplate sets AutomationId = "cvItem" on a label inside each cell. All 5 items share the same AutomationId. App.WaitForElement("cvItem") and App.Tap("cvItem") will always interact with the first matching element.

Risk: Low — tapping the first item is sufficient to reproduce the bug. The test still validates the scenario correctly via screenshot.

Recommendation: This is a common pattern in CollectionView UI tests and is acceptable. No change required.

4. UI test relies solely on screenshot verification without explicit deselection assertion

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

Problem:

public void CollectionViewSelectionShouldClear()
{
    App.WaitForElement("cvItem");
    App.Tap("cvItem");
    VerifyScreenshot();
}

The test taps an item (triggering SelectionChanged which sets SelectedItem = null) and then takes a screenshot. If the visual difference between "item selected" and "item deselected" is subtle (e.g., highlight color), the screenshot comparison may not robustly catch regressions.

Risk: Low for current scenarios — screenshot baselines are pre-captured and will catch visual changes. However, if items have no visible selection highlight, the screenshot wouldn't distinguish pass from fail without the baseline.

Recommendation: Consider adding an intermediate step to verify the item is visually deselected, e.g., checking a label text update or using retryTimeout for screenshot stability:

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

✅ Looks Good

• Symmetry: Both Items/ and Items2/ handler files are updated identically, maintaining consistency across deprecated and current iOS handlers (as expected per collectionview-handler-detection.instructions.md — Items/ is for Android/Windows, Items2/ is for iOS/MacCatalyst; both iOS implementations are correctly updated).
• Logic is correct: The IsLoaded() condition (UIView.Window != null) correctly distinguishes initial load from runtime. The description's rationale is sound.
• No breaking API changes: The fix is purely internal/behavioral.
• Both issues covered: CollectionView not being able to remove selected item highlight on iOS #30363 (new test) and [MAUI] Select items traces are preserved #26187 (existing test updated) are both addressed.
• Android snapshot added: Confirms Android behavior is unchanged (regression test).
• Platform scope: Fix is correctly scoped to iOS only ([iOS] prefix, .iOS.cs files only).

@kubaflo, as suggested by the agent, the safety guards have been moved into the !IsLoaded() completion handler as well (similar to the IsLoaded() path), and the code has been further optimized to remove duplicates.

Also, retryTimeout has been added to VerifyScreenshot.