Distribution

The Last Piece — Where to Put the Updates In Part 1 we prepared the Developer ID certificate and notarization, and in Part 2 we prepared the Sparkle signing key. That means we now have a way to sign the app, notarize it, and verify the authenticity of updates. But the location pointed to by SUFeedURL (https://updates.example.com/appcast.xml), which we wrote into the app’s Info.plist in Part 2, still has nothing in it. In this final part, we’ll host the update feed that goes in that spot and finish the build settings, completing the entire one-time setup. ...

Automatic Updates, and Why You Need One More Layer of Signing In Part 1, we finished setting up the Developer ID certificate and notarization. With that, you’re ready to deliver the app to users for the first time. But an app isn’t done after a single release — you have to keep shipping new versions that fix bugs and add features. For a Mac App Store app, the App Store handles updates for you. A directly distributed app doesn’t get that, so you have to build an automatic-update feature into the app yourself. On macOS, the de facto standard for this role is the open-source framework Sparkle. With Sparkle in place, the app periodically checks an “update feed (appcast),” and if a new version exists, it notifies the user, downloads it, and installs it. ...

What It Means to Distribute Directly with Developer ID There are broadly two ways to get a macOS app into users’ hands. One is through the Mac App Store (MAS), and the other is direct distribution — letting users download a .dmg (or .app) file you build yourself from a website, GitHub, or similar. Direct distribution has clear advantages. You don’t have to wait for App Store review, there are no payment commissions, and you can ship updates whenever and however you like. In exchange, the things the App Store used to handle for you — code signing, notarization, and automatic updates — are now yours to set up. ...