Issue: #34307 - Font autoscaling does not work in realtime
PR: #34445 - [iOS] Fix Font autoscaling does not work in realtime
Platforms Affected: iOS (and MacCatalyst)
Files Changed: 2 implementation, 0 test

Key Findings

• Root Cause: FontManager.iOS.cs caches scaled UIFont instances in a ConcurrentDictionary<Font, UIFont>. When the user changes Dynamic Type size at runtime, the Font struct key doesn't change so the same stale UIFont is returned from cache. The fonts never update until app restart.
• Fix Area 1: FontManager.iOS.cs — Adds observer for UIApplication.Notifications.ObserveContentSizeCategoryChanged to clear _fonts cache when Dynamic Type changes.
• Fix Area 2: PageViewController.cs — In TraitCollectionDidChange, detects changes to PreferredContentSizeCategory and calls InvalidateFontsOnContentSizeChanged to recursively refresh all autoscaled text elements.
• Fix Area 3: PageViewController.cs — New static method InvalidateFontsOnContentSizeChanged recursively walks the visual tree via IVisualTreeElement.GetVisualChildren() and calls UpdateValue(nameof(ITextStyle.Font)) + InvalidateMeasure() for every ITextStyle element with AutoScalingEnabled: true.
• Copilot Review Comment: The NSObject token returned by ObserveContentSizeCategoryChanged is not retained/disposed, which can cause FontManager instance leaks in tests. Should store and dispose the observer token in FontManager's dispose path.
• No tests exist in this PR — No files in TestCases.HostApp or TestCases.Shared.Tests. Gate phase will be ⚠️ SKIPPED.
• Issue confirmed reproducible on iOS by MAUI team member; not reproduced on Android.
• PR author tested on Windows, Android, and iOS (not Mac).

Fix Candidates

Gate Result: ⚠️ SKIPPED

Platform: iOS
Mode: N/A — No tests found in PR

Reason: PR #34445 contains no test files. Files changed:

• src/Core/src/Fonts/FontManager.iOS.cs (implementation only)
• src/Core/src/Platform/iOS/PageViewController.cs (implementation only)

No files exist in TestCases.HostApp or TestCases.Shared.Tests.

• Tests FAIL without fix: ⚠️ N/A (no tests to run)
• Tests PASS with fix: ⚠️ N/A (no tests to run)

Recommendation: Use write-tests-agent to create UI tests for issue #34307 (Font autoscaling realtime update on iOS).

Fix Candidates

Attempt 1 (claude-sonnet-4.6)

Approach: Bypass font cache for auto-scaled fonts proactively (no observer in FontManager)
Key Insight: Auto-scaled fonts call UIFontMetrics.DefaultMetrics.GetScaledFont(), whose output depends on UIContentSizeCategory. Caching them is semantically incorrect — they should be recreated fresh. The PR clears the cache reactively; this fix removes caching for auto-scaled fonts entirely.
Different from PR: PR uses ObserveContentSizeCategoryChanged to clear ALL cached fonts. This approach never caches auto-scaled fonts.
Result: 🚫 Blocked — No UI test available to empirically verify.

Attempt 2 (claude-opus-4.6)

Approach: Dual-cache architecture — split _fonts (non-scaled) and _scaledFonts (auto-scaled); add ClearScaledFontCache() on FontManager; PageViewController resolves FontManager via DI and calls it on trait change. No observer subscription.
Different from PR: No observer (eliminates leak), no full cache clear, selective invalidation of only auto-scaled fonts. Also different from Attempt 1 (still caches auto-scaled fonts between changes).
Result: 🚫 Blocked — No UI test available to empirically verify.

Cross-Pollination

Note: Both cross-pollination ideas were NOT separately implemented as try-fix attempts since all attempts result in Blocked (no test exists to verify). They are documented for informational purposes.

Exhausted: Yes (2 models × Round 1, cross-pollination complete)
Selected Fix: PR's Fix — it is the only empirically-tested candidate (the PR author tested on iOS). However, it has a known issue: the observer token from ObserveContentSizeCategoryChanged is not retained/disposed, creating a potential memory leak. Recommend REQUEST CHANGES to fix the observer token lifecycle.

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Summary

PR #34445 fixes a real iOS bug where FontManager caches UIFont instances keyed by Font struct. When the user changes Dynamic Type at runtime, the cache key doesn't change, so the stale scaled font is returned until app restart. The PR correctly identifies and addresses this by:

