MONGOCRYPT-340 added support for Apple's M1 processor. Currently we ship two dylibs for MacOS - one for x64 (aka Intel) and one for ARM64 (aka M1). It would be preferable to ship a single Universal Binary, which contains both the x64 and ARM64 code in a single dylib. Darwin's loader will then choose the appropriate CPU architecture when loading the dylib.

What is the advantage of shipping CSFLE as a universal binary compared to shipping two CPU-specific dylibs? The work required to consume CSFLE on MacOS is significantly reduced. Our drivers (or shims) currently detect whether they are running on MacOS and load the dylib already. Now all drivers/shims must be updated to not only detect MacOS, but also x64 or ARM64, and then load the correct dylib. With a universal binary, drivers/shims load the dylib as they always have and Darwin's loader sorts out whether to run the x64 or ARM64 code. In theory, each driver will only need to be tested with the CSFLE universal binary, but won't need additional code changes.

Universal Binaries can be created for apps, extensions, dylibs, etc. To build a Universal Binary, additional compiler options can be provided to compile for multiple architectures or separate architecture-specific builds can be combined using the lipo tool. Universal Binaries supporting both x64 and ARM64 can be created on both Intel and M1 Macs, but the ARM64 slice can only be debugged on a M1 Mac. For more information, see Building a Universal macOS Binary in Apple's documentation.

NOTE: Drivers may have other unmanaged dependencies that will have to be recompiled as universal binaries to enable full M1 support. For example, the .NET/C# driver uses unmanaged libraries for Snappy and zstd, which would need to be updated. Supporting CSFLE as a Universal Binary is only one step.