Dear Apple Support,
We are experiencing a critical issue affecting some of our macOS users during application updates via DMG.
In certain cases, when users attempt to update the app by dragging it from the mounted DMG to the /Applications folder (replacing the old version), the application becomes corrupted. Users receive an error indicating that the app cannot be opened.
On retry, they are met with an error stating that the app cannot be overwritten.
Upon inspection, the resulting application bundle is incomplete and contains only the following structure:
.
└── Contents
└── CodeResources
The only known workaround is to completely remove the existing app from /Applications before copying the new version — this resolves the issue consistently.
We’ve observed this issue in the field with increasing frequency, which negatively impacts user trust. We also found similar reports from other developers (e.g., https://github.com/warpdotdev/Warp/issues/5492), suggesting a broader issue.
Questions:
What could be the underlying cause of this behavior on macOS (e.g., MDM, security policies, filesystem behavior)? Are there any recommended practices to prevent or mitigate this issue when updating apps via DMG? We would appreciate any guidance or clarification you can provide.
Best regards, Ivan Poluianov
In certain cases, when users attempt to update the app by dragging it from the mounted DMG to the /Applications folder (replacing the old version), the application becomes corrupted. Users receive an error indicating that the app cannot be opened.
Please file a bug on this and post the bug number back here once it's filed. Attach whatever diagnostic data you can, particularly a sysdiagnose from a machine that's had the failure along with the timing information about when the failure occurred.
What could be the underlying cause of this behavior on macOS (e.g., MDM, security policies, filesystem behavior)? Are there any recommended practices to prevent or mitigate this issue when updating apps via DMG?
I'm not sure of the exact cause in your case, but I've seen a few bugs that were seemed be be caused by objects inside the app bundle not being owned (or modifiable) by the current user. A few questions/testing suggestions:
-
What was the source of the original app bundle? Copied from a DMG, App Store install, direct PGK install, etc.
-
In terms of testing/reproducing the issue, what happens if you do the initial install as one user and the replace as a different user? I'd try this with all combinations of admin/standard account configurations.
-
If you're able to reproduce the issue and/or have good access to machine that is experience the issue, I'd take a close look at exactly what objects are in the newly created bundle and what their permissions are. My guess is that you'll find something "odd", which is what's actually causing the problem.
We would appreciate any guidance or clarification you can provide.
Unfortunately, the only real "workaround" for something like this is to move/delete the existing object so that you're doing a "clean" copy without any replacement.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
