[quote='788938022, DTS Engineer, /thread/756027?answerId=788938022#788938022'] Are you using hdiutil for that? And, if so, I presume you hide that mount from the user? [/quote] Why yes, I am using hdiutil to mount the image. Specifically, I'm using: (translating Obj-C to pseudocode just for brevity) diskImagePath = "<path to dmg>" mountPath = "/Volumes/" + UUID().uuidString /usr/bin/hdiutil attach "$diskImagePath" -mountpoint "$mountPath" -nobrowse -noautoopen And, later, to unmount, I'm using: /usr/bin/hdiutil detach "$mountPath" -force [quote='788938022, DTS Engineer, /thread/756027?answerId=788938022#788938022'] Your primary concern seems to be the point at which the system ingests your stapled ticket. [/quote] That's correct. More precisely, I'm actually not completely sure what to be scared of in this ecosystem. I definitely want normal security measures to work as intended. This is why I phrased the original question (albeit somewhat confusingly) as "what is the best practice here", rather than "how do I fix this rare problem". For example, if you were to (hypothetically) come back and say, "in this scenario, a notarized DMG is appropriate because , and you should also do to avoid ", then what that tells me is: The general approach I'm using today is here to stay, at least for now. Thus, it's worth my time to add more automated metrics around my hdiutil attach failure (see "Skippable Backstory" in the original post), and file a (useful) bug report. And, because I'm using the technologies in a recommended way, I'm more likely to get a useful answer back, which is good for me. On the other hand, if you were to say, "in this scenario, a notarized DMG is bad because , and you should use instead", then what that tells me is: There's a risk that my undesirable use of this technology is contributing to my hdiutil attach problem. Thus, it's not worth my time to fix the hdiutil attach problem, and instead, I should reengineer my fancy self-update system to operate in a way that is recommended by Apple And, applying the recommendations may completely sidestep my problems, which is good for me.

[quote='788832022, crazymacguy, /thread/756027?answerId=788832022#788832022, /profile/crazymacguy'] For pre-macOS 10.15, we also have a kernel extension. [/quote] [quote='788851022, DTS Engineer, /thread/756027?answerId=788851022#788851022'] So that’s only necessary, and only installed, on systems prior to macOS 10.15? [/quote] Correct. That's a big part of why I'm itching to drop support for 10.14 and earlier. Just waiting for the populations to drop low enough.

[quote='788790022, DTS Engineer, /thread/756027?answerId=788790022#788790022'] Does your app need an installer at all? That is, does the installer package install components outside of the main app in /Applications? If so, what sort of components? [/quote] You're asking an engineer whether or not something is possible? ;) No, we do not technically need an installer. We do currently install files outside of the main app bundle, yes — but, honestly, the only reason we're using an installer package today is because that's the way it was originally designed. The only components remaining outside of the main application bundle are launch agents, launch daemons, and command-line executables. For pre-macOS 10.15, we also have a kernel extension. And, for supported browsers, we also have browser extensions that go in "magical" system folders, such as (for example) in /Library/Application Support/Mozilla/Extensions/. The installer package understands these details, and also correctly requires a system reboot when needed. More components used to exist; as they have been replaced and/or upgraded over the years, more often than not, they get moved to inside the main application bundle. I have hope that we will eventually become an app that can be installed by dragging a single app into the Applications folder, but it's a slow process. We'll make a huge step forward when we drop support for 10.14 and older, because the kext and the conditional reboot requirement will both go away. In summary, I think my answer is actually both. Today, yes, we "require" an installer package. But, I'm also quite interested in the future where our app is a single bundle.