1. Registering a ContentSizeCategoryChanged observer in FontManager to clear the cache
2. Detecting PreferredContentSizeCategory changes in PageViewController.TraitCollectionDidChange
3. Recursively invalidating auto-scaled text elements via InvalidateFontsOnContentSizeChanged

The fix approach is sound and the PR author has manually tested on iOS. However, there is one confirmed code quality issue that needs to be addressed before merge.

Root Cause

FontManager.iOS.cs caches scaled UIFont instances in a ConcurrentDictionary<Font, UIFont>. The Font struct key does not include the current UIContentSizeCategory. When the user changes Dynamic Type, the Font key is unchanged, so _fonts.GetOrAdd(font, factory) returns the stale cached font instead of creating a new one with the updated scaling.

Fix Quality

What's Good:

• Correct two-pronged approach: clear stale cache + refresh live UI elements
• Uses ITextStyle.Font.AutoScalingEnabled guard to avoid unnecessary updates
• Recursive tree walk via IVisualTreeElement.GetVisualChildren() is the right approach for pushing mapper updates
• Correctly handles previousTraitCollection is not null guard

Issue That Requires Change:

Observer memory leak in FontManager.iOS.cs — UIApplication.Notifications.ObserveContentSizeCategoryChanged(...) returns a NSObject observer token. The PR discards this token (no variable assigned), which means:

• The observer is never unregistered
• The closure captures _fonts (hence FontManager instance), preventing GC
• In test environments that create FontManager directly, this leaks per-instance

Fix: Store the returned NSObject in an instance field, implement IDisposable, and call _contentSizeCategoryObserver?.Dispose() in Dispose().

Example:

// In class fields:
NSObject? _contentSizeCategoryObserver;

// In constructor:
_contentSizeCategoryObserver = UIApplication.Notifications.ObserveContentSizeCategoryChanged(
    (sender, args) => _fonts.Clear());

// In Dispose():
_contentSizeCategoryObserver?.Dispose();
_contentSizeCategoryObserver = null;

Minor Concern (non-blocking):

• InvalidateFontsOnContentSizeChanged is called regardless of whether CurrentView itself has auto-scaled fonts at the top level. This is fine for correctness but slightly wasteful if the page has no auto-scaled fonts at all (the tree walk still occurs).

Alternative Approaches Found in Try-Fix

Two alternative approaches were explored (both Blocked due to no tests):

1. Bypass caching for auto-scaled fonts (Attempt 1): Never cache auto-scaled fonts at all — check font.AutoScalingEnabled in GetFont and call factory(font) directly. Semantically cleaner; eliminates the observer entirely. Downside: minor per-call overhead since auto-scaled fonts are never reused.

2. Dual-cache + selective invalidation (Attempt 2): Split cache into _fonts (non-scaled) and _scaledFonts (auto-scaled); add ClearScaledFontCache() called from PageViewController via DI. No observer, no global clear, selective invalidation only.

Cross-pollination surfaced two more ideas: handler-level subscription per-element, and including UIContentSizeCategory in the cache key. All alternatives avoid the observer token leak but none are implemented in the current PR.

Verdict

The PR's logic is correct and the approach is valid. The one required change is fixing the observer token lifecycle to prevent memory leaks. This is a straightforward fix. Once addressed, the PR is ready to merge.

Result: ⚠️ REQUEST CHANGES — Fix observer token lifecycle in FontManager.iOS.cs (store and dispose the NSObject returned by ObserveContentSizeCategoryChanged).

Issue: #34307 - Font autoscaling does not work in realtime
PR: #34445 - [iOS] Fix Font autoscaling does not work in realtime
Platforms Affected: iOS (and MacCatalyst)
Files Changed: 2 implementation, 0 test

Key Findings

• Root Cause: FontManager.iOS.cs caches scaled UIFont instances in a ConcurrentDictionary<Font, UIFont>. When the user changes Dynamic Type size at runtime, the Font struct key doesn't change so the same stale UIFont is returned from cache. The fonts never update until app restart.
• Fix Area 1: FontManager.iOS.cs — Adds observer for UIApplication.Notifications.ObserveContentSizeCategoryChanged to clear _fonts cache when Dynamic Type changes.
• Fix Area 2: PageViewController.cs — In TraitCollectionDidChange, detects changes to PreferredContentSizeCategory and calls InvalidateFontsOnContentSizeChanged to recursively refresh all autoscaled text elements.
• Fix Area 3: PageViewController.cs — New static method InvalidateFontsOnContentSizeChanged recursively walks the visual tree via IVisualTreeElement.GetVisualChildren() and calls UpdateValue(nameof(ITextStyle.Font)) + InvalidateMeasure() for every ITextStyle element with AutoScalingEnabled: true.
• Copilot Review Comment: The NSObject token returned by ObserveContentSizeCategoryChanged is not retained/disposed, which can cause FontManager instance leaks in tests. Should store and dispose the observer token in FontManager's dispose path.
• No tests exist in this PR — No files in TestCases.HostApp or TestCases.Shared.Tests. Gate phase will be ⚠️ SKIPPED.
• Issue confirmed reproducible on iOS by MAUI team member; not reproduced on Android.
• PR author tested on Windows, Android, and iOS (not Mac).

