I’d say hand-crafting pixel-perfect icons with different versions for extreme sizes is worthwhile (and I don’t believe in simple rasterization from vector for the same reason), but not every developer would have resources to spare for that.

I was lucky enough to oversee a project replacing seven hundred icons back in 2017, and we hand-adjusted the low resolution versions of 16x16 and 24x24.

> “…notice that the icons are not simply the same image scaled up or down. TTrackBar is a good example of this: at each size, the small indicator marks are different. An icon designed for 16×16 or 32×32 won’t resize and scale to look good at 24×24, because the pixel grid is different. Even if we support antialiasing, a 1-pixel-wide line looks much cleaner when it takes up one pixel in the image, rather than being approximated through antialiasing over several pixels, which makes it look blurry. Similarly, shape edges should be snapped to the pixel grid for each size. We’ve gone through and tweaked the icons for each different pixel grid.”

This meant that not only did we tweak the icons at the small sizes (in the example above for a track bar control, we don’t use the large size 128x one scaled down to 16x even though they are both built on a 16x grid) but that we used a different base grid for the 24x and 48x versions compared to all other sizes.

It took time. And not everyone has those resources. But if you can, it is the right thing to do.

https://blogs.embarcadero.com/new-in-10-2-2-component-icons/

Thanks for the insight. My script targets a solo dev such as myself, but crafting icons is always superior.

As a designer, the way I recommend to do it is not by tweaking icons but by having a specific process separating design from deliverables. Define branding language, come up with your symbols and marks and mascots and their use guidelines, and then prepare deliverables based on that. Icons intended to be used at extremely different sizes (16px vs. 512px) and in different contexts are different deliverables.