Thanks for the tip @coz2001, recently today saw that same icon in a friend's MacBook running Catalina.

This could also be an issue with mac OS Catalina. Other apps are also doing this with ZIP files and if you try reverting the file association to the default Archive Utility app, instead of the OS ZIP icon you'll get the same white page with the Archive Utility icon in the middle.

This isn't exclusive to ZIP icons either. I've seen it with GZ archive aswell.

Indeed. I’ve contacted with the Apple Developer support and they asked me to submit a bug report. So hopefully this will be fixed in macOS 10.15.1.

I’ll be linking the information to this issue. I suggest you also report this bug using the Feedback Assistant.

Checked latest Catalina version with yesterday's supplemental update (19A602), same issue.

Same on 10.15.1 Beta 2 (19B77a).

Does not seem to be fixed on 10.15.1 Beta 3 (19B86a)

Thanks for the update, I really hope it eventually will be fixed the icons just look wrong.

Same here on macOS 10.15 (19A603).

Please, to all that are facing this issue, report it to Apple via the Feedback Assistant app that is bundled in macOS. I've already reported it (FB7365951) on October's 10th, with no reply yet.

I just reported the issue.

This is a catalina compatibility issue in the keka app because other applications will see the icon of that type as normal.

This is a catalina compatibility issue in the keka app because other applications will see the icon of that type as normal.

I think this is a general Catalina bug. As mentioned above the built-in archive utility app also has the same problem.

macOS 10.15.1 (19B88) still has the issue as expected, since it was not fixed in the betas.

@alvarnell I see this as a bug, since the specified icons are not displayed and even the file type descriptions are wrong #472.

@Euiyeon I did lots of tests, with multiple icons and empty app projects, always with the same results. Then @Deathlike shared the screenshot of the same issue in Archive Utility. Also contacted with Apple Developer support and they told me to fill the bug report.

Again, all users facing this issue should report it to Apple using the Feedback Assistant app.

Still happening in latest 10.15.2 beta 1 (19C32e). And sadly still no reply on the Feedback Assistant issue.

Still the same in 10.15.2 beta 2 (19C39d).

Weird......and my PDF files also have similar problems with Acrobat...

I think it's the extra "IconVariant" property that's throwing Finder off.
After these steps, I can get the Finder to display Keka icons normally:

1. Remove existing Keka
2. Download a new copy from the website
3. Decompress the .app into desktop
4. Reset quarantine tag and self-sign the executable (otherwise the system will refuse to run the modified app)
5. Remove all the "IconVariantblah" in Info.plist
6. Launch Keka & set as default decompressor
7. Relaunch Finder

===
Environment:
macOS 10.15.2 Beta (19C39d)
Keka 1.2.0-dev (3575)

@jankytay there're multiple extra keys in there, not only IconVariant. I've tried removing it anyway with no different results, so maybe is the self sign the difference that helped you. You've signed it with a developer signature?

@jankytay could you share that self signed build?

@aonez no, I signed with ad-hoc
sudo codesign -f -s - Keka.app/Contents/MacOS/Keka
and replaced all \t+<key>IconVariant</key>\n\t+<string>.+</string>\n in Info.plist

I only have VLC and The Unarchiver installed, both the unarchiver and Keka are doing the same issue with the icons, is there a way you can tell to recover the icons? Specially the RAR ones, yesterday I download a RAR files that were RAR.00 RAR.01 etc, the only one showing the blank document page with the The Unarchiver logo was the first one called RAR. the other ones that are connected to unrar that files didn't even show the icon, it was a complete blank document page

Hey guys, if you put this command on Terminal:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user

Every icon shows up correctly after putting the command, and stays correct.
But when you restart the icons show again incorrect, any ideias?

If I put this command on terminal which partially is making rebuild the launch services it all shows correct but when I start my computer again back to square one, have you guys any ideias why this happens? since the command put everything back to place when you restart it should be good as well, it should not bring back the blank document icon with the logo on it

UPDATE: Uninstalled VLC and installed Movist Pro, RAR icons show up correctly, since Movist Pro doesn't have an option to open RAR.

Every icon shows up correctly now.

Until I installed VLC again with Movist Pro installed as well now Movist Pro icons show up with default icons blank page with the logo on it, is VLC breaking this stuff?? Once I install VLC all the icons go wrong!

For sh and xml I got less lucky and it got reassociated to Xcode (even though I set LSIsAppleDefaultForType for sh).

Correction: I indeed set this attribute for sh (and csh) but I set it to </false> (which I suppose is the default, but I wanted to see what happens if it's set explicitly and then forgot about it). After I set it to true and tried the same procedure of reassigning the type to a different app and deinstalling it, the file got reassociated back to Emacs with the correct type specific icon in finder. The same applied to xml after I set this flag explicitly to true.

So the conclusion

it's based on luck.

seems wrong and the behaviour of LSIsAppleDefaultForType seems to be more deterministic than I thought (but who knows what happens if more then one app sets this to true for a type).

@bitti so LSIsAppleDefaultForType set to true worked consistently in your tests?

so LSIsAppleDefaultForType set to true worked consistently in your tests?

After the described procedure (assigning a different opening app and then deinstalling it) it seems so (although one could do a more quantitative test). But I had to experience that this state is very ephemeral. A simple touch /Applications/Emacs.app (therefore a rereading of the Info.plist) is enough to lose the associations again, and if I reassign the opening app to Emacs it's starting to show the generic icon again...

So this "trick" is basically useless. Apple needs to fix this bug.

What I did:

1. Created a new user
2. Logged in
3. Created zip archive and extracted it
4. Returned to my old account and discovered that zip archive icon restored

Seems that creating a new user and running default Archive utility restores default archive icons.

Seems this issue will be finally fixed in next macOS 10.16 (or 11.0?) Big Sur:

The only one not using the Keka icon is the ZIP file, but at least uses the default icon. Will do some testing there.

Finally😉

How is the performance on the 1st beta of the new macOS 11? Seems to be very stable actually to the eye

@miguelbesy only tested in a Parallels VM without official support, so imagine the performance 😂

What I did:

1. Created a new user

2. Logged in

3. Created zip archive and extracted it

4. Returned to my old account and discovered that zip archive icon restored

Seems that creating a new user and running default Archive utility restores default archive icons.

That did not work for me.

1. I created a new Admin account
2. Opened a new .epub in Apple Books
3. I compressed and extracted the .epub with The Unarchiver
4. Changed Default "Open With" of .epub and .zip files to open with Apple Books and The Unarchiver in Get Info

Still shows the app icon inside a black document.

FYI: Those are custom icons I added to Contents/Resources folder of each app, so they won't be recognizable. The filetype icons I added to these folders displayed fine in Mojave. I am also using LiteIcon for customizing app icons.

I am on Catalina 10.15.5

This is is how to do fix the icons on Catalina.

Hi, Catalina icon problems resides on: /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist and /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/System) [this is a .plist without extension]

Specifically ZIP and other common types of files are defined as 'public' and once defined as 'public' Catalina does not allow changing the full icon, instead it forces the icon to be a mini-icon from the associated application [which will open it]

.zip is classified as 'public'= icon show mini-Keka icon
.rar is not classified as 'public' = icon show colored pink as should be
(there are several other types defined as public, and they have the same mini-icon problem)

.
Those public declarations are inside Info.plist (inside the above directory, and on another file called SYSTEM [without extension but it is a .plist file obfuscated by removing the extension: /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/System) [this is a .plist without extension]

(search for LSRiskCategoryContentTypes inside it) .zip is, .rar not
and so on... and this reflects the icons.

extensions which are considered RISKY (like zip) cannot have custom icons on Catalina...
Isn't is an ultra secure mechanism to not let associations confuse users ?? (being sarcastic now Lol..)

Editing those files is possible if SIP is disabled, [reenable SIP it after editing them], you can fix all icons it by comparing the contents of [mentioned] .plist files to Mojave ones, or BigSur .plist files ones [inside CoreTypes.bundle/Contents],

this is how to fix those icons for Catalina.

After changing/removing the 'public' flag from ZIP and other affected types, you must recreate the LaunchDatabase:

1s method, simple:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -u /Applications/Keka.app/

(the above command only unregister Keka, then you need to run Keka and tell it to register all its files extensions again)
The purpose is to delete old references from the LSD (launch service database) which are blocked with the Apple public flag. And recreate the associations again, using keka as it normally does.

if it does not work, try rebooting,

If still does not work, you must recreate the FULL LSD database: this is 100% working method (to recreate the full LSD) (launch services database) using the command:

2nd method:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -delete ; sleep 2 ; sudo reboot

(the above command will clean the LSD database, custom files-extensions associations will be lost, you will have to customize them again [if you have some custom file associations] otherwise the default MacOS file associations will be recreated. This is harmless, but be aware that some applications will have to be re-associated)

There is no other way, because the LSD may be marked on several places with the 'ZIP public' flag (specially if you have several compression apps, etc.)

The cleanup process works, because when the LSD is being recreated there will be no more 'public' flag to ZIP [or other extensions which you have removed [by comparing to Mojave /BigSur]) so the recreation process goes fine and without that flag, the Keka icon just works.

After rebooting it will be created automatically, just the login will take some seconds more than normal..

Not sure? OK, here is how to verify everything I am telling above without risk:

You can check it before doing anything at all, here is how:

Dump the LSD database contents of Catalina to a TXT file:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump > ~/lsregister-Catalina-dump.txt

Get some Mojave machine, or BigSir, do the same, dump it to TXT file:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump > ~/lsregister-Mojave-dump.txt

Open some text editor, search for affected extensions, like .zip on both TXT dumps

• Catalinas has a Binding for .zip which is takes priority over KEKA, and classifies .zip as Risky, so no icon changes possible for .zip,
• but that binding does not exists for .rar (and others) , which are considered NOT risky, so icon change is possible.
• Mojave does not have that binding and does not treat .zip like Catalina does, so icon change is possible

This is absolutely the same for EVERY other extensions which we cannot change icons on Catalina, and this includes compressed files, some kind of video files, audio files, and other kind, WHERE ALL of them are classified as Risky and has that public flag....

You will understand how that thing works, and will notice that there is no public flag on Mojave.. You can find it also on some kind of multimedia files too (which affects IINA icons at the same way)

So, where does those public / Risky flags come from??

They come from the CoreTypesBundle plist files which I mentioned.

.

If we change the way Catalina 'see's those files (by changing those plist files as like Mojave or BigSur, and recreating the LSD database), to make Catalina understand those file extensions like Mojave/BigSur does, then the icon customization occurs correctly on Catalina.

Make Backups before editing!!

Before doing it, make sure to backup somewhere, in case you mess wrong with the .plist files.
/System/Library/CoreServices/CoreTypes.bundle

I suggest editing the mentioned files using some kind of plist editor like PrefEdit or another similar one.

Before doing it, grab a copy of Mojave CoreTypes.bundle and look inside it, open its plist, find ZIP and other affected file types, then compara them to Catalina, or compare to CoreTypes.bundle from BigSir:

will notice the 'public' flag on the affected extensions, which you will have to remove from Catalina's plists.

@pradorocchi I might be missing something but both the dump and System values seem the same to me in Mojave, Catalina and Big Sur. Public means it has no ownership.

Anyway I won't recommend disabling SIP and modifying CoreTypes for this issue. Apple should have fixed this one in Catalina. At least is fixed in Big Sur.

Hi @aonez
I managed to fully make it work!!

I will post easy instructions here later today! It is very easy. (was hard to debug and find the cause, but solution is easy)

Wait for my howto later.
PS: it also requires a change on Keka info.plist

Hi @aonez
I managed to fully make it work!!

I will post easy instructions here later today! It is very easy. (was hard to debug and find the cause, but solution is easy)

Wait for my howto later.
PS: it also requires a change on Keka info.plist

Where is it man?

Hi @aonez
I managed to fully make it work!!

I will post easy instructions here later today! It is very easy. (was hard to debug and find the cause, but solution is easy)

Wait for my howto later.
PS: it also requires a change on Keka info.plist

hey bro, still waiting for your solution here XD

hey bro, still waiting for your solution here XD

Don't hold your breath. It's the the same guy who wrote this confusing entry in June which was already supposed to be a "fix".

@pradorocchi Where is now man? Your promised it?

Since this is fixed (by Apple) in Big Sur I'm locking this conversation.