Fix Candidates

Issue: #34307 - Font autoscaling does not work in realtime
PR: #34445 - [iOS] Fix Font autoscaling does not work in realtime
Platforms Affected: iOS (confirmed), Android listed on issue but not reproduced by validation comment, MacCatalyst claimed by PR description
Files Changed: 2 implementation, 2 API surface, 0 test

Key Findings

• Issue Font autoscaling does not work in realtime #34307 reports that explicit numeric FontSize values do not react to Dynamic Type changes at runtime, while deprecated named sizes still do.
• A MAUI validation comment confirms reproduction on iOS and explicitly says it was not reproduced on Android, despite Android being listed in the issue metadata.
• The PR changes only iOS-specific implementation files plus the corresponding iOS/MacCatalyst PublicAPI.Unshipped.txt files; there are no test files in the PR.
• Current PR approach: clear the cached scaled fonts in FontManager.iOS.cs when content size category changes, then refresh autoscaled text elements from PageViewController.TraitCollectionDidChange.
• Prior agent review in PR comments flagged an observer-token leak; the current PR diff now stores the observer token, implements IDisposable, and adds PublicAPI entries for FontManager.Dispose().
• Review discussion does not surface additional edge cases beyond platform scope and the lack of automated coverage.

Fix Candidates

Gate Result: ⚠️ SKIPPED

Platform: iOS
Mode: N/A — No tests found in PR

Reason: PR #34445 contains no test files. Files changed:

• src/Core/src/Fonts/FontManager.iOS.cs (implementation only)
• src/Core/src/Platform/iOS/PageViewController.cs (implementation only)

No files exist in TestCases.HostApp or TestCases.Shared.Tests.

• Tests FAIL without fix: ⚠️ N/A (no tests to run)
• Tests PASS with fix: ⚠️ N/A (no tests to run)

Recommendation: Use write-tests-agent to create UI tests for issue #34307 (Font autoscaling realtime update on iOS).

Gate SKIPPEDResult:

Platform: ios
Mode: N/A - No tests found in PR

• Tests FAIL without N/Afix:
• Tests PASS with N/Afix:

Reason: PR #34445 changes only implementation and PublicAPI files. It includes no files under TestCases.HostApp or TestCases.Shared.Tests, so there is no PR-supplied UI coverage to verify fail-without-fix / pass-with-fix behavior.

Follow-up: This PR would benefit from issue coverage via write-tests-agent for #34307.

Gate Result: ⚠️ SKIPPED

Platform: iOS
Mode: N/A — No tests found in PR

Reason: PR #34445 contains no test files. Files changed:

• src/Core/src/Fonts/FontManager.iOS.cs (implementation only)
• src/Core/src/Platform/iOS/PageViewController.cs (implementation only)

No files exist in TestCases.HostApp or TestCases.Shared.Tests.

• Tests FAIL without fix: ⚠️ N/A (no tests to run)
• Tests PASS with fix: ⚠️ N/A (no tests to run)

Recommendation: Use write-tests-agent to create UI tests for issue #34307 (Font autoscaling realtime update on iOS).

Fix Candidates

Cross-Pollination

Exhausted: Yes (practical limit reached; all empirical validation was blocked by missing issue-specific tests)
Selected Fix: PR #34445 - simplest current implementation among the explored options, and the prior observer-token lifecycle issue appears addressed in the current diff. The main remaining gap is missing automated coverage.

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Summary

PR #34445 fixes a real iOS bug where FontManager caches UIFont instances keyed by Font struct. When the user changes Dynamic Type at runtime, the cache key doesn't change, so the stale scaled font is returned until app restart. The PR correctly identifies and addresses this by:

1. Registering a ContentSizeCategoryChanged observer in FontManager to clear the cache
2. Detecting PreferredContentSizeCategory changes in PageViewController.TraitCollectionDidChange
3. Recursively invalidating auto-scaled text elements via InvalidateFontsOnContentSizeChanged

The fix approach is sound and the PR author has manually tested on iOS. However, there is one confirmed code quality issue that needs to be addressed before merge.

