[iOS] StatusBarBehavior does not occupy entire notch - fix

[kubaflo]

Description of Change

I've encountered this bug while working with MAUI: dotnet/maui#24972 and it turns out that it is rather an issue that should be linked to this repository.

Basically the status bar is wrong for some screens. I've found this comments here: https://forums.developer.apple.com/forums/thread/662466

It makes sense because when I based the status bar height on the top safe area I have the following result:

Expected	Before	After

Linked Issues

• Fixes [BUG] StatusBarBehavior does not occupy entire notch for modal pages when NavigationPage.HasNavigationBar="False" (iOS) #2287

It might also fix this one: dotnet/maui#25435, but I'm not 100% sure if it is a status bar's or MAUI's issue. Maybe even both

PR Checklist

• Has a linked Issue, and the Issue has been approved(bug) or Championed (feature/proposal)
• Has tests (if omitted, state reason in description)
• Has samples (if omitted, state reason in description)
• Rebased on top of main at time of PR
• Changes adhere to coding standard
• Documentation created or updated: https://github.com/MicrosoftDocs/CommunityToolkit/pulls

Additional information

[pictos]

LGTM

[TheCodeTraveler]

The StatusBar overlaps the navigation bar in the After photo.

To help visualize this, I've added a green bar in the photo below that is the same height as the NavigationBar. The green bar is the same height in both the Before and After image.

[TheCodeTraveler]

Please link to a bug (or open a new Issue) in our GitHub repo to help us understand + reproduce the problem you are trying to fix.

Please also update edit the title of this PR; Improve status bar does not explain the bug or the proposed solution.

Please ensure the status bar does not overlap the navigation bar

This PR increases the size of the StatusBar where it now overlaps the NavigationBar

[kubaflo]

Please link to a bug (or open a new Issue) in our GitHub repo to help us understand + reproduce the problem you are trying to fix.

Please also update edit the title of this PR; Improve status bar does not explain the bug or the proposed solution.

Please ensure the status bar does not overlap the navigation bar

Yea, but it is the iOS's native behaviour. Generally status bar should have the same color as the navigation bar. The only point for customising it is when we don't have a navigation bar. And the current MCT solution would give the following outcome:

[Axemasta]

Please link to a bug (or open a new Issue) in our GitHub repo to help us understand + reproduce the problem you are trying to fix.

This is the issue #2287, Originally I thought it was a maui issue but its not and actually a status bar behaviour issue, since the repro app doesn't apply the padding when not using the behavior

[jfversluis]

Another report of this bug: dotnet/maui#25435

Additionally I also ran into this myself while working on the https://github.com/jfversluis/blazor-hybrid-workshop

[kubaflo]

Hi! Any update concerning this PR?

[pictos]

@brminnick what do you think about @kubaflo's answer?

[TheCodeTraveler]

This is a tough one. Both the Community Toolkit and .NET MAUI are correctly using SafeAreaInserts. This appears to be how iOS has designed their operating system UI.

I've searched Apple's Human Interface Design Guidelines to learn more about their recommendations around the status bar and modality, but they don't provide any specific instructions.

Since this "bug" only seems to affect Modal Pages, my recommendation is to use PageSheet for modal all modal pages on iOS. I've provided the code here: #2287 (comment)

My vote is to close both this PR and the Issue as this is the design that Apple is pushing us developers into.

[TheCodeTraveler]

Hi! Any update concerning this PR?

To answer @kubaflo's question, we are blocked from merging any PRs until we are able to merge our .NET 9 PR which is currently blocked by a bug in .NET MAUI.

Once the MAUI engineering team resolves this bug, we will be unblocked and can resume merging PRs for the Community Toolkit: dotnet/maui#25871

[kubaflo]

Okay, @brminnick do whatever you think is the best :) But I don't think it happens only on modal pages, it happens on pages without a navigation bar

[Axemasta]

I'm thinking about this PR because I've just forked this behaviour and had to make this change as I can't live with the random line between my nav bar and notch and it got me thinking...

Should we add a toggle option for iOS to use the safe area:
statusBarBehavior.On<iOS>().UseSafeArea(true)

The default behavior would be to use the status bar frame, and the override would use the top of the safe area. This way we have a fix for this issue, which IS quite common. We don't force developers down the road of making all modals PageSheets (there are still some rough edges with using these in Maui...) and we keep the default implementation as is!

@brminnick thoughts?

[TheCodeTraveler]

Should we add a toggle option for iOS to use the safe area:
statusBarBehavior.On().UseSafeArea(true)

@Axemasta That actually makes a lot of sense! Do you have a proof-of-concept with it working that I could dig into?

[Axemasta]

I've put together a proof of concept although to be totally honest I think adding a BindableProperty named iOSUseSafeArea might just be easier.

Proof of concept is here, annoyingly the IPlatformElementConfiguration generic is constrained to Element so we can apply one directly to our behavior. We can however apply the configuration to the element we apply our behavior to & read it from there...

For the proof of concept:

• Create behavior
• Add a platform specific config class with:
  • Bindable property
  • Get / Set methods
  • Extension method to easily set against an element using IPlatformConfiguration api
• Apply behavior to element
• Call platform specific tweak

In the specific case of the StatusBarBehavior using this approach, our element config could apply to the page, so we would have an ios config such as mct:Page.StatusBarShouldUseSafeArea="true" in our xaml.

Looking at the current implementation of status bar, we'd probably want to pass the BindableObject reference through to the platform, so that the iOS platform code can lookup whether the user has opted into the feature flag and then apply:

if (StatusBarIosConfiguration.GetUseSafeArea(bindable))
{
	new CGRect(statusBar.Frame.X, statusBar.Frame.Y, statusBar.Frame.Width, window.SafeAreaInsets.Top);
}
else
{
	statusBar.Frame = UIApplication.SharedApplication.StatusBarFrame;
}

Adding a toggle to the page might be a bit confusing, I was hoping it wouldn't be as messy as it turned out to be (accounting for the Element constraint.

[jfversluis]

@kubaflo @Axemasta as discussed yesterday on the .NET MAUI Community Toolkit standup, if we compare the behavior with the behavior of native iOS apps this seems to be correct.

Reading through this I think the suggestion by @Axemasta makes a lot of sense! Do we need a separate setting? Can't we just look at the .NET MAUI configured setting for this on the page that we're on and decide based on that? But I'm fine with adding a platform-specific setting for this too.

Can we make that happen? :)

[kubaflo]

I've added

xmlns:ios="clr-namespace:CommunityToolkit.Maui.PlatformConfiguration.iOSSpecific;assembly=CommunityToolkit.Maui"
ios:StatusBar.UseSafeArea="True"

Let me know what you think :)

Stale

[TheCodeTraveler]

Thanks @kubaflo! Approved

[TheCodeTraveler]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).