I have noticed quite a few times that after viewing a particular image and quitting Preview manually, Preview still remains active in the background sucking up huge chunks memory/RAM. It only stops after force quitting it. I don't know why this does happen!

  • How did you close it? Did you use File > Quit (⌘Q), or did you just close the window? – SilverWolf - Reinstate Monica Sep 24 '17 at 15:51
  • Right Click and Quit then Force Quit – Sayan Sep 24 '17 at 15:53
  • So, you try to quit it, and it then locks up without quitting? Do you get the spinning beach ball of doom? – SilverWolf - Reinstate Monica Sep 24 '17 at 15:57
  • @seaturtle And it still remains active in the background! – Sayan Sep 24 '17 at 15:58
  • See after I have successfully opened an image with preview I close preview by right>quit (Mouse) then I go to activity monitor and I see that preview is still active in the background so until and unless I press Command-Option-Escape and force quit it, it doesn't quits and I don't get the beach ball of doom! – Sayan Sep 24 '17 at 16:00

This happens a lot. Preview is supposed to auto-terminate – but often cannot. As of this writing: this is a bug not fixed in Sierra and not fixed in High Sierra. Even force quitting the app from the Dock might surprise you: after one trigger-the-bug files hangs Preview, force quit the app from the Dock and open Activity Monitor. Even though the app has lost its indicator light in the Dock and will not show up if you switch through your applications with Cmd+Tab it may very well be still shown as running– and sometimes with quite a hefty CPU toll. Since this is a bug in all versions of Preview that are supposed to be able to be auto-terminated, you have not many options:

  • disable auto-termination to mitigate some of these effects and get a bit more manual control over the situation with defaults write -g NSDisableAutomaticTermination -bool yes
  • if it happens: force-quit the app(-process) with Activity Monitor
  • or do it from Terminal: sudo killall Preview

Best option of course is not to use the buggy program and choose an alternative picture and PDF viewer.

| improve this answer | |
  • If I use the first option what are the changes I will encounter and the will the changes be for each and every app which are not needed to get this change? – Sayan Sep 28 '17 at 9:50
  • Only apps that should auto-erminate will be affected. The observed behaviour should be like in older systems: only when you quit an app will it go. Try it out. If that does not suit you reverse it with defaults delete -g NSDisableAutomaticTermination – LаngLаngС Sep 28 '17 at 10:47
  • I tried the first solution and fortunately It worked! – Sayan Sep 28 '17 at 12:42
  • Can you recommend some good alternatives? – Sayan Sep 29 '17 at 15:41
  • Full spec PDF compatibility? Adobe Reader. pdfexpert.com, maybe foxit foxitsoftware.com – LаngLаngС Sep 30 '17 at 8:45

This is by design and expected behavior if your memory pressure is green in activity monitor. Both iOS and macOS will keep some apps resident until compressed memory or paging is called for and then purge them. Changes in the kernel relating to App Nap, sudden termination, background processing allow many more states for applications than just running and quit.

Why do you care whether the process is still in memory? It's not running. Preview.app supports Automatic Termination, the system will remove it from memory when it is necessary to to so.

| improve this answer | |
  • 1
    That is where the problem is, it is not terminating by it-self and thus sucking up upto 20% of my CPU and RAM – Sayan Sep 24 '17 at 16:23
  • @Sayan I’ve added some context and a developer link on the many states that processes now can inhabit. What is the memory pressure when you feel the app should be terminated? Can you reproduce that after a clean restart? – bmike Sep 30 '17 at 17:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .