This is a release candidate of Munki 7.
In Munki 7, the command-line tools and their helpers, previously written in Python and requiring a Python interpreter with PyObjC available, have all been rewritten in Swift and are compiled executables.
Please test and provide feedback. Use caution in installing this beta on production-critical machines.
Supported OSes
- The Munki 7 command-line tools are built with a deployment target of macOS 10.15. That means the code runs on 10.15+, but little testing has been done on OSes prior to macOS 14. Munki 7 drops support for macOS 10.13 and 10.14.
- Managed Software Center has been updated to adopt the new look for macOS 26 (when built using Xcode 26, and when running on macOS 26.) This new version has been tested on macOS 15 and the current macOS 26 beta. It runs as far back as macOS 10.15.
Build info
- This release was built with Xcode 26.0 Release Candidate on a beta of macOS 26 via a GitHub Actions workflow here: https://github.com/macadmins/munki-builds. It has been signed and notarized by MacAdmins Open Source.
- You can build this with Xcode 16, but the Managed Software Center application will not adopt all the new macOS 26-specific behavior/appearance.
- The distribution package now contains a new/additional component package:
com.googlecode.munki.libs
. On macOS 10.15 and macOS 11, this package installs a Swift runtime dynamic library needed for some of the Munki command-line tools. In a Munki pkginfo for this release, you should mark that receipt as optional. - Distribution package version: 7.0.0.5324
- Components:
- com.googlecode.munki.core 7.0.0.5324
- com.googlecode.munki.admin 7.0.0.5324
- com.googlecode.munki.app 7.0.0.5315
- com.googlecode.munki.app_usage 7.0.0.5324
- com.googlecode.munki.launchd 7.0.0.5320
- com.googlecode.munki.pythonlibs 6.7.0.5293
- com.googlecode.munki.libs 5.5
- Components:
Known issues
makecatalogs
is slower than the Python version. Some work has been done to speed it up, but it's still slower.- There has been a report of occasional crashing in
munkimport
. (See #1262)
Changes since RC1:
- Added AssociatedBundleIdentifiers to launchd plists; allows macOS to "group" these processes in System Settings->Login Items & Extensions. Thanks to @weswhet (#1268) (#1269)
- A fix for an issue with LocalOnlyManifests. Thanks to @mrowell (#1270)
- A fix for an issue with
makepkginfo
/munkiimport
where empty dicts for payload-free component packages were being included in the receipts array. Thanks to @jby (9941b0c)
New features in Munki 7:
- Managed Software Center now supports customization of the sidebar. See https://github.com/munki/munki/wiki/Customizing-Managed-Software-Center-sidebar for details. Thanks to @SteveKueng for the initial implementation.
version_script
: pkginfo items may now contain the keyversion_script
. The expected value for this key is a string, containing a script that outputs the version number of a currently-installed version of the software, or an empty string (or exits non-zero) if the software is not currently installed. This is a new mechanism Munki can use to determine whether or not an item needs to be installed (or updated). Since it returns a version number, and Munki can use its existing version number logic, in most cases using aversion_script
will be superior to using aninstallcheck_script
.- During bootstrapping, if on A/C power or battery level is greater than 50% on Intel or greater than 30% on Apple silicon, the status app will prevent the display from going to sleep so that bootstrap progress is displayed. Thanks to @chrisgrande. (See #1215)
Munki 7 removed features:
Some features and capabilities supported by previous versions of Munki are no longer supported:
-
The
startosinstall
installer_type, used to install macOS major upgrades on Intel Macs is no longer supported. Thestage_os_installer
installer_type works on both Intel and Apple silicon, and is supported in Munki 7. -
Installation of Apple software updates. Munki 6 does not install Apple updates on Apple silicon, but instead prompts the user to use Apple tools (System Settings app; softwareupdate) to do so. Munki 7 extends this behavior to Intel Macs as well.
-
Apple update metadata (https://github.com/munki/munki/wiki/Pkginfo-For-Apple-Software-Updates) The installer_type
apple_update_metadata
is no longer supported. -
The following Adobe installer_types are no longer supported:
- AdobeSetup
- AdobeUberInstaller
- AdobeAcrobatUpdater
- AdobeCS5AAMEEPackage
- AdobeCS5PatchInstaller
- AdobeCCPInstaller
-
Additionally, the following uninstall_methods are no longer supported:
- AdobeSetup
- AdobeUberUninstaller
- AdobeCS5AAMEEPackage
- AdobeCCPUninstaller
-
To use Munki 7 to install Adobe software, use the Adobe admin console to create Apple installer packages (that Munki can install via its support for Apple installer packages).
-
The installer_type
profile
is no longer supported. Munki 7 has no support for the installation or removal of configuration profiles, and additionally, support for configuration profile "emulation" has been removed as well. Admins should be using an MDM solution to manage configuration profiles on macOS. -
The
appdmg
installer_type is no longer supported (this has been deprecated for well over a decade): https://github.com/munki/munki/wiki/App-Dmg-Package-Notes -
The
suppress_bundle_relocation
pkginfo key is no longer supported. This only ever worked for bundle-style packages.
Middleware:
- Python middleware compatible with Munki 6 will not work with Munki 7. Several popular middleware modules have been ported to Swift using Munki 7's middleware protocol, and are believed to work:
- Though these ported middleware modules are believed to work, they are not officially supported at this time. My preference would be for others who actually use the modules to take over development, support, and maintenance.
Repo plugins:
- Python repo plugins compatible with Munki 6 will not work with Munki 7. A Swift repo plugin protocol is available, and the MWA2APIRepo plugin was ported to Swift, largely as a proof-of-concept so that vendors who have incorporated Munki into their products and have written repo plugins have example code to follow.
Other notes:
-
The installer package for this beta release contains a component package that installs the Python libraries used by Munki 6.7 (aka "munkilib"). This is intended as a transition aid. (We use Sal where I work and some of the Sal reporting scripts import code from inside munkilib). The intention would be for Munki admins to identify these sorts of dependencies and work to eliminate them.
-
Installing the beta package over an existing Munki 6.x install will leave the munki-python symlink and Munki's Python.framework in place. This might be helpful while transitioning, but might also make it easier to miss dependencies on that Python. You might consider removing Munki 6's included Python to see what breaks.