@guylepage3 why'd you move this to doing? Are you working on it?

Complete:

We have the option to brand our DMG (background image, etc). There's an issue for that here: #357

What's the difference between DMG images and .app files? Why would we need or choose one over the other?

@shea256

What's the difference between DMG images and .app files?

.app "files" are app bundles. These are directory structures that include the executables and various resources (images, translations, etc) that make up an app. They appear in Finder as one "file", but you can right click on them and choose "See package contents" to view their contents.

DMG is a disk image...sort of like an ISO is a disk image of a CD or DVD. You put your .app bundle in the disk image, typically with a symlink to /Applications which makes it easy for the user to "install" it. It's the preferred way (according to apple) of shipping your app outside of the Mac app store.

Why would we need or choose one over the other?

We're not really choosing one over the other. Our .app and a symlink to /Applications are the only items included in the signed DMG disk image.

As to why we need to use a signed DMG:

macOS will translocate apps that aren't shipped in signed DMGs or signed installers.

Starting in OS X v10.12, you can no longer provide external code or data alongside your code-signed app in a zip archive or unsigned disk image. An app distributed outside the Mac App Store runs from a randomized path when it is launched and so cannot access such external resources.

If using a disk image to ship an app, users should drag the app from the image to its desired installation location (usually /Applications) before launching it. This also applies to apps installed via ZIP or other archive formats or apps downloaded to the Downloads directory: ask the user to drag the app to /Applications and launch it from there.

This practice avoids an attack where a validly signed app launched from a disk image, ZIP archive, or ISO (CD/DVD) image can load malicious code or content from untrusted locations on the same image or archive. Starting with macOS Sierra, running a newly-downloaded app from a disk image, archive, or the Downloads directory will cause Gatekeeper to isolate that app at a unspecified read-only location in the filesystem. This will prevent the app from accessing code or content using relative paths.

More information on what that means here: http://lapcatsoftware.com/articles/app-translocation.html

Also see "shipping your signed code": https://developer.apple.com/library/content/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG17

And 4. of https://sparkle-project.org/documentation/ (our update framework)

@shea256 tl;dr: from above is the translocation that happens from shipping an unsigned zip of the .app prevents auto update from working :-)