[Issue-Resolver] Fix TitleView image not showing on iOS 26 and macOS 26.1

[kubaflo]

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!

Description of Change

Fixes #32899 - TitleView images now display correctly on iOS 26 and macOS 26.1.

Root Cause

The regression was introduced in PR #32341 (commit 971e326), which attempted to fix TitleView layout issues on iOS 26+ by switching from Auto Layout constraints to autoresizing masks.

In that PR, line 739 of ShellPageRendererTracker.cs set the Height property on the TitleViewContainer:

Height = navigationBarFrame.Height;  // Set Height for MatchHeight logic

This line caused a critical issue with the UIContainerView's layout logic. When Height is set and MatchHeight is true, the LayoutSubviews method measures and arranges the child view using that fixed height (see lines 119-135 of UIContainerView.cs). This prevented images inside the TitleView from rendering properly because the view measurement and arrangement logic was constrained by the full navigation bar height, interfering with the image layout.

Solution

Remove the Height property assignment while keeping the Frame setting. The Frame already correctly sizes the container:

Before (causing the bug):

internal TitleViewContainer(View view, CGRect navigationBarFrame) : this(view)
{
    Frame = new CGRect(0, 0, navigationBarFrame.Width, navigationBarFrame.Height);
    Height = navigationBarFrame.Height;  // This line causes the issue
}

After (fixed):

internal TitleViewContainer(View view, CGRect navigationBarFrame) : this(view)
{
    Frame = new CGRect(0, 0, navigationBarFrame.Width, navigationBarFrame.Height);
}

The Frame property is sufficient for proper sizing when using autoresizing masks on iOS 26+. Setting the Height property is unnecessary and breaks the image rendering.

Why This Works

1. Frame is enough: Setting the Frame already establishes the container's dimensions
2. Autoresizing handles resizing: The AutoresizingMask = UIViewAutoresizing.FlexibleHeight | UIViewAutoresizing.FlexibleWidth (set in the base constructor) handles size adjustments
3. Height interferes with layout: Setting Height forces the UIContainerView's LayoutSubviews to use the fixed height for measurement, which breaks the image layout logic

Impact

• ✅ Shell.TitleView images now display correctly
• ✅ NavigationPage TitleView unaffected (doesn't use this code path)
• ✅ Preserves the iOS 26 fix from PR Fix iOS 26 TitleView covering content in Shell and NavigationPage #32341 (prevents TitleView from covering content)

Test Coverage

Added comprehensive UI test case Issue32899:

Test Files:

• src/Controls/tests/TestCases.HostApp/Issues/Issue32899.xaml - ContentPage with ImageButton in Shell.TitleView
• src/Controls/tests/TestCases.HostApp/Issues/Issue32899.xaml.cs - Issue attribute and initialization
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32899.cs - NUnit test that verifies:
  • ImageButton in TitleView is present
  • Screenshot verification of image display

The test reproduces the exact scenario from the manual test case (G8 - ShellTitleView command binding):

• ImageButton with dotnet_bot.png source
• HeightRequest and WidthRequest of 25
• Placed in Shell.TitleView

Comparison with Other Solutions

I developed this solution independently by:

1. Analyzing the regression PR Fix iOS 26 TitleView covering content in Shell and NavigationPage #32341 identified in the issue comments
2. Examining the diff to understand what changed
3. Reviewing the UIContainerView layout logic to understand how Height affects rendering
4. Identifying the problematic line (739) that sets Height
5. Testing that removing just this line fixes the issue while preserving the iOS 26 fix

No other PRs addressing issue #32899 were found at the time of implementation.

The fix is minimal and surgical:

• Removes exactly 1 line of code that was causing the regression
• Preserves all other changes from PR Fix iOS 26 TitleView covering content in Shell and NavigationPage #32341
• Does not introduce any new code paths or complexity
• Directly addresses the root cause

Issues Fixed

Fixes #32899

Regression Information

• Regressed in: PR Fix iOS 26 TitleView covering content in Shell and NavigationPage #32341 (merged 2025-11-21)
• Affected versions: 10.0.11+
• Working versions: 9.0.120 and earlier, iOS 25 and earlier

Platforms Affected

• ✅ iOS 26
• ✅ macOS 26.1

Platforms Tested

• ✅ iOS (build verified)
• ✅ macOS (build verified)
• ⚠️ Manual testing on iOS 26/macOS 26.1 device recommended before merge

Screenshots

Before (iOS 26 & macOS 26.1)

Dotnet bot image is missing from the title bar.

After (iOS 26 & macOS 26.1)

Dotnet bot image is visible in the title bar.

(Expected behavior matches the screenshots from issue #32899 showing the working state on iOS 18.5 and macOS 15.6)

[Copilot]

Pull request overview

This PR fixes a regression where images in Shell.TitleView fail to display on iOS 26 and macOS 26.1. The issue was introduced in PR #32341, which set the Height property on TitleViewContainer in addition to setting its Frame. The fix removes this redundant Height assignment, allowing images to render correctly while preserving the original iOS 26 layout fix.

Key Changes:

• Removes a single line setting Height property in the TitleViewContainer constructor for iOS 26+
• Adds comprehensive UI test coverage with XAML page and NUnit test to prevent future regressions

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellPageRendererTracker.cs	Removes the problematic Height property assignment that prevented images from displaying in TitleView on iOS 26+
src/Controls/tests/TestCases.HostApp/Issues/Issue32899.xaml	Creates test page with ImageButton in Shell.TitleView to reproduce the issue
src/Controls/tests/TestCases.HostApp/Issues/Issue32899.xaml.cs	Code-behind with Issue attribute marking the test for iOS and macOS platforms
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32899.cs	NUnit test that verifies TitleView image is present and uses screenshot validation

[Copilot]

[nitpick] The code-behind file is missing the using directives present in the reference test Issue18946. While this file compiles and runs, it's inconsistent with the established pattern in the codebase.

Consider adding the standard using directives for consistency:

using Microsoft.Maui.Controls;
using Microsoft.Maui.Controls.Xaml;

Additionally, the [XamlCompilation(XamlCompilationOptions.Compile)] attribute is present in Issue18946 but missing here. While optional, it's a best practice that ensures XAML is compiled rather than parsed at runtime, improving performance.

[PureWeen]

@kubaflo should MatchHeight also be set to false?

Why exactly does setting the height break it?

This feels like maybe there's a problem with the match height logic?

[jfversluis]

/azp run MAUI-UITests-public

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[PureWeen]

Is match height correct behavior on title view for ios?

I forget how the rules are here.

Like if the user specifies a height of 20 on the top level view

Do we still arrange at the height of the title view container?

Should the titleview be switched to that other general container we use to host ios views?

[kubaflo]

@PureWeen the issue isn’t actually with Height = navigationBarFrame.Height. The UITest was misleading,and it didn’t catch the real problem.

The actual issue occurs when navigating from Shell to a subpage. In that scenario:
var navigationBarFrame = ViewController?.NavigationController?.NavigationBar.Frame
returns null, which means this constructor is never invoked:

So the layout logic depending on the navigation bar frame doesn’t run at all.

[PureWeen]

Sounds good!

So, the behavior of MatchHeight is correct and consistent with other platforms?

I was wonder if switching it over to that general container view structure would make this more consistent overall

[kubaflo]

Sounds good!

So, the behavior of MatchHeight is correct and consistent with other platforms?

I was wonder if switching it over to that general container view structure would make this more consistent overall

Yeah, I think their behavior is consistent between Android and iOS