[iOS, Mac] Fix for RadioButton TextColor for plain Content not working

[HarishwaranVijayakumar]

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!

Issue Details

• RadioButton TextColor not working on iOS when Label styles are present in Styles.xaml

Root Cause of the issue

• When a RadioButton has plain string content (e.g., Content = "some text"), ContentConverter.ConvertToLabel creates a Label to display it and then binds the RadioButton's TextColor to the label via BindTextProperties. The binding is only applied if ShouldSetBinding confirms the property is not already set.

• The bug: if the application has a global implicit Label style (e.g., in App.xaml) that sets TextColor, and that style has ApplyToDerivedTypes = true (the default for implicit styles), MAUI applies it to the newly-created Label before the binding is set up. When ShouldSetBinding then checks IsSet(TextColorProperty), it finds the style has already set the property and skips setting the binding — leaving the RadioButton's own TextColor ignored.

Description of Change

Bug fix: Prevent global Label styles from interfering with RadioButton text color

• Introduced a new internal ContentLabel class in ContentConverter.cs that uses a self-hosted empty style to block inherited global Label styles, ensuring that RadioButton text color is not overridden.
• Updated the ConvertToLabel method in ContentConverter.cs to use ContentLabel instead of Label for plain text content, preventing interference from global styles.

Testing and verification

• Added a UI test in TestCases.Shared.Tests/Tests/Issues/Issue18011.cs to verify that the RadioButton text color is not overridden by global Label styles.
• Added a sample test case in TestCases.HostApp/Issues/Issue18011.cs that sets a global Label style and demonstrates the issue, confirming the fix and cleaning up styles after the test.

Issues Fixed

Fixes #18011

Tested the behaviour in the following platforms

• - Windows
• - Android
• - iOS
• - Mac

Output

Before	After

[Copilot]

Pull Request Overview

This PR fixes an issue where RadioButton TextColor property was not working on iOS/Mac when global Label styles were present in the application. The problem occurred because RadioButtons use ContentPresenter to display string content, which converts the string to a Label that inherits global Label styles, overriding the intended TextColor.

• Created a new ContentLabel subclass of Label to bypass global Label styles
• Updated the ConvertToLabel method to use ContentLabel instead of Label
• Added explanatory comments for the workaround approach

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Add baseimages · 95167d9

---

Issue: #18011 - RadioButton: TextColor for plain Content not working on iOS
PR: #31940 - [iOS, Mac] Fix for RadioButton TextColor for plain Content not working
Author: HarishwaranVijayakumar (community contributor, Syncfusion partner)
Platforms Affected: iOS, MacCatalyst
Files Changed: 1 implementation file, 2 test files, 5 snapshot files

Issue Summary

When a RadioButton has a plain string Content (not a custom View), the TextColor property is ignored on iOS/MacCatalyst. Root cause: ContentConverter.ConvertToLabel() creates a new Label to display the text. When global Label styles are present in Styles.xaml (as in all default MAUI templates), those styles override the TextColor binding set by the RadioButton.

The bug does NOT reproduce when no global Label styles exist - the issue is specifically triggered by the default MAUI template's <Style TargetType="Label"> in Styles.xaml.

Fix Summary

PR creates a ContentLabel : Label internal subclass in ContentConverter.cs. Key design:

1. Uses ContentLabel (not Label) in ConvertToLabel() → bypasses <Style TargetType="Label"> styles (different type)
2. ContentLabel has a self-hosted empty Style(typeof(ContentLabel)) stored in its Resources dictionary → this takes priority in local resource lookup over global styles with ApplyToDerivedTypes="True", blocking their application

Changed Files

Fix Files:

• src/Controls/src/Core/ContentConverter.cs (+15, -3) — adds ContentLabel internal class, uses it in ConvertToLabel

Test Files:

• src/Controls/tests/TestCases.HostApp/Issues/Issue18011.cs (+54) — HostApp UI test page (screenshot test)
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue18011.cs (+20) — NUnit screenshot test

Snapshot Files:

• src/Controls/tests/TestCases.Android.Tests/snapshots/android/RadioButtonTextColorShouldNotBeOverriddenByGlobalLabelStyle.png — Android baseline
• src/Controls/tests/TestCases.Mac.Tests/snapshots/mac/RadioButtonTextColorShouldNotBeOverriddenByGlobalLabelStyle.png — Mac baseline
• src/Controls/tests/TestCases.WinUI.Tests/snapshots/windows/RadioButtonTextColorShouldNotBeOverriddenByGlobalLabelStyle.png — Windows baseline
• src/Controls/tests/TestCases.iOS.Tests/snapshots/ios/RadioButtonTextColorShouldNotBeOverriddenByGlobalLabelStyle.png — iOS baseline
• src/Controls/tests/TestCases.iOS.Tests/snapshots/ios-26/RadioButtonTextColorShouldNotBeOverriddenByGlobalLabelStyle.png — iOS 26 baseline (added in latest commit)

Reviewer Discussion

File:Line	Reviewer Says	Author Says	Status
ContentConverter.cs	"Can include a comment here?"	Comment added	✅ RESOLVED
ContentConverter.cs:47	"Can you include related tests?"	Tests added (took multiple attempts)	✅ RESOLVED
ContentConverter.cs	ContentLabel should be internal	Addressed	✅ RESOLVED
ContentConverter.cs	Won't fix with ApplyToDerivedTypes="True"	Self-hosted style addresses this	✅ RESOLVED
ContentConverter.cs	Can you add tests? (kubaflo)	Tests added	✅ RESOLVED

Prior Agent Review History

Three prior agent reviews were conducted. The most recent (rmarinho's comment):

• Pre-Flight: ✅ COMPLETE
• Gate: ✅ PASSED (iOS, full verification)
• Fix: ✅ COMPLETE (8 try-fix alternatives; PR's fix selected as best)
• Report: ✅ APPROVE

New since last review: Commit 95167d93 ("Add baseimages") added ios and ios-26 snapshot PNG files that were missing. Prior review ran Gate and test created local baselines — this commit persists them to the repo.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #31940	ContentLabel : Label internal subclass with self-hosted empty Style(typeof(ContentLabel))	⏳ PENDING (Gate)	ContentConverter.cs (+15, -3)	Prior review validated; all concerns resolved

---

🚦 Gate — Test Verification

---

📝 Review Session — Add baseimages · 95167d9

---

Result: ✅ PASSED
Platform: ios
Mode: Full Verification (RequireFullVerification: true)

• Tests FAIL without fix ✅ (bug correctly detected when ContentConverter.cs reverted)
• Tests PASS with fix ✅ (fix resolves the issue)

Test: RadioButtonTextColorShouldNotBeOverriddenByGlobalLabelStyle
Device: iOS Simulator (01E8CA9E-1D30-4467-B4F6-DEB4890B9A27)
Test File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue18011.cs

The tests correctly catch the bug and validate the fix.

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Add baseimages · 95167d9

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (claude-sonnet-4.6)	Instance-level empty Style(typeof(Label)) in label's own Resources dictionary (no subclass needed)	✅ PASS	ContentConverter.cs	Works but mutates a plain Label instance; same style-shadowing concept as PR but without subclass
2	try-fix (claude-opus-4.6)	Override OnSetDynamicResource in ContentLabel subclass to skip Label implicit style key	✅ PASS	ContentConverter.cs	Works but intercepts a deeper internal API; risks breaking other dynamic resource usage
3	try-fix (gpt-5.2)	Set label.Style = new Style(typeof(Label)) (explicit Style property)	❌ FAIL (3% visual diff)	ContentConverter.cs	Explicit Style assignment does not block implicit style application
4	try-fix (gpt-5.3-codex)	Force bindings by adding forceBindings parameter to ShouldSetBinding	❌ FAIL (env/compile error)	ContentConverter.cs	Modifies shared binding logic; would have side effects; env error prevented full test
5	try-fix (gemini-3-pro-preview)	Simple ContentLabel : Label subclass with NO self-hosted style	✅ PASS	ContentConverter.cs	Incomplete PR fix: bypasses standard Label styles but does NOT handle ApplyToDerivedTypes="True" case
PR	PR #31940	ContentLabel : Label internal subclass WITH self-hosted empty Style(typeof(ContentLabel)) in Resources	✅ PASS (Gate)	ContentConverter.cs (+15, -3)	Handles both standard and ApplyToDerivedTypes="True" cases; type isolation + style shadowing

Cross-Pollination Round 2

Model	Response
claude-sonnet-4.6	NO NEW IDEAS
claude-opus-4.6	NO NEW IDEAS - all approaches covered: resource blocking, style interception, binding override, type mismatch
gpt-5.2	NEW IDEA: Scoped TemplateBinding in RadioButton template to set TextColor, overriding global Label style (would require RadioButton template changes - out of scope)
gpt-5.3-codex	NEW IDEA: Re-apply TextColor in Loaded/HandlerChanged (deferred binding — already tried in prior review session, has timing dependency)
gemini-3-pro-preview	NEW IDEA: Set TextColor as local value directly (similar to Attempt 3 which failed - explicit Style doesn't block implicit styles)

Exhausted: Yes (3/5 models gave "new" ideas that are either already explored in prior session or out of scope; 2/5 confirmed no new ideas)

Selected Fix: PR's fix — The ContentLabel subclass with self-hosted Style(typeof(ContentLabel)) in Resources is superior to all alternatives:

1. Beats Attempt 1 (instance-level Label Resources): PR uses a distinct type so no change to Label semantics; static style is shared across instances (less allocation)
2. Beats Attempt 2 (OnSetDynamicResource override): PR doesn't intercept internal API; lower risk of unexpected behavior
3. Beats Attempt 5 (simple subclass): PR handles ApplyToDerivedTypes="True" case via self-hosted style; Attempt 5 leaves this edge case open
4. Deferred binding (prior session): PR has no timing dependency

Root Cause Analysis

1. ContentConverter.ConvertToLabel() creates a new Label when RadioButton.Content is a plain string
2. MAUI's MergedStyle.RegisterImplicitStyles() calls SetDynamicResource("Microsoft.Maui.Controls.Label") on all Label instances in the tree
3. When global <Style TargetType="Label"> exists with TextColor = Colors.Green, this overrides the RadioButton's TextColor = Colors.Red binding
4. ShouldSetBinding checks IsSet BEFORE the label enters the visual tree (before styles resolve), so TextColor is "not set" at that point and binding is registered
5. But when the label resolves styles (after entering the tree), the implicit style writes TextColor at Style specificity, which can conflict with the FindAncestor binding
6. The fix creates ContentLabel — a distinct type that implicit Label styles don't target by default, and with a self-hosted Style(typeof(ContentLabel)) that blocks ApplyToDerivedTypes="True" scenarios via local resource priority

---

📋 Report — Final Recommendation

---

📝 Review Session — Add baseimages · 95167d9

---

✅ Final Recommendation: APPROVE

Summary

PR #31940 correctly fixes RadioButton TextColor being ignored on iOS/MacCatalyst when global Label styles are present in the application. Gate verified the fix on iOS (tests FAIL without fix, PASS with fix). The try-fix phase explored 5 independent alternatives — all 3 that passed are variations of the same style-blocking concept but less robust than the PR's approach. The PR's fix is the best solution.

Root Cause

When RadioButton.Content is a plain string, ContentConverter.ConvertToLabel() creates a new Label. MAUI's style system (MergedStyle.RegisterImplicitStyles) applies <Style TargetType="Label"> implicit styles to ALL Label instances, including this internally-created one. Because the RadioButton's TextColor binding is registered before the label enters the visual tree (and thus before styles resolve), ShouldSetBinding allows the binding — but when styles apply after tree entry, they can override the binding's value. When ApplyToDerivedTypes="True" is also set, the style applies to all Label subclasses as well.

Fix Quality

The ContentLabel : Label internal subclass with a self-hosted Style(typeof(ContentLabel)) in Resources is the most robust solution among all alternatives explored:

Approach	Result	Robustness
PR: ContentLabel + self-hosted Style(ContentLabel)	✅ PASS	⭐⭐⭐ Handles both standard and ApplyToDerivedTypes
Attempt 1: Instance-level Style(Label) in Resources	✅ PASS	⭐⭐ Works but mutates plain Label; shared key could have implications
Attempt 2: Override OnSetDynamicResource	✅ PASS	⭐⭐ Intercepts internal API; less visible mechanism
Attempt 3: Explicit label.Style = empty Style	❌ FAIL	— Doesn't block implicit styles
Attempt 4: Force bindings via ShouldSetBinding	❌ FAIL	— Modifies shared binding logic
Attempt 5: Simple ContentLabel subclass only	✅ PASS	⭐ Doesn't handle ApplyToDerivedTypes="True" case

Why PR's fix is best:

1. Type-level isolation prevents styles from targeting ContentLabel by default
2. Self-hosted Style(typeof(ContentLabel)) handles the ApplyToDerivedTypes="True" edge case via local resource priority
3. No timing dependency (unlike deferred/Loaded event approaches from prior review session)
4. No modification to shared binding logic (unlike force-binding approaches)
5. static readonly Style s_style is shared across instances (no per-instance overhead)

Code Review Findings

🟡 Minor: PlatformAffected.iOS should include MacCatalyst

• File: src/Controls/tests/TestCases.HostApp/Issues/Issue18011.cs:3
• Issue: PlatformAffected.iOS but the fix is in cross-platform ContentConverter.cs and PR title says [iOS, Mac]
• Suggestion: Change to PlatformAffected.iOS | PlatformAffected.MacCatalyst
• Severity: Minor — tests still run correctly, just misrepresents the affected scope

🟡 Minor: Truncated PR description

• The last sentence of the PR body is cut off at "With this update, the label bypasses"
• Should be completed to describe what the label bypasses (global Label styles)

✅ Everything Else Looks Good:

• ContentLabel is correctly internal (not public)
• Self-hosted style mechanism works correctly for both standard and ApplyToDerivedTypes scenarios
• Test page properly adds and removes global Label styles (good test isolation)
• Two RadioButton test cases (one with explicit red color, one default) cover the key regression scenario
• Comments explain the approach clearly
• iOS snapshot baselines provided for both ios and ios-26 environments
• All platform snapshots committed (Android, Mac, Windows, iOS, iOS-26)

What NOT to Do (for future agents)

• ❌ Don't set label.Style = new Style(typeof(Label)) — Explicit Style assignment does NOT block implicit style application; MAUI applies implicit styles through a separate mechanism
• ❌ Don't use simple ContentLabel : Label subclass without self-hosted style — Works for standard Label styles but breaks when ApplyToDerivedTypes="True" is set
• ❌ Don't use deferred binding (Loaded event + force re-apply) — Works but adds timing dependency and event subscription overhead; type isolation is cleaner

PR Title & Description

Title: [iOS, Mac] Fix for RadioButton TextColor for plain Content not working
Assessment: Acceptable, though [iOS, Mac] RadioButton: Fix TextColor ignored when global Label styles present is more searchable.

Description: Has the required NOTE block already present. Truncated last sentence should be completed.

---

📋 Expand PR Finalization Review

---

Title: ✅ Good

Current: [iOS, Mac] Fix for RadioButton TextColor for plain Content not working

Description: ⚠️ Needs Update

• [iOS, Mac] prefix is inaccurate — the fix is in ContentConverter.cs in src/Controls/src/Core/, which is cross-platform Core code, not iOS/Mac-specific. Snapshot images were also added for Android and Windows, confirming the fix is cross-platform.
• "Fix for" is redundant phrasing.
• "not working" is vague — doesn't describe the actual mechanism or root cause.

✨ Suggested PR Description

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

When a RadioButton has plain string content (e.g., Content = "some text"), ContentConverter.ConvertToLabel creates a Label to display it and then binds the RadioButton's TextColor to the label via BindTextProperties. The binding is only applied if ShouldSetBinding confirms the property is not already set.

The bug: if the application has a global implicit Label style (e.g., in App.xaml) that sets TextColor, and that style has ApplyToDerivedTypes = true (the default for implicit styles), MAUI applies it to the newly-created Label before the binding is set up. When ShouldSetBinding then checks IsSet(TextColorProperty), it finds the style has already set the property and skips setting the binding — leaving the RadioButton's own TextColor ignored.

Description of Change

Introduced a new internal ContentLabel class (a subclass of Label) and changed ContentConverter.ConvertToLabel to instantiate ContentLabel instead of Label.

ContentLabel adds a self-hosted empty implicit style for its own type to its Resources:

internal class ContentLabel : Label
{
    static readonly Style s_style = new Style(typeof(ContentLabel));
    public ContentLabel()
    {
        Resources = new ResourceDictionary { { typeof(ContentLabel).FullName, s_style } };
    }
}

MAUI's style resolution searches the element's own ResourceDictionary before traversing up to parent/application resources. When an implicit style for ContentLabel is found in the element's own resources, the lookup stops — the global Label style (with ApplyToDerivedTypes = true) is never applied to the ContentLabel. This leaves TextColor unset by any style, so ShouldSetBinding correctly allows the binding to the RadioButton's TextColor to be established.

The fix is cross-platform — ContentConverter.cs lives in Core and is shared across iOS, Mac Catalyst, Android, and Windows. Snapshots were added for all four platforms.

Key Technical Details

Why typeof(ContentLabel).FullName as the ResourceDictionary key works:
MAUI's implicit style resolution looks for Style objects stored in ResourceDictionary using the target type's full name (e.g., "Microsoft.Maui.Controls.ContentLabel") as the string key. This is the standard mechanism for implicit styles.

Why the static Style field is safe:
s_style has no setters and is only used to block other styles from being applied. It is effectively a sentinel value and is safe to share across all ContentLabel instances.

Scope of change:
ContentLabel is internal, so it is not exposed as a public API. Any consumer using ContentPresenter with string content (e.g., RadioButton, Button, CheckBox) benefits from this fix without API surface changes.

Issues Fixed

Fixes #18011

Platforms Tested

• iOS
• Mac Catalyst
• Android
• Windows

Code Review: ⚠️ Issues Found

Code Review — PR #31940

🔴 Critical Issues

Description Truncated Mid-Sentence

File: PR body (not code)
Problem: The PR description ends abruptly:

"With this update, the label bypasses "

This is a copy-paste or editing accident. The description is incomplete and fails to communicate the complete fix rationale to reviewers and future agents.
Recommendation: Complete the description (see recommended-description.md).

---

🟡 Suggestions

1. PlatformAffected.iOS Should Be PlatformAffected.All

File: src/Controls/tests/TestCases.HostApp/Issues/Issue18011.cs:3

[Issue(IssueTracker.Github, 18011,
    "RadioButton TextColor for plain Content not working on iOS when Label styles present", PlatformAffected.iOS)]

Problem: The fix is in ContentConverter.cs which is Core/cross-platform code. Snapshot images were added for Android, iOS, Mac, and Windows — confirming all platforms are affected and the fix applies everywhere. Using PlatformAffected.iOS incorrectly scopes the test to iOS only.
Recommendation: Change to PlatformAffected.All.

---

2. ContentLabel Mechanism Could Benefit From a More Explicit Explanation

File: src/Controls/src/Core/ContentConverter.cs:134-143

// Internal label type used by ContentPresenter to avoid interference from global Label styles.
// A self-hosted empty style blocks inherited Label styles (including ApplyToDerivedTypes) from being applied.
internal class ContentLabel : Label
{
    static readonly Style s_style = new Style(typeof(ContentLabel));
    public ContentLabel()
    {
        Resources = new ResourceDictionary { { typeof(ContentLabel).FullName, s_style } };
    }
}

Problem: The comment explains what happens but not why it works at the framework level. The key mechanism is:

1. MAUI's implicit style resolution checks the element's own Resources before traversing parent/application resources.
2. Storing a Style with key typeof(ContentLabel).FullName registers it as an implicit style for ContentLabel.
3. When this style is found locally, the lookup stops — the global Label style with ApplyToDerivedTypes = true is never reached.

This makes ShouldSetBinding return true for TextColorProperty, allowing the binding to the RadioButton's TextColor to be established.
Recommendation: Add a brief comment mentioning that the string key is the implicit style registration mechanism (FullName = implicit style key) and that finding it locally short-circuits the lookup up the resource tree.

---

3. Test Only Verifies Visual Appearance, Not Color Value

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

[Test]
[Category(UITestCategories.RadioButton)]
public void RadioButtonTextColorShouldNotBeOverriddenByGlobalLabelStyle()
{
    App.WaitForElement("RadioButtonWithTextColor");
    VerifyScreenshot();
}

Problem: The test verifies the visual appearance via screenshot comparison only. If the color rendering changes slightly across OS versions or hardware, the snapshot may need updating even if the fix is still working correctly.
Recommendation: While screenshot tests are acceptable, note that VerifyScreenshot() with no tolerance parameters may be fragile across iOS versions (e.g., ios vs ios-26 snapshots are separate). The test does have both ios and ios-26 snapshots added, which is good practice.

This is a minor observation — the overall test structure is correct.

---

✅ Looks Good

• ContentLabel as internal — Correctly scoped. Not exposed as a public API surface, so no PublicAPI.Unshipped.txt changes needed.
• Static s_style field — Correct. The style has no setters and is purely structural. Sharing it across instances is safe and efficient.
• OnDisappearing cleanup in HostApp — The test page correctly removes the injected global style on disappear, preventing it from affecting subsequent tests.
• NOTE block present — The PR description includes the required NOTE block for community testers.
• Snapshots added for all 4 platforms — Android, iOS, iOS-26, Mac, Windows snapshots are all included.
• ShouldSetBinding interaction — The fix correctly addresses the root cause: by preventing the global style from setting TextColor, ShouldSetBinding returns true and the binding to the RadioButton's TextColor is established correctly.
• No breaking API changes — ContentLabel is internal, ConvertToLabel is private static. No public API surface is changed.

---

[kubaflo]

Can you add tests?

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

Or

• Run remotely in PowerShell:

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

[HarishwaranVijayakumar]

Can you add tests?

@kubaflo, Added test case.

[HarishwaranVijayakumar]

🤖 AI Summary

📊 Expand Full Review
🔍 Pre-Flight — Context & Validation
📝 Review Session — Added comments · c562641
Issue: #18011 - RadioButton: TextColor for plain Content not working on iOS PR: #31940 - [iOS, Mac] Fix for RadioButton TextColor for plain Content not working Author: HarishwaranVijayakumar (community contributor) Platforms Affected: iOS, MacCatalyst (label in title) Files Changed: 1 implementation file, 0 test files

Issue Summary

When a RadioButton has a plain string Content (not a custom View), the TextColor is ignored on iOS/MacCatalyst. The root cause is that ContentConverter.ConvertToLabel() creates a new Label to display the text, and when global Label styles are present in Styles.xaml (as they are in all new .NET MAUI templates), those styles override the TextColor binding set by the RadioButton.

The issue is confirmed to be specific to users having Label styles in Styles.xaml — e.g., a default MAUI template generates <Style TargetType="Label"> which inadvertently overrides the RadioButton's text color.

Fix Summary

PR creates a ContentLabel : Label subclass to use instead of Label in ContentConverter.ConvertToLabel(). Since ContentLabel is a different type, global Label styles don't apply to it.

Changed File:

• src/Controls/src/Core/ContentConverter.cs (+6, -2)

  • Changed ConvertToLabel return type from Label to ContentLabel
  • Changed new Label to new ContentLabel
  • Added class ContentLabel : Label { } inner class with comment

Reviewer Discussion

File:Line Reviewer Says Author Says Status
ContentConverter.cs:135 "Can include a comment here?" Comment added ✅ RESOLVED
ContentConverter.cs:47 "Can you include related tests?" "Tried but it breaks other tests" ❌ OPEN
ContentConverter.cs:135 ContentLabel should be internal class ContentLabel (no response) ❌ OPEN
ContentConverter.cs:135 "Won't fix with ApplyToDerivedTypes=\"True\"" (no response) ❌ OPEN

Edge Cases Identified

• ApplyToDerivedTypes="True" — if a Label style uses this attribute, the fix does NOT work because the style will also apply to ContentLabel (raised by @jsuarezruiz, unresolved)
• Missing internal visibility modifier on ContentLabel — public by default, unintended external usage possible

Fix Candidates

Source Approach Test Result Files Changed Notes

PR PR #31940 Create ContentLabel : Label subclass to avoid global Label styles ⏳ PENDING (Gate) ContentConverter.cs (+6, -2) Original PR — but no tests and incomplete for ApplyToDerivedTypes case
🚦 Gate — Test Verification
📝 Review Session — Added comments · c562641
Result: ❌ FAILED Platform: ios Mode: N/A — Tests do not exist

Summary

Gate failed because no tests exist for issue #18011 in this PR or in the codebase.

• src/Controls/tests/TestCases.HostApp/Issues/ — no file matching *18011* found
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/ — no file matching *18011* found

Evidence from PR Discussion

Reviewer @jsuarezruiz explicitly requested tests in a code review comment (unresolved):

"Can you include a related tests?"

Author responded:

"Tried to add test using Application.Current.Resources, but it breaks the other test cases."

The author did not resolve this issue and no tests were added.

Verdict

Cannot verify that the fix is correct via automated tests. Gate FAILED — tests are required before this PR can be approved.

🔧 Fix — Analysis & Comparison
📝 Review Session — Added comments · c562641
Skipped — Gate did not pass. Try-fix requires tests to run verification.

No try-fix candidates explored.

Exhausted: N/A (skipped — Gate failed) Selected Fix: PR's fix — skipped Phase 3 due to Gate failure; PR fix was the only candidate

📋 Report — Final Recommendation
📝 Review Session — Added comments · c562641

⚠️ Final Recommendation: REQUEST CHANGES

Summary

PR #31940 fixes RadioButton TextColor not working on iOS/MacCatalyst when global Label styles are present in Styles.xaml (issue #18011). The fix is a minimal one-file change: introduce a ContentLabel : Label subclass so that global <Style TargetType="Label"> styles don't affect the internal label created by ContentConverter. The approach is reasonable for the common case, but the PR is missing tests and has unresolved reviewer concerns that need to be addressed before merge.

Root Cause

When RadioButton has a plain string Content, ContentConverter.ConvertToLabel() creates a new Label to display it. The ContentPresenter binds text properties (TextColor, FontSize, etc.) from the RadioButton to this label via relative source bindings. However, the global <Style TargetType="Label"> in Styles.xaml (present in all default MAUI templates) overrides those bindings because implicit styles have a higher effective priority than these inherited bindings, causing TextColor to be ignored on iOS.

Fix Quality

What the fix does:

• Creates ContentLabel : Label subclass in ContentConverter.cs
• Changes ConvertToLabel to return ContentLabel instead of Label
• Since ContentLabel is a different type, implicit <Style TargetType="Label"> no longer matches it

What works: The fix correctly handles the standard case (global Label styles in Styles.xaml without ApplyToDerivedTypes).

What doesn't work: If a user sets ApplyToDerivedTypes="True" on their Label style, the fix fails because Style.CanBeAppliedTo() walks up the base type hierarchy and ContentLabel : Label would still match. This is confirmed by reviewing Style.cs:CanBeAppliedTo().

Issues Requiring Changes

🚨 Required: Tests Missing

The reviewer @jsuarezruiz explicitly requested tests (unresolved thread). The author responded that they "tried to add tests using Application.Current.Resources, but it breaks the other test cases."

Action needed: Tests must be added. If the test infrastructure has trouble with Application.Current.Resources, this is a test design issue to solve — not a reason to skip tests. The PR should include at minimum a unit test that verifies ConvertToLabel returns a ContentLabel (not a raw Label), which wouldn't require Application.Current.Resources.

⚠️ Minor: Missing internal visibility modifier

ContentLabel is declared as package-private (class ContentLabel) but should be internal to be explicit. Copilot reviewer suggested this change (unresolved):

// Current:
class ContentLabel : Label { }

// Suggested:
internal class ContentLabel : Label { }

⚠️ Edge Case: ApplyToDerivedTypes="True" not handled

With <Style TargetType="Label" ApplyToDerivedTypes="True">, the style will still apply to ContentLabel since it's a subclass of Label. @jsuarezruiz raised this concern (unresolved). While not the common case, it should be documented or handled.

Requested Changes

1. Add tests — at minimum, a unit test verifying the fix works. A UI test for issue RadioButton: TextColor for plain Content not working on iOS #18011 would be ideal.
2. Add internal keyword to ContentLabel class declaration.
3. Address ApplyToDerivedTypes concern — either handle it or document the limitation in a code comment.

Gate Status

❌ Gate FAILED — no tests exist for this issue in the codebase. Gate requires tests that fail without the fix and pass with the fix.

📋 Expand PR Finalization Review

Addressed the valid concerns.