CollectionView (grouped): EmptyView handling is wrong when groups become empty

Description

When a grouped CollectionView (IsGrouped="True") is bound to an ObservableCollection of groups, the EmptyView behavior is inconsistent across platforms:

iOS: the EmptyView is rendered on top of the list as soon as all groups are empty, even though groups still exist.
Android: the EmptyView is never shown when the last group is removed at runtime, so an empty list displays nothing.

Steps to Reproduce

Minimal repro project: MauiAppCollectionViewEmptyView (net10.0, Microsoft.Maui.Controls 10.0.90).

Setup:

CollectionView with IsGrouped="True".
ItemsSource = ObservableCollection<ItemGroup>, where ItemGroup derives from ObservableCollection<string> (each group is enumerable and observable).
GroupHeaderTemplate (group title + "± Item" buttons), GroupFooterTemplate (a message when the group is empty), ItemTemplate, and an EmptyView declared in XAML.
Top bar: "+ Group" / "- Group" buttons.

iOS — EmptyView shown over the list when all groups are empty

Launch on iOS.
Tap "+ Group" (the group is created with one item).
Tap "- Item" so the group becomes empty. A group still exists.
Expected: the EmptyView must NOT be displayed (there is at least one group; an empty group is already signaled by its footer).
Actual: the EmptyView is displayed on top of the CollectionView.

Android — EmptyView never shown after removing the last group

Launch on Android.
Tap "+ Group".
Tap "- Group" until no groups remain.
Expected: the EmptyView is displayed (the collection is now empty).
Actual: the collection is empty but the EmptyView never appears.

Note: on Android, initializing the ItemsSource as empty from the start does display the EmptyView. The bug only occurs when groups are removed dynamically through the ObservableCollection.

Link to public reproduction project repository

https://github.com/tranb3r/Issues/tree/main/MauiAppCollectionViewEmptyView

Version with bug

10.0.90

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

No response

Affected platforms

iOS, Android

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

This issue has been validated in Visual Studio Code 1.133.0 with .NET MAUI versions 10.0.60, 10.0.80 and 10.0.90. It can be reproduced on the iOS and Android platforms. I have attached output video below:

Issue reproduced Output

In Android	In iOS
Screen.Recording.2026-08-14.at.7.55.44.PM.mov	Screen.Recording.2026-08-14.at.7.56.31.PM.mov

@tranb3r

Thanks for the focused reproduction, @tranb3r. I reproduced both behaviors with your project on iPhone 16 Pro / iOS 18.4 and Pixel 9 Pro / Android 16, and opened #37439 with a fix and regression coverage for Android plus both iOS CollectionView handlers.

The root causes were platform-specific:

iOS used the flattened leaf-item count for EmptyView, so an existing group with zero items was incorrectly treated as an empty grouped source.
Android notified RecyclerView before refreshing its tracked groups, so the EmptyView observer saw the stale group count when the final group was removed.

The fix consistently defines a grouped source as empty only when it has zero outer groups. I linked your app directly to the patched framework, replayed the exact scenarios through Appium, asserted the native accessibility trees, and repeated the transitions five times on each platform.

iOS 18.4

Before	After

Android 16

Before	After

When the PR's build artifacts become available, please try them with your project and let us know whether the behavior also resolves the issue in your environment.

Thank you, Gerald! This was crazy fast — really appreciate it! 🙌

@tranb3r

Follow-up after PR review: I addressed all feedback in #37439 and reran the reporter project against the final source on iOS 18.4 and Android 16.

iOS final-item removal: the native tree contains Group 1 and no EMPTY VIEW: https://github.com/user-attachments/assets/0552ec1c-009e-4cb6-b901-63af611decc1
Android final-group removal: EMPTY VIEW appears immediately: https://github.com/user-attachments/assets/9ca9f347-c6a0-437a-ac71-59017543c229

One visual clarification: the italic This group is empty. text in the iOS after image is the sample app's GroupFooterTemplate (Padding="10,0,10,10"), not the EmptyView. The before image showed the actual bug, where the bold EMPTY VIEW and No groups to display. overlaid the group header/footer.

The tests now use eventual assertions, cover direct removal of the final empty group and a populated two-item group, and avoid Android full refreshes unless the outer group count crosses zero. Independent final reviews found no actionable issues.

@tranb3r, once updated CI artifacts are available from #37439, please try them with your project and let us know whether both platform scenarios behave correctly for you.

Publish reproduction evidence for #37429 on android

@jfversluis

@tranb3r, once updated CI artifacts are available from #37439, please try them with your project and let us know whether both platform scenarios behave correctly for you.

@jfversluis
I've just tested the PR artifacts, and the fix works perfectly on both platforms. Thanks again.
Is there any reason why the PR was closed?

Publish reproduction evidence for #37429 on android

[Android] CollectionView: Fix grouped EmptyView updates (#37954)

Thank you for the report and the investigation details. We are closing this as completed: both grouped CollectionView EmptyView corrections have merged, and the reporter confirmed that they work in 10.0.110-ci.inflight.26430.9. The later stable-10.0.110 discussion concerns release inclusion, not failure of those fixed nightlies.

Supporting evidence: #37954 (merged into inflight/current), #37959 (merged into inflight/current).

This records the merged source change; it does not imply that the fix is present in every released .NET MAUI package.

If you can still reproduce the reported behavior in a build that includes the linked change, please comment here with the exact version and reproduction details so we can reopen and investigate. The existing reproduction and discussion remain available; a new issue is not required.