This would be considered a breaking change mainly because an app may quite drastically change it's visual appearance with this change - to many in unexpected way, however it's a welcome change but it would be considered a breaking change and would need to go into a minor release likely (vs a patch).

Possible to post a quick screenshot of iOS/Android side by side on this?

@NathanWalker sure thing. Take a look at the red box shadow at the bottom.

This is how it looks on Android:

This is how it looks on an iPhone 15 after the changes:

This is how it currently looks on an iPhone 15 in production:

It's worth considering whether we should value native look-and-feel over cross-platform consistency or not.
Because in iOS, we have actual support for a complete shadow styling while android merely offers elevation and blur filter (with the exception of canvas shadow layer).

If we had to do such a calibration, I think android should match the iOS look 'n feel and not vice-versa.

@SeanKelly369 I noticed some designers divide blur by screen scale.
I found a Sketch vs iOS shadow discussion here:https://stackoverflow.com/questions/34269399/how-to-control-shadow-spread-and-blur
Can you check if dividing blur gives you the ideal result?

@coderabbitai please review this PR

#!/bin/bash# Get information about the PRgh pr view 10583 --json title,body,files,additions,deletions# Get the diff for the PRgh pr diff 10583# List the files changed in this PRgh pr view 10583 --json files | jq -r '.files[].path'

#!/bin/bash# Let's examine the full context of the iOS background implementationcat packages/core/ui/styling/background.ios.ts | grep -A 20 -B 20 "shadowRadius"# Also look at the Android implementation for comparisonfd "background.android.ts" --exec cat {}# Check if there are any existing tests for shadow functionalityfd -e "spec.ts" -e "test.ts" | xargs grep -l "shadow\|Shadow" | head -5

#!/bin/bash# Let's examine the CSS shadow spec test to understand the expected behaviorcat packages/core/ui/styling/css-shadow.spec.ts# Let's also check if there are any platform-specific shadow constants or documentationrg -A 5 -B 5 "shadow.*blur|blur.*shadow" --type ts# Check for any existing documentation about shadow differences between platformsrg -A 10 -B 5 "shadow.*ios|ios.*shadow" --type md --type ts

@shiv19 I've reviewed this PR and have several observations and recommendations:

🎯Review Summary

This PR addresses a legitimate cross-platform inconsistency in box-shadow rendering, but there are important considerations around breaking changes, technical approach, and consistency.

✅Positive Aspects

1. Addresses Real Issue: The visual differences in shadow rendering between iOS and Android shown in the screenshots are significant
2. Targeted Fix: The change is surgical, affecting only the iOS box-shadow implementation
3. Visual Improvement: The post-change iOS rendering appears much closer to Android

⚠️Key Concerns

1.Breaking Change Acknowledgment

// Current changeshadowLayer.shadowRadius=shadowRadius*0.65;

As@NathanWalker correctly noted, this is indeed a breaking change that will affect existing app visuals. The PR description incorrectly states "BREAKING CHANGES: none" - this should be updated.

2.Empirical vs Mathematical Approach

The0.65 multiplier appears to be empirically derived. Consider@CatchABus's suggestion about dividing by screen scale:

// Alternative approach to investigateshadowLayer.shadowRadius=shadowRadius/Screen.mainScreen.scale;

3.Inconsistency with Text Shadows

The text shadow implementation inpackages/core/ui/text-base/index.ios.ts doesn't apply this adjustment:

layer.shadowRadius=layout.toDeviceIndependentPixels(Length.toDevicePixels(value.blurRadius,0));

This creates inconsistency between box-shadow and text-shadow rendering on iOS.

4.Missing Test Coverage

The existing tests only cover CSS parsing, not platform-specific rendering behavior. Consider adding integration tests that validate cross-platform consistency.

📝Recommendations

1.Research the Multiplier

Investigate if there's a mathematical relationship or Apple documentation that justifies the 0.65 factor, or test the screen scale division approach:

// Test both approachesshadowLayer.shadowRadius=shadowRadius*0.65;// CurrentshadowLayer.shadowRadius=shadowRadius/Screen.mainScreen.scale;// Alternative

2.Apply Consistency

If proceeding with the multiplier approach, consider applying it to text shadows as well for consistency.

3.Update Documentation

• Correct the breaking changes statement in the PR description
• Add comments explaining the iOS-specific adjustment and its rationale

4.Version Planning

Given the breaking nature, ensure this goes into an appropriate release (minor, not patch) as@NathanWalker suggested.

5.Test Coverage

Consider adding visual regression tests or platform comparison tests for shadow rendering.

🤔Questions for Consideration

1. Have you tested the screen scale division approach suggested by@CatchABus?
2. Should text shadows receive the same adjustment for consistency?
3. Would a configuration option for shadow rendering behavior be valuable?

The fix addresses a real problem, but I recommend investigating the mathematical basis for the adjustment and ensuring consistency across all shadow implementations before merging.