Hi MyMattes — sharing some experimental data in case it's useful for the discussion.
While debugging icon jail behavior on Tahoe 26 for some other apps, I ran a controlled experiment that pinpointed an exact pixel-level trigger condition. Hadn't seen it documented anywhere, so it might add some context to your concerns about transition paths.
The trigger is a single binary condition on edge pixel alpha:
- alpha ≥ 253 → filled rounded clip (no frame)
- alpha ≤ 252 → forced squircle frame + scaled-down inset
The threshold sits exactly between 252 and 253. Verified with 12 controlled test apps using identical solid-color icons but varying alpha (255, 254, 253, 252, 250, 245, 240, 200, 128, 50, 10, 1). Values 255/254/253 render cleanly; everything ≤252 gets jailed with identical frame width regardless of how low alpha goes.
Two findings worth highlighting:
-
Frame width is constant. alpha=252 and alpha=50 produce frames of identical size. Lower alpha just makes the inner image more transparent (the desktop bleeds through), but the system frame doesn't grow.
-
It's not about the .icns size set, format, or how iconutil is used. Two .icns files with byte-identical iconutil output but different edge alpha render completely differently. Purely edge alpha decides.
This is, I suspect, why so many legacy iOS-ported apps are caught — developers commonly added subtle anti-aliasing on icon edges (alpha 240–250) for visual softness. This was always fine on prior macOS versions; Tahoe 26 reads anything ≤252 as "icon not designed for current spec, system will wrap it."
Practical implication for your transition-path concern: for raster-based icons, force every pixel's alpha to 255 in the source PNG before packaging into .icns. No need to migrate to Icon Composer or .icon bundles for the edge case where you just want to escape the squircle wrap. Four-line transformation in Python:
from PIL import Image
img = Image.open("input.png").convert('RGBA')
pixels = img.load()
for y in range(img.size[1]):
for x in range(img.size[0]):
r, g, b, _ = pixels[x, y]
pixels[x, y] = (r, g, b, 255)
img.save("output.png")
Then sips to generate the size set and iconutil -c icns to package. This works equally well for unmaintained third-party apps where you can replace the icon manually.
Tested on macOS 26.4.1. I've also filed this as Apple Feedback FB22801803 in the hope that:
- Either the threshold gets relaxed (e.g., to alpha ≥ 240)
- Or the rule is at least documented in HIG/AppKit reference
Would be very interested if anyone here has tested intermediate alpha values (e.g., float-precision alpha in deep color images), or has counter-examples that would refine the rule further.
Experiment screenshot: https://imgur.com/a/OpMTctP
Full fix script: https://gist.github.com/wenkaiqu014-hue/9e3c87e3cc0d3681fa1401b6a8ecc405
