Keeping users on the latest version of the Dropbox desktop app is critical. It allows our developers to rapidly innovate, showcase new features to our users, maintain compatibility with server endpoints, and mitigate risk of incompatibilities that may creep in with platform/OS changes.

Our auto-update system, as originally designed, was written as a feature of the desktop client. Basically, as part of regular file syncing, the server can send down an entry in the metadata that says, “Please update to version X with checksum Y.” The client would then download the file, verify the checksum, open the payload, replace the files on disk, restart the app and boom! It would be running version X. This meant that the client had to be running in order to update itself. More importantly, it also meant that small bugs in other parts of the client could affect auto-update. Eliminating these potential failures was crucial to maintain continuity of Dropbox’s value to its users. So we decided it was time to move our auto-update mechanism out of the main app.

Back in 2014, we accomplished this on Windows by taking Google’s Omaha project and adapting it to our needs. Since Omaha is an out-of-process updater, if we shipped a completely broken client we could still update it. This project took a while to finish since Omaha is also an installer/meta-installer and we had to rework several of our installation flows to make it all work well. But we were happy with the end result.

Last year, we decided we wanted to do the same for macOS. Usually we like to start projects like this by doing lots of research. Why reinvent the wheel if you don’t have to? Google did have an open source project called UpdateEngine which was essentially “Omaha for Mac,” but the last code drop was back in 2008 and it wouldn’t compile cleanly with modern XCode, so we decided not to use it. Other options we looked at had other difficulties. Some were in-process only, or supported only one app, or only supported Sierra (we support Dropbox on some pretty old versions of OS X) so we couldn’t use them.

So we decided to write our own auto-update system. This gave us a lot of flexibility in the feature set, and rather than bolting stuff on after the fact, as we did with Omaha, we could build the exact system we needed. (We also didn’t have to use XML for the API 😃.)

We built an “app” called DropboxMacUpdate. Because we needed to support old systems (Mac OS 10.7+) we wrote it in ObjC rather than using Swift. Picking one of Apple’s languages let us leverage many of the OS features without too much trouble. (In comparison, the client is written in Python, and when we need to do some OS-specific thing we have to write lots of bridge code.)

Upon installation, DropboxMacUpdate.app will register itself with launchd . This is a well known technique that will allow the app to periodically check for updates. Any Dropbox app can register with DropboxMacUpdate by giving it the path of where it’s installed. Every five hours, DropboxMacUpdate will check its registration database for apps, then check the paths of those apps for the installed version and send them to the server. The server will check if an update is needed and will reply with the version, the URL and the hash of the payload. DropboxMacUpdate then downloads the payload and uses it to update the app. This all happens without the need for any user interaction.

Shipping updates is no trivial matter. We have to ensure that there’s no way for a user to get a “bad” version of the client. So we employ multiple layers of security checks.

1. By default, the connection to the Dropbox server uses TLS with certificate pinning. This way we know we’re talking to dropbox.com and only dropbox.com
2. The server replies with the sha256 hash of the payload. This gets verified once we download the payload.
3. .dbx_install will verify that the .app is signed by Dropbox before copying it to its final location.
4. Additionally, on 10.12+ systems the DMG payload is verified as an in-depth security measure. (Sadly, DMG signature verification is not implemented in earlier versions of OS X.)

But most importantly, being able to deliver secure, reliable, and rapid updates to our users is the biggest security improvement.