PUNCHCARD Download Get Punchcard $9

Running a Mac app from its disk image: why things break

· 6 min read

If you open an app by double-clicking it inside a downloaded disk image, or straight from your Downloads folder, macOS runs a hidden, read-only copy of it rather than an installed app. It launches and looks normal, but anything that depends on the app being installed breaks quietly: other apps cannot find it, it is gone once the image is ejected, and updates have nowhere to write. The fix takes a minute: quit it, drag it into Applications in Finder, eject the image, and open it from Applications.

What a disk image is for

A .dmg file is a disk image: a single file that macOS mounts as if it were a drive. Open one and it appears in Finder’s sidebar, with its contents in a window. Developers use it as a delivery box. It carries an app through a download in one piece, and it lets them lay out a window with the app next to a shortcut to Applications, as a hint to drag one onto the other.

The box is not meant to be where the app lives. A downloaded image is usually read-only, it exists under /Volumes/ only while it is mounted, and it goes away when you eject it or restart. Double-clicking the app inside it works anyway, which is exactly why so many people never move it.

What macOS does when you open it there

Since macOS Sierra, Gatekeeper has handled this case with App Translocation. When you open a downloaded app that is still marked as quarantined, from the disk image or folder it arrived in, macOS runs it from a hidden, randomized, read-only location instead. It is a security measure: the app runs apart from whatever else came with it, so it cannot quietly pick up files placed beside it.

The catch is that the translocated copy is not installed as far as macOS is concerned. macOS keeps a registry of the apps on the Mac, and that registry does not treat the translocated copy as one of them. Other apps that list installed apps can therefore miss it entirely.

The symptoms

Running from a disk image rarely produces an error message. It produces odd behavior that looks like a bug somewhere else:

  • Other apps do not see it as installed. Anything that lists the apps on your Mac, or looks one up so it can work with it, can come back as if the app were not there.
  • It is gone after you eject the image or restart. The app you were using lived on the image. Eject it, or restart, and there is no copy of the app on the Mac at all. Anything you set to open it later has nothing to find.
  • Updates cannot land. An app that updates itself replaces its own files, and a read-only copy cannot be written to.

None of these point at the real cause, which is why the problem can go unnoticed.

A real example: a browser that seemed not to exist

Our own app, Punchcard, has an optional setting, Itemize websites, that prints the sites you used in Chrome, Brave, Edge or Vivaldi on its daily receipt. Its Settings list each supported browser on the Mac, and that list relied on macOS to say which browsers were installed.

In Punchcard 1.3.0, a customer using Brave switched the setting on and saw “No supported browser on this Mac yet”. When we reproduced it, the cause was exactly this: a Brave that is running but not installed as far as macOS is concerned. macOS did not count that copy as installed, so the list came up empty.

Punchcard 1.3.1 also lists browsers that are running, whatever macOS reports. That fixes our side of it. It does not change anything for Brave: other apps that ask macOS the same question can still miss it, and a read-only copy is still a read-only copy. The durable fix was the one below. Tracking website time in Brave, Edge or Vivaldi covers the rest of that setup.

How to see where an app is running from

In Activity Monitor:

  1. Open Activity Monitor, in Applications, Utilities.
  2. Find the app in the process list. The search field in the toolbar helps.
  3. Double-click it and open the Open Files and Ports tab.
  4. The path of the app is near the top.

In Terminal, one line does it. Brave is the example here:

ps -axo command | grep -i "brave browser.app/contents/macos"

For another app, swap in its name and keep the .app/contents/macos ending. One line of the output is the grep command matching itself; ignore it.

Then read the path:

  • Starts with /Applications/: installed. All is well.
  • Starts with /Volumes/: running from the disk image.
  • Contains AppTranslocation: a translocated copy, usually of an app opened from a disk image or from Downloads.

The fix, step by step

  1. Quit the app with Command-Q. Closing its window is not enough.
  2. In Finder, drag the app from the disk image window (or from Downloads) onto Applications, either the folder in the sidebar or the shortcut inside the image window.
  3. Eject the disk image with the eject button next to it in Finder’s sidebar. You can then delete the .dmg file.
  4. Open the app from Applications. You may see a confirmation that it was downloaded from the internet; that is Gatekeeper checking it, as intended.
  5. Check again with Activity Monitor or the ps line. The path should now start with /Applications/.

Do the move in Finder. Moving it with Finder is what clears the condition. Some advice online suggests removing the quarantine mark in Terminal instead; that makes the symptom go away by skipping a check that exists to protect you, so we do not recommend it.

If you had set the app to open at login while it ran from the image, look at System Settings, General, Login Items afterwards and make sure the copy in Applications is the one listed. Login items on a Mac covers where else apps start from.

Zip downloads and installer packages

  • Zip files. A .zip unpacks into Downloads, and the app that comes out is still a download. Open it from there and it is translocated the same way. Drag it to Applications before the first launch.
  • Signed .pkg installers. An installer package puts the app into Applications itself, so there is nothing to drag and nothing runs from the download. Punchcard ships this way.
  • The Mac App Store. Apps from it install straight into Applications.

If an app is in Applications and still will not start or stay in the menu bar, the cause is elsewhere. A menu bar app is missing after a macOS update has a diagnosis order for that case.

Questions

Is it dangerous to run an app from its disk image? Not in itself; translocation exists to make it safer. It is fragile rather than risky: fine for a quick look, wrong for an app you plan to keep.

Can I delete the .dmg after moving the app? Yes, once the app is in Applications and the image is ejected. Keep it only if you want an installer for later.

Will moving the app lose its settings or data? Usually not. Most apps keep settings and data in your user Library, not inside the app itself. Punchcard, for example, keeps its record in ~/Library/Application Support/Punchcard/punchcard.sqlite, so moving the app leaves it untouched. Where Mac apps keep your data shows how to find it for others.

Why do some apps offer to move themselves to Applications? Because of everything above. An app that notices it is running from a disk image or Downloads can offer to move itself into Applications and relaunch from there, which is the same fix done for you.