Icon issue on macOS 10.15 Catalina

[DesertRec]

👉 This seems will never be fixed in Catalina. Big Sur has this fixed anyway.

Original report:

I recently bought Keka from app store when I was using Mojave, I then made a clean install with Catalina and now the zip icon doesn't look right.

[aonez]

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

[Deathlike]

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.

[aonez]

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.

[aonez]

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

[aonez]

Same on 10.15.1 Beta 2 (19B77a).

[aonez]

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

[DesertRec]

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

[abdelle7]

Same here on macOS 10.15 (19A603).

[aonez]

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.

[DesertRec]

I just reported the issue.

[naturalkei]

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

[jianglai]

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.

[alvarnell]

Is it really a problem, or just a change?

Sent from my iPad

-Al-

[aonez]

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.

[aonez]

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

[aonez]

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

[timothy-morph]

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

[aonez]

Please report it to Apple.

On Mon, 18 Nov 2019 at 17:29, timothy-morph [email protected] wrote:

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

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/aonez/Keka/issues/453?email_source=notifications&email_token=AADVHIYPYP3ENHCLMKG3CM3QUK7GVA5CNFSM4I67PK3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEELBJQY#issuecomment-555095235, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADVHI5AWQLUVRU3Q65YSYDQUK7GVANCNFSM4I67PK3A .

[jankytay]

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)

[aonez]

@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?

[aonez]

@jankytay could you share that self signed build?

[jankytay]

@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

[jankytay]

i think trying to reproduce the whole process locally is more efficient than me uploading a 20M+ zip file 😅

[aonez]

@jankytay no change for me. Note that some formats not compatible with the built-in archiver (like TXZ and TLZ) have that IconVariant key and work properly.

[aonez]

Still no change in 10.15.2 beta 3 (19C46a).

[aonez]

@jankytay, this build only has ZIP in the Info.Plist, with no other than the default keys in it: Keka.tar.zip

Fails the same for me.

[jankytay]

huh, now this is one tricky bug to pinpoint the issue welp, i tried...

[aonez]

yep, thanks a lot for your feedback anyway ^^ Still this seems to be a bug in Catalina's lsd or similar that they're not yet taking care of.

[jankytay]

no problem, thank you for verifying it ~~at least it works on my machine™~~

[mupkoo]

Not sure if this is documented somewhere, but this might help https://stackoverflow.com/questions/58220256/file-icons-getting-changed-to-app-icon-in-macos-catalina

[aonez]

Thanks for the tip @mupkoo! It's the same issue but the solution suggested by Thomas Zoechling was already applied in Keka long time ago and does not solve the Catalina issue.

[qyaaang]

I also have the same issue with Microsoft excel file icon and Adobe Acrobat file icon.

[aonez]

@yangqun1993 be sure to report it to Apple :)

[abdelle7]

@aonez Any good news ??

[aonez]

@abdelle7 sadly in the latest 10.15.3 Beta 1 (19D49f) this is still present...

[adamwinn]

I'm seeing this with all sorts of other apps too

[fACEd-star]

Try COMPLETELY uninstalling VLC media player (if you have) restart and then install again. It works for me. It was a problem past association some archives (rar?) with VLC...

[mamengcode]

I also have the same issue with Microsoft excel file icon and Adobe Acrobat file icon.

Is this a bug of macOS Catalina? I just have it for pdf files, and my excel files are okay.

[aonez]

@flyseeksky it is indeed a bug of macOS Catalina, please see the instructions to report it to Apple.

[bradleybowman]

Also experiencing this issue, and have been since the Catalina upgrade.

I only began using macOS and Keka shortly before Catalina was released (picked up a 2012 Mac Mini for a good price, and grabbed Keka from the App Store). Wish I'd found this thread earlier; I thought it was just me. Reported the issue to Apple per your instructions.

Thanks for your work!

[aonez]

Thanks @bradleybowman! I've checked 10.15.4 beta 5 last week and still has this issue. No word on the issues reported to Apple, sadly. It seems this will not be fixed in Catalina, maybe in 10.16.

[ghost]

Very interesting. I got this issue now too.

-Got a new Mac with Catalina pre-installed -Upgraded to latest Catalina version -Downloaded Archiver app (before found about Keka) -Zip file icons have Archiver's icon on top of the generic white document icon -Downloaded IINA media player -MKV file type icons appeared normally with IINA's MKV specific icon -Downloaded Submerge which changed all media files to open with it without asking the user -Changed MKV and other media files to open with IINA again -Now the MKV file type icon is the IINA app icon on top of the generic white document icon

I can change the MKV file type icon manually per file using Get Info but obviously it doesn't get changed across every MKV, only the selected one.

Very frustrating.

Submitted feedback to Apple using Feedback Assistant. Recommend others to do the same.

How can such a simple thing be broken so long?

[aonez]

How can such a simple thing be broken so long

Catalina reminds me of Lion... I'm just skipping it altogether, it only lives in a virtual machine. Mojave is pretty stable.

[JihongWEI]

This may be a bug of Catalina. At present, my personal solution is to create a new account. The file ICONS with the suffix zip and docx can be displayed normally.

[syo093c]

I also have this problem. IINA and Keka are both work incorrectly. Catalina is a PURE GARBAGE！

[i0ntempest]

I got this solved using a little piece of software called RCDefaultApp. It's old and a bit buggy but does the job for me. You first install the preference panel, then goto Extensions tab, then for every file type that has the bad icon, choose <disable>. It may then show another app is selected, but if you do $ killall Finder the icon should be fixed.

[T-Bone90]

I got this solved using a little piece of software called RCDefaultApp. It's old and a bit buggy but does the job for me. You first install the preference panel, then goto Extensions tab, then for every file type that has the bad icon, choose <disable>. It may then show another app is selected, but if you do $ killall Finder the icon should be fixed.

RCDefaultApp dosn't work with Catalina. Or how it works?

[i0ntempest]

I got this solved using a little piece of software called RCDefaultApp. It's old and a bit buggy but does the job for me. You first install the preference panel, then goto Extensions tab, then for every file type that has the bad icon, choose <disable>. It may then show another app is selected, but if you do $ killall Finder the icon should be fixed.

RCDefaultApp dosn't work with Catalina. Or how it works?

It is really outdated but works for me, at least for this purpose.

[T-Bone90]

I got this solved using a little piece of software called RCDefaultApp. It's old and a bit buggy but does the job for me. You first install the preference panel, then goto Extensions tab, then for every file type that has the bad icon, choose <disable>. It may then show another app is selected, but if you do $ killall Finder the icon should be fixed.

RCDefaultApp dosn't work with Catalina. Or how it works?

It is really outdated but works for me, at least for this purpose.

How? I install it but Catalina won't open the App in the Settings. I only have the option move to the trash.

[i0ntempest]

I got this solved using a little piece of software called RCDefaultApp. It's old and a bit buggy but does the job for me. You first install the preference panel, then goto Extensions tab, then for every file type that has the bad icon, choose <disable>. It may then show another app is selected, but if you do $ killall Finder the icon should be fixed.

RCDefaultApp dosn't work with Catalina. Or how it works?

It is really outdated but works for me, at least for this purpose.

How? I install it but Catalina won't open the App in the Settings. I only have the option move to the trash.

Try manually copying it to /Library/PreferencePanes first, if doesn’t work try disabling gatekeeper: $ sudo spctl --master-disable, if still doesn’t work disable SIP

[T-Bone90]

OK the App works now but I couldn't get the icons to work. Once they were back to standard. But not a perfect Keka icon (zip e.g.). I think we must wait for an update. :-(

[i0ntempest]

Yea my goal is just make the icons back to standard, not the ugly app icon. Maybe try setting it to Keka in RC and see what you get.

[rk492]

https://github.com/Lord-Kamina/SwiftDefaultApps#usage-notes

I am trying with this, but I didn't get any positive result. I have the same problem with IINA or Skim

[i0ntempest]

https://github.com/Lord-Kamina/SwiftDefaultApps#usage-notes

I am trying with this, but I didn't get any positive result. I have the same problem with IINA or Skim

I’ve tried this, it claims to be a replacement of the one I mentioned but it doesn’t allow you to edit extensions.

[andyapple]

12/05/2020

I am having issues with .rar icon. On a clean installation of macOS Catalina, when i install Keka it works great and i can see the corrent .rar icon. As soon as I install VLC Media Player, I can't see anymore the correct .rar icon, i just see the kekaworkflow.icns. Keka is selected as default app for all .rar files, and it opens them correctly but the icon is not the correct one. The problem starst as soon as I open VLC for the first time. Can you help me to fix this?

Thanks, Andyapple

[aonez]

@andyapple this is a bug in macOS Catalina, you should report it to Apple 👉 https://github.com/aonez/Keka/issues/453#issue-504655013

[andyapple]

@andyapple this is a bug in macOS Catalina, you should report it to Apple 👉 #453 (comment)

Ok, thank you!!

[bitti]

I just updated to 10.15.5 but the bug still seems to persist. I suppose spamming Apple with bug reports doesn't help?

[jianglai]

I honestly don't think it will be fixed in Catalina. Hopefully 10.16 fixes it.

[kytta]

Idk if fixing the bug is easier in a system that comes in 5 months rather than in a series of minor updates. I fear this bug will persist a long time after 🙄

[aonez]

@NickKaramoff I hope you're wrong 🤞🏼

[miguelbesy]

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?

[miguelbesy]

I downloaded some apps from the App Store just for testing and the icons of Oka Unarchiver and RAR Extractor Lite shows up correctly with VLC installed, Keka and The Unarchiver once VLC is installed the RAR icon shows up as blank page with the logo on it.

So is this a Catalina issue or a bug from the apps?

[jianglai]

Idk if fixing the bug is easier in a system that comes in 5 months rather than in a series of minor updates. I fear this bug will persist a long time after 🙄

My hope is that they already have a fix in place in 10.16 and just never bothered to backport it to 10.15.

[aonez]

@miguelbesy can you share the Info.plist file inside one of those apps (App.app/Contents/Info.plist) that you mention are not affected with this bug?

[miguelbesy]

@aonez im not in the computer right now but you can search them in the App Store they are free apps.

[bitti]

Oka shows up correctly

I tried out both apps and can't confirm that. Oka doesn't even define different icons for different filetypes so I don't see how it should help in debugging this issue. But maybe we should define first what the "issue" actually is. It's surely not just about the VLC icon which was mentioned as an example. I would define it as follows:

Given:

• We have an app where its Contents/Info.plist declares specific icons for certain types with certain file extensions in the CFBundleDocumentTypes and/or UTExportedTypeDeclarations sections
• The app is set as the default "open with" app for at least some of these types
• Some of these types are already defined on system level (i.e. in /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist)

Issue: For types which are already system defined (or possibly by other apps?) we don't see the file icon specified for this type but the generic app icon instead.

Expected: We should see the specific file icon regardless if the type was already specified elsewhere.

To illustrate this let me take what I see for "RAR Extractor Lite" as an example:

Here we can see the different manifestations of the issue:

• Several file icons like for types 7z and alz show up correctly, supposedly because they are not in /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist
• Others which are in the CoreServices Info.plist like gz or gzip just show the generic "RAR Extractor" app icon, even though it specifies specific icons for these types just like for the others
• Even though "RAR Extrator" defines the icon for file extensions zip and z01 in the same CFBundleTypeExtensions type definition, only the second one shows the specific icon (supposedly because only zip is defined in CoreServices)
• Interestingly types like bin which I didn't switch to open by "RAR Extractor" by default show specific icons specified by the "Archive Utility" CoreService app, even though these types are also in /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist
• Icons which I switched to be opened by "RAR Extractor" by default and then switched back to " Archive Utility" started to show the app icon instead of the file specific icon, even though that was working before (as you can see for extensions bz, bz2 and tar

When looking into /System/Library/CoreServices/Applications/Archive Utility.app/Contents/Info.plist it's interesting to note that it doesn't even bother to specify a UTExportedTypeDeclarations section but it includes these key/value pair for each type:

			<key>LSIsAppleDefaultForType</key>
			<true/>

I think this attribute is basically undocumented and probably not supposed to be used by 3rd party apps. But the last point above suggests, that even this attribute doesn't help in all cases.

So before continuing the discussion I suggest we should confirm first if we can agree on this definition of the issue.

[aonez]

Thanks a lot for the details @bitti. I'll check on /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist since I was just focusing on Archive Utility. But seems you're 100% right.

<key>LSIsAppleDefaultForType</key> is most probably for macOS to set the initial default apps, maybe during the OS installation or the first user login. This one appears also in TextEdit, for example.

Oka doesn't even define different icons

Thanks for checking that too.

[bitti]

As a follow up I want to add a few observations as to what happened after I deinstalled "RAR Extractor"

So the types, for which "Archive Utility" defines specific icons, recovered; except fortar. To this I have to add that I put bz2 back to open with "RAR Extractor" before I deinstalled it. If that had any bearing on the fact that bz also got recovered I can only speculate (maybe because "RAR Extractor" defined both file extensions in the same CFBundleTypeExtensions).

In any case one can see that for what should be a purely declarative thing is now dependent on some kind of hidden state which in turn depends on the order one does things or does not. I don't see how Apple can not acknowledge this as a bug.

To explore this idea of uninstalling an app to recover file specific icons further, I tried it out for my usecase for which I stumbled over this bug in the first place. In fact it was not because of Keka but because I try to adapt my Emacs.app Info.plist to get type specific icons. Currently it's looking like this for some selection of types:

One can see:

• The type specific icon for xsdl works as expected, since it's not in CoreServices
• The type specific icon for java curiously started working after I set the LSIsAppleDefaultForType
• Types csh, sh, js only show the generic app Icon, even though I also set the LSIsAppleDefaultForType flag on these
• For xml I didn't set this flag and so we see what is expected by this bug

After this I installed a random editor, here I chose BBedit, and changed the associations for the non working types (I didn't want to risk to destroy my setup for java and xsdl):

After I deinstalled BBedit I got this:

So in case of js I got lucky and it fell back to the Emacs association and I got the type specific icon I defined for it. For sh and xml I got less lucky and it got reassociated to Xcode (even though I set LSIsAppleDefaultForType for sh). The same goes for csh which got reassociated to iTerm.

So it seems there is a way to get at least some items working, but it's based on luck. (Edit: See below for a different conclusion.)

[miguelbesy]

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

[miguelbesy]

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

[miguelbesy]

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!

[bitti]

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).

[aonez]

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

[bitti]

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.

[pptxman]

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.

[aonez]

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.

[DesertRec]

Finally😉

[miguelbesy]

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

[aonez]

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

[azuryst]

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

[pradorocchi]

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.

[aonez]

@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.

[pradorocchi]

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

[Mancerrss]

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?

[Alraemon]

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

[bitti]

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".

[Mancerrss]

@pradorocchi Where is now man? Your promised it?

[aonez]

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