Secondary Order ToolbarItems not displayed correctly on iOS

[ewerspej]

Description

On iOS, ToolbarItems that have their Order="Secondary" are not displayed in the secondary level menu bar. Instead, they appear in line with the Primary items.

I have the following XAML setup:

<ContentPage.ToolbarItems>
  <ToolbarItem Command="{Binding SetLowBrightnessCommand}">
    <ToolbarItem.IconImageSource>
      <FontImageSource
        FontFamily="MaterialIconsOutlined-Regular"
        Glyph="&#xe51c;"
        Color="LightBlue"
        Size="20"/>
    </ToolbarItem.IconImageSource>
  </ToolbarItem>
  <ToolbarItem Command="{Binding SetHighBrightnessCommand}">
    <ToolbarItem.IconImageSource>
      <FontImageSource
        FontFamily="MaterialIconsOutlined-Regular"
        Glyph="&#xe518;"
        Color="LightPink"
        Size="32"/>
    </ToolbarItem.IconImageSource>
  </ToolbarItem>
  <ToolbarItem
    Order="Secondary"
    Text="Item 3" />
  <ToolbarItem
    Order="Secondary"
    Text="Item 4" />
</ContentPage.ToolbarItems>

On iOS the secondary items (Item 3, Item 4) are incorrectly displayed in the same level as the icons, which shouldn't be the case:

On Android it works as expected:

Steps to Reproduce

1. Create new MAUI project
2. On MainPage, set <ContentPage.ToolbarItems>
3. Add some instances of ToolbarItem with default setting or Order="Primary"
4. Add one or more instances of ToolbarItem with Order="Secondary"
5. Observe the incorrect behavior on iOS

Link to public reproduction project repository

https://github.com/ewerspej/maui-samples/

Version with bug

7.0 (current)

Last version that worked well

Unknown/Other

Affected platforms

iOS

Affected platform versions

iOS 16 (and possibly earlier versions)

Did you find any workaround?

No

Relevant log output

n/a

[frogcrush]

I am also having this issue, and have not found a workaround. This is blocking our app from going live.

[MichaelSL]

I have the same issue, no workaround yet.

[ooikengsiang]

The primary reason is iOS doesn't support drop-down menu from title bar by default. I look into the source code, no flyout menu implemented, so this feature is not broken in iOS, but more like unsupported.

[ewerspej]

The primary reason is iOS doesn't support drop-down menu from title bar by default. I look into the source code, no flyout menu implemented, so this feature is not broken in iOS, but more like unsupported.

That's unlikely, because it works in Xamarin.Forms AFAIK, it just looks different on iOS than it does on Android, which is fine.

Not implemented doesn't mean not supported. In any case, the current behavior appears broken, no matter whether it's because of a bug or because of a lack of implementation, it cannot stay like this, because otherwise the Order property is rendered useless.

[ewerspej]

@thatkidyousaw1 No, I am not aware of a working workaround. However, I have also not invested much time into finding one, because this needs to work out-of-the-box. It's clearly broken and I am categorically against workarounds for fundamental things. Workarounds for smaller bugs and issues are fine, but this is a showstopper for this feature and renders it utterly useless.

[XamlTest]

Verified this on Visual Studio Enterprise 17.7.0 Preview 2.0. Repro on iOS 16.4 with below Project: https://github.com/ewerspej/maui-samples/

[ewerspej]

Verified this on Visual Studio Enterprise 17.7.0 Preview 2.0. Repro on iOS 16.4 with below Project: https://github.com/ewerspej/maui-samples/

Yes, it should still be reproducible there. However, note that I've recently added Shane's Workarounds NuGet package, which fixes a couple of things temporarily. The issue described here is not affected by that, though.

[malsabi]

This issue is still active in .NET 8 Core RC1

[andreas-spindler-mw]

Still active in .NET 8.0.100

[pandaloupe]

I'm pretty sure this wasn't supported in XamForms either. There are workarounds which make use of a custom page renderer like this one https://github.com/AmitManchanda/iOSSecondaryToolbarMenubar I haven't seen a proper implementation of that for MAUI so far which would be a Handler rather than a Renderer as I understand it.

[AlleSchonWeg]

There is a request open for a long time: https://github.com/dotnet/maui/issues/815 Starting with iOS 14.1 something similar is possible: https://developer.apple.com/documentation/uikit/uinavigationcontroller/customizing_your_app_s_navigation_bar#3950610 It looks a lot better as the maui/xf secondary toolbar items: https://nemecek.be/blog/85/how-to-show-uimenu-from-uibutton-or-uibarbuttonitem

[ewerspej]

I'm pretty sure this wasn't supported in XamForms either. There are workarounds which make use of a custom page renderer like this one https://github.com/AmitManchanda/iOSSecondaryToolbarMenubar I haven't seen a proper implementation of that for MAUI so far which would be a Handler rather than a Renderer as I understand it.

Indeed, in Xamarin.Forms it wasn't the same on iOS and Android. However, the secondary items were displayed in a proper fashion on iOS, not like it's now with MAUI. In either case, the secondary items shouldn't just be added to the navigation bar like in the screenshot, because they will eventually fill up the entire navigation bar with text.

[bzd3y]

I can confirm that this did work in Xamarin. And in MAUI they are actually displayed correctly when using a FlyoutPage with Detail set to a NavigationPage.

However, then the secondary toolbar items cover up the contents of the page.

[tataelm]

this is still an issue. Is there any progress with this?

[samhouts]

We recognize that this is an omission from Xamarin.Forms, so it takes a high priority. As some have noted, this functionality didn't really exist in iOS at the time, so the manner in which we implemented it in Xamarin.Forms was not ideal; that's why it wasn't brought over to .NET MAUI. Now that iOS has provided us with APIs that we can use, we believe that you'll be much happier if we do not bring over the same functionality from Xamarin.Forms and instead implement #815.

I'm going to mark this as a duplicate of #815, and we'll work to get it prioritized.

Thanks for your patience!

[samhouts]

Duplicate of #815

[ewerspej]

@samhouts Thanks for taking time to figure out the best option for iOS. I agree that the proposed approach in #815 is indeed better compared to the XF solution.