macOS Release Cycle and Security Update Policy
The annual cadence
macOS releases follow iOS closely: previewed at WWDC in June, developer and public betas over the summer, and general availability in the autumn - usually somewhat later than iOS, often in October.
Since 2025 macOS has used year-based version numbers, aligning it with iOS, iPadOS, watchOS and tvOS on a single release generation number.
Point releases through the year deliver both fixes and features, and as with iOS, a capability announced in June may not arrive until a point release months later.
The unwritten support policy
Apple does not publish an end-of-life date for a macOS version. What can be observed is consistent:
| Version | Typical treatment |
|---|---|
| Current | Full security and feature updates |
| Previous | Security updates |
| Two versions back | Security updates, sometimes with a delay or narrower scope |
| Older | No further updates |
The practical implication is a rolling window of roughly three years. Security fixes for the two older versions have historically been less comprehensive than for the current one, with some fixes shipping only in the newest release. Organisations with strict patching requirements generally treat “current or previous” as the supported set rather than relying on the third.
Rapid Security Responses
Apple introduced Rapid Security Responses to ship urgent fixes without a full OS update. They install quickly, often without a full restart, and are identified with a letter suffix such as 26.1.1 (a).
They are intended for actively exploited issues and can be removed if they cause problems, which is unusual for Apple updates. For fleets, they are worth allowing through automatic updates even where full OS updates are managed on a slower schedule.
Xcode drives the upgrade schedule
For anyone building software, the constraint is usually not macOS itself but Xcode.
Each Xcode version requires a minimum macOS version, and each supports a specific range of SDKs and deployment targets. Because Apple periodically requires App Store submissions to be built against a recent SDK, the chain runs: App Store deadline, to required Xcode version, to required macOS version, to whether your build machines can run it.
This makes macOS upgrades on continuous integration infrastructure an annual dependency with a hard deadline attached, rather than something that can be deferred indefinitely.
Hardware support
Each major macOS release drops support for some older Macs. Since the transition to Apple silicon, the pattern has been that Intel Macs lose support earlier, and recent releases have narrowed Intel support considerably.
For a Mac that can no longer run the current version, the practical options are running the newest supported version until its security updates stop, or replacing the hardware. Community projects exist to install newer versions on unsupported Macs, but they are not a basis for production or managed environments.
Managing upgrades in an organisation
- Do not upgrade on release day. The first point release, usually within a month or two, resolves the early issues.
- Test build infrastructure separately from workstations. Toolchain breakage on CI is more disruptive than a desktop issue.
- Use managed software update controls. Declarative device management lets you defer major upgrades while still applying security updates, which is the combination most organisations want.
- Track the Xcode requirement, not the macOS release. That is the date that actually forces the move.
Conclusion
macOS ships annually in the autumn, with an observed security support window covering roughly the current release and the two before it. Apple publishes no formal end-of-life dates, so the safest planning assumption is current-or-previous. For development organisations the real driver is Xcode: its macOS requirement, tied to App Store SDK deadlines, is what sets the upgrade schedule for build machines.