It's easy to make the over-reaching generalization that everything is different on a Mac. And sure, there are some key differences, but regardless of the OS associated with it, CI/CD is generally the same at a high level. Most of the distinctions in the world of Mac CI/CD is the product of Mac-specific tools and best practices.

What’s the same:

  • Linux. Mac’s OS is based on Unix, about 90% of the Linux commands still work
  • Creation of virtual machines (provisioning)
  • A group space to collaborate and then deploy new code being developed (the pipeline)
  • Applying updates/new external packages (rehydration/CM)

This last step warrants a bit more explanation. The practice of updating and otherwise changing a base VM image is called rehydration (in the case of stateless/ephemeral/immutable infrastructure) or configuration management (for stateful or mutable architectures). This is where Puppet and Chef are often used, and Ansible can be used for this function as well.

Chart- Process of applying updates/new external packages (rehydration/CM)

What’s different:

Code: ‍Differences are driven in large part by what tools the Apple staff gets behind. The path of least resistance is almost certainly that which Apple, with its far-reaching influence, advocates.  Unlike Windows or supported Linux offerings like RedHat or CentOS, the Apple development staff has dominated their space with over 40 years of innovation, and many Apple concepts have become the way to do business for all platforms (such as smartphones).

Databases: Older apps and programs had a database as a core feature, and many systems still do. While the current best practice is to avoid a populated database (one which only works with a historical record) when possible, the legacy code that exists is almost always reliant on a database's history. Databases represent a point of "state": a system that needs to know its own history, and cannot be fully re-created "on the fly." Maintaining a database is a key architecture feature of many CI/CD systems. The terms for this are either a "stateful system" or "mutable infrastructure". Ansible was designed with this flow in mind and can address all the components of this infrastructure.  

In general, Mac apps have always avoided this. This means a different architecture is generally employed, often referred to as an ephemeral, stateless, or immutable infrastructure. A database can be used but is used as a temporary store of data for that session. An architecture of this nature pulls from a known good source, often referred to as a “golden image." The idea of this system is to completely recreate the environment with each instance. The base image still needs updates, but this is done to a single image offline, then new systems copy these updates from the image as they are created. Terraform was designed with this type of system in mind, and fully addresses the ephemeral process. Many non-Mac systems can use this architecture as well, but it is the rule for most Mac applications.

Build Caching: ‍Unlike the traditional Linux and Windows systems, Apple builds can take a long time to perform. Being aware of this, several major companies have launched their own products to address this, and Apple is beginning to address this internally as well. Currently, contenders in this space are:

  • Bazel (by Google)
  • Please (by former Google staff)
  • Buck (by Facebook)
  • Pants (used by Twitter)
chart of tools for build caching

Share this article


Orka, Orka Workspace and Orka Pulse are trademarks of MacStadium, Inc. Apple, Mac, Mac mini, Mac Pro, Mac Studio, and macOS are trademarks of Apple Inc. The names and logos of third-party products and companies shown on the website are the property of their respective owners and may also be trademarked.

©2023 MacStadium, Inc. is a U.S. corporation headquartered at 3525 Piedmont Road, NE, Building 7, Suite 700, Atlanta, GA 30305. MacStadium, Ltd. is registered in Ireland, company no. 562354.