Root Cause

FontManager.iOS.cs caches scaled UIFont instances in a ConcurrentDictionary<Font, UIFont>. The Font struct key does not include the current UIContentSizeCategory. When the user changes Dynamic Type, the Font key is unchanged, so _fonts.GetOrAdd(font, factory) returns the stale cached font instead of creating a new one with the updated scaling.

Fix Quality

What's Good:

• Correct two-pronged approach: clear stale cache + refresh live UI elements
• Uses ITextStyle.Font.AutoScalingEnabled guard to avoid unnecessary updates
• Recursive tree walk via IVisualTreeElement.GetVisualChildren() is the right approach for pushing mapper updates
• Correctly handles previousTraitCollection is not null guard

Issue That Requires Change:

Observer memory leak in FontManager.iOS.cs — UIApplication.Notifications.ObserveContentSizeCategoryChanged(...) returns a NSObject observer token. The PR discards this token (no variable assigned), which means:

• The observer is never unregistered
• The closure captures _fonts (hence FontManager instance), preventing GC
• In test environments that create FontManager directly, this leaks per-instance

Fix: Store the returned NSObject in an instance field, implement IDisposable, and call _contentSizeCategoryObserver?.Dispose() in Dispose().

Example:

// In class fields:
NSObject? _contentSizeCategoryObserver;

// In constructor:
_contentSizeCategoryObserver = UIApplication.Notifications.ObserveContentSizeCategoryChanged(
    (sender, args) => _fonts.Clear());

// In Dispose():
_contentSizeCategoryObserver?.Dispose();
_contentSizeCategoryObserver = null;

Minor Concern (non-blocking):

• InvalidateFontsOnContentSizeChanged is called regardless of whether CurrentView itself has auto-scaled fonts at the top level. This is fine for correctness but slightly wasteful if the page has no auto-scaled fonts at all (the tree walk still occurs).

Alternative Approaches Found in Try-Fix

Two alternative approaches were explored (both Blocked due to no tests):

1. Bypass caching for auto-scaled fonts (Attempt 1): Never cache auto-scaled fonts at all — check font.AutoScalingEnabled in GetFont and call factory(font) directly. Semantically cleaner; eliminates the observer entirely. Downside: minor per-call overhead since auto-scaled fonts are never reused.

2. Dual-cache + selective invalidation (Attempt 2): Split cache into _fonts (non-scaled) and _scaledFonts (auto-scaled); add ClearScaledFontCache() called from PageViewController via DI. No observer, no global clear, selective invalidation only.

Cross-pollination surfaced two more ideas: handler-level subscription per-element, and including UIContentSizeCategory in the cache key. All alternatives avoid the observer token leak but none are implemented in the current PR.

Verdict

The PR's logic is correct and the approach is valid. The one required change is fixing the observer token lifecycle to prevent memory leaks. This is a straightforward fix. Once addressed, the PR is ready to merge.

Result: ⚠️ REQUEST CHANGES — Fix observer token lifecycle in FontManager.iOS.cs (store and dispose the NSObject returned by ObserveContentSizeCategoryChanged).

Final Recommendation: REQUEST CHANGES##

Phase Status

Summary

PR #34445 addresses a real iOS Dynamic Type regression and the current implementation is reasonable: it clears stale scaled fonts in FontManager and refreshes autoscaled text when the preferred content size category changes. The earlier review concern about leaking the notification observer appears to be fixed in the current diff by storing and disposing the observer token.

However, the PR still lacks automated issue coverage. The Gate phase could not verify the bug because the PR contains no HostApp / shared UI test for Issue34307, and every try-fix attempt hit the same blocker: the iOS runner discovered 0 of 0 NUnit tests and printed No test matches the given testcase filter 'Issue34307'. That means none of the candidate fixes, including the current PR, were empirically validated by issue-specific UI coverage.

Root Cause

On iOS, FontManager caches scaled UIFont instances keyed by the MAUI Font value. When the system Dynamic Type category changes at runtime, that cache can continue returning a font built for the old content-size category unless MAUI invalidates the cached entry and pushes a font refresh back through the active text elements.

Fix Quality

The current PR is the best option among the explored candidates because it is more localized and less invasive than the alternatives explored in try-fix. The alternative ideas either widened the native surface area, introduced new tracking infrastructure, or relied on UIKit-only behavior that still could not be verified here.

The blocking issue is test coverage, not an obvious logic flaw in the latest PR diff. Because the skill's gate could not be satisfied, this review cannot recommend approval yet.