so the code path will only be applied for like one in 1000 - 10000 users. increasing the time here by a millionth part shouldn't matter.įurthermore and even more important, no time will be spent at all unless the user has actually applied a custom icon.
even if the calls were expensive they'd not be noticeable compared to the time required to download and apply an update. I assume these calls are not expensive but it would also be something I'd be interested in profiling if I were interested in preserving these. an alternative approach would be copying the custom icon and setting the required xattr manually. We also cannot use AppKit in the installer code which may be executed from a daemon. it shouldn't vanish just because the app is updated. in any case, it is the icon the user wants to see for the app. a custom icon will have the quality that the user has created for the icon. I don't think I want to support preserving these icons overridden in Finder (which may be low-resolution and possibly not scale). i'd be happy to close this and only re-open this bug-report if enough actual users that would like to see some progress here speak up. In any case, i'd never apply a custom icon myself, and i struggle to understand users that do this.
and on the other hand, the Mac App Store is ultra-low quality and really quite user-hostile in many ways. though on the one hand, just because something is done in a way, doesn't mean it is good. The App Store does not preserve custom icons set this way (and thus presumably neither does - but I have not confirmed this), so there is a precedent here of it being standard not to preserve this.ĭefinitely. saying 'you are not allowed to see the icon you want to see because we believe it might be low-quality' isn't friendly. if the user wants to see a specific icon and goes to the trouble of applying the icon, thats his choice. My impression is that this is not as good quality as an app icon or an app that supports custom dock icons Well, it depends on which resolution the icon the user applies has. definitely a classic MacOS < 10 leftover.īut icons set this way might be set just for a specific size. The implementation is very weird, as the icon is stored in the resource fork (!) of that empty Icon\r file. I'm not really that sure on the details and limitations of this format to be honest.
Tested installing large-ish regular zip update (300 MB)
Pkg package installation (via sparkle-cli) Older macOS version (with both bad zip cases, and good zip case) Tested both of the above cases in a real sample app. I tested and verified my change by using one or multiple of these methods:Ĭreated a unit test with extraneous bytes at end of file.Ĭreated a unit test with bad header (missing proper zip header).