Progressive Rollout via Sparkle

When using Sparkle to provide in-app updates on macOS the default behavior is that an update is available for all users simultaneously whenever the Appcast.xml file is updated.

Modern agile methodologies, such as those found in services, favor staging the rollout of updated functionality to an increasingly larger group of users. This strategy provides a safety valve for issues that weren't caught during testing or that crop up unexpectedly, like a signing issue.

Here you'll find a thoroughly tested collection of classes in a sample project along with notes for additional changes you might want to make to your process. If you have any questions, concerns, or improvements please reach out per the notes below.

Originally implemented and utilized in SourceTree.


These classes are meant to be used in conjunction with Sparkle; they are not a replacement. Fastlane is an optional way to facilitate deployment but both options will be discussed.

Carthage is the preferred option for this project. To get set up in your checkout run carthage update --platform Mac which will checkout and build managed dependencies. After that you'll be able to build and run ProgressiveUpdater.


Please refer to the following documents for details:

  • CODE OF - Community Code of Conduct; play nice!
  • - Pull Request Guidelines
  • - Details on client, scripting, and assorted other aspects required for deployment
  • Headers - All classes include HeaderDoc compatible comments for easy access


The simplest way to run tests is to use scan from the Fastlane suite. All unit tests and their expectations will be exercised. You can also run and debug them in Xcode when necessary.


Pull requests, issues, and comments are welcome provided they conform to our Code of Conduct. See the existing issues for things to start contributing. When starting a pull request please be sure to follow our Contributing Guidelines to speed up review.

For bigger proposed changes, make sure you start a discussion first by creating an issue and explaining the intended change.

Atlassian requires contributors to sign a Contributor License Agreement, known as a CLA. This serves as a record stating that the contributor is entitled to contribute the code/documentation/translation to the project and is willing to have it used in distributions and derivative works (or is willing to transfer ownership).

Prior to accepting your contributions we ask that you please follow the appropriate link below to digitally sign the CLA. The Corporate CLA is for those who are
contributing as a member of an organization and the individual CLA is for those contributing as an individual.


Copyright (c) 2016 Atlassian and others.
Apache 2.0 licensed, see LICENSE.txt file.