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 PR
gh pr view 10583 --json title,body,files,additions,deletions

# Get the diff for the PR
gh pr diff 10583

# List the files changed in this PR
gh pr view 10583 --json files | jq -r '.files[].path'

#!/bin/bash
# Let's examine the full context of the iOS background implementation
cat packages/core/ui/styling/background.ios.ts | grep -A 20 -B 20 "shadowRadius"

# Also look at the Android implementation for comparison
fd "background.android.ts" --exec cat {}

# Check if there are any existing tests for shadow functionality
fd -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 behavior
cat packages/core/ui/styling/css-shadow.spec.ts

# Let's also check if there are any platform-specific shadow constants or documentation
rg -A 5 -B 5 "shadow.*blur|blur.*shadow" --type ts

# Check for any existing documentation about shadow differences between platforms
rg -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 change
shadowLayer.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

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

// Alternative approach to investigate
shadowLayer.shadowRadius = shadowRadius / Screen.mainScreen.scale;

3. Inconsistency with Text Shadows

The text shadow implementation in packages/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 approaches
shadowLayer.shadowRadius = shadowRadius * 0.65; // Current
shadowLayer.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.