fix(ios): honor corner-shape: squircle for non-uniform border radii - #11451

View your CI Pipeline Execution ↗ for commit dd4717e

💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗

☁️ Nx Cloud last updated this comment at 2026-09-25 18:19:36 UTC

Open in StackBlitz

npm i https://pkg.pr.new/@nativescript/core@11451

npm i https://pkg.pr.new/@nativescript/vite@11451

npm i https://pkg.pr.new/@nativescript/webpack@11451

commit: dd4717e

Thanks for taking this on, and apologies up front: the confusion here is mine, not yours.

When I added corner-shape in #11365 I mapped squircle to kCACornerCurveContinuous believing the two are the same curve. They are not. I measured on the simulator against a real CALayer with cornerCurve = .continuous:

• Apple's continuous corner at radius r is within 0.019 r of a plain circle of the same radius. It is essentially CSS round with the curvature eased in over a 1.528665 r run-up (CALayer.cornerCurveExpansionFactor(.continuous)).
• CSS squircle (superellipse(2)) at the same radius is 0.187 r away, about 3 pt at r=16. No superellipse(K) at any radius gets closer to continuous than the circle does.
• CALayerCornerCurve only has circular and continuous, so the CSS squircle can only ever be a mask path on iOS.

Your helper draws the correct CSS superellipse(2) corner: same curve, same corner box, per-axis radii on the inner border, all matching the spec algorithm. What it is not is kCACornerCurveContinuous, which is what squircle currently means on the uniform fast path. Merging now would make the two branches disagree by ~0.19 r, which is worse than the circular fallback we have today.

Plan for 9.2 (details and numbers in #11452): fix the naming instead of building on the wrong mapping.

• corner-shape: squircle becomes spec-correct superellipse(2), drawn as a mask path on every branch including the uniform one, since Core Animation cannot draw it.
• Apple's continuous curve moves to an iOS-only property, -ios-corner-shape: continuous, mapping to kCACornerCurveContinuous on the fast path and the equivalent three-cubic path elsewhere.
• corner-shape: round stays kCACornerCurveCircular, which is exactly the spec.

So I'd like to defer this PR until that lands and then take it as the non-uniform half of the spec squircle work. The generator plumbing (outer clip, inner border, shadow, animation paths) is exactly what we need. One change I'd ask for then: replace the polyline with two cubic Béziers per corner, which is also how Blink renders it.

Two cubics per corner. Fitted to the n=4 superellipse: max deviation 1.65e-4 r versus 1.9e-3 r for the 12-segment polyline, 2 path elements per corner instead of 12, exact tangents at both ends, and a smooth seam on the diagonal. Same signature as your helper, so no call site changes. Expressing points as c + X·d2 + Y·d1 removes the orientation branch and handles the inner border's unequal x/y radii for free (the spec's affine mapping of the unit corner into the startRadius × endRadius box).

// CSS corner-shape: squircle == superellipse(2), i.e. |x|^4 + |y|^4 = r^4.
// Each quarter is two cubic Béziers (one per half-corner, mirrored across the
// diagonal), fitted to within 1.7e-4·r of the exact curve.
const SQUIRCLE_H = 0.840896; // 0.5^(1/4): where the curve crosses the diagonal
const SQUIRCLE_A = 0.38905; // first control point, along the incoming edge
const SQUIRCLE_B = 0.1678; // second control point, offset along the diagonal tangent

function addSquircleArcToPoint(path: any, t1x: number, t1y: number, t2x: number, t2y: number, vx: number, vy: number): void {
	CGPathAddLineToPoint(path, null, t1x, t1y);

	// The corner-box corner opposite the vertex is the curve's center.
	const cx = t1x + t2x - vx;
	const cy = t1y + t2y - vy;
	// d1: center → t1 (length = radius along the incoming edge), d2: center → t2.
	const d1x = t1x - cx, d1y = t1y - cy;
	const d2x = t2x - cx, d2y = t2y - cy;
	const px = (X: number, Y: number) => cx + X * d2x + Y * d1x;
	const py = (X: number, Y: number) => cy + X * d2y + Y * d1y;

	const h = SQUIRCLE_H, a = SQUIRCLE_A, b = SQUIRCLE_B;
	// (0,1) = t1 → (h,h) on the diagonal
	CGPathAddCurveToPoint(path, null, px(a, 1), py(a, 1), px(h - b, h + b), py(h - b, h + b), px(h, h), py(h, h));
	// (h,h) → (1,0) = t2, the first half mirrored across the diagonal
	CGPathAddCurveToPoint(path, null, px(h + b, h - b), py(h + b, h - b), px(1, a), py(1, a), t2x, t2y);
}

The radius capping you have is already right for this shape: unlike continuous, the superellipse consumes exactly r of each edge. And only h, a, b depend on K (h = 0.5^(1/2^K), a/b refitted per K), so a future superellipse(K) value is a constants lookup on the same code.

Sorry again for the detour. Tracking the naming fix in #11452.