|Home » Learning Curve
Gosh PLIST Files!
Time for some remedial work.
There's evidently a lot of 'fake news' out there even in the world of Comp Sci. If you're looking for info on Apple's desktop OS, be careful what you believe.
Here's a good example.
Exactly why the question is posed and why it's answered as it's answered are both mysteries. Let's take them one line at a time.
> Deleting these PLIST files are shown in many troubleshooting methods for the solution of poor application performance.
They were before but not now. PLIST files in ~/Library/Preferences are where applications store settings. Good applications don't store anything to disk if no changes are made. Not all Apple applications are good applications. Far fewer third party applications are good applications. Add to that the fact that the Apple system will no longer remove empty files and you begin to see the extent of the issue.
> Users who are aware of these files also know that deleting these preference files will reset the preference of application and fix most of the problems.
NO. CATEGORICALLY NO. This was the case previously but NOT NOW. The Apple API documentation specifically warns about this. So where are application settings stored these days? Good question, next question. The only sure-fire way to remove application settings is from the command line.
% defaults delete [PLIST file minus the 'plist' extension]
Even that will occasionally misfire, so you should run the command at least twice.
> You can open and edit a PLIST file in a program like TextEdit.
Sure you can, but heaven help you if you try to save them that way. The default format for the Preferences directory is BINARY and you can't save binary from a text editor - which you should know (or at least pretend you do).
> Most of the outdated files will become faulty and start causing problems for the user.
They will? Do they suffer from bit fatigue or something? This is symptomatic of someone who is just padding an article with nonsense to make things seem more impressive.
> Preference PLIST files are harmless and its totally fine to delete them.
Or 'it's'. Deleting them will - if the application is written correctly and if it's a much earlier release of the OS - revert the app to 'factory defaults'. But, as stated, this is outdated today, about as relevant as 'fix your permissions'.
> But for the system files such as daemon property lists should not be considered the same as the preferences PLIST files. Deleting system files will prevent the application from launching or working properly.
Well duh, dude! Because you need a LOT of extra permissions to get at those? And no, they are not preferences files. They're CONFIGURATION files. Used to launch 'agents' and 'daemons'. So no, you don't want to mess with them.
[And if you ever do, in spite of the advice to the contrary, then you create a dedicated directory in your own home area and copy out the files you intend to mess with.]
> This is because most of the preference PLIST files will just reset the preference of application.
Once again: today this is FALSE. And it was false when this piece was published (May 2020). VERY FALSE. (Unfortunately.)
But there are today so many further considerations with application settings. Is the misbehaving application sandboxed? Do you even know what 'sandboxed' means? The relevant file might not be in 'Preferences' at all but in ~/Library/Containers. As to exactly how all this holds together: it's likely not everyone at Apple even knows. So, once again, you use the command line as explained above.
You could use a good and fast PLIST editor for quick inspection. Xcode is not your editor. You can always run this.
% defaults read [PLIST file minus the 'plist' extension]
Note that the PLIST file might still exist. Apple's system may no longer automatically remove empty PLIST files as before. But you'll still get the same diagnostic in such case.
Domain [PLIST file minus the 'plist' extension] does not exist
Run the command twice for good measure. Then you should be good to go.
Conclusion? Off-handed information by online dilettantes may be safe but then again may not be. So be careful. And remember: on-disk preferences are not necessarily the correct representation of an application's internal state, running or no. Not anymore. Unfortunately. So always use the command line.
And a word to Apple: Stop fucking around.
Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.
Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.
All Content and Software Copyright © Rixstep. All Rights Reserved.