With macOS Tahoe already more than half way through its cycle, and Apple’s WWDC announced, now is a good time to plan your Mac’s calendar. This article peeks at what lies ahead for macOS over the next six months.

Since the pandemic disruption settled, minor version updates to macOS have become more regular. Looking across Sonoma, Sequoia and Tahoe, greatest variation in their timing has been in their x.3 and x.4 releases, that have varied between 22 Jan – 11 Feb, and 7 – 31 March, respectively. x.5 to x.7 have been more consistent, as they’re more tightly constrained by events including WWDC, the subsequent new beta season, and for some maybe even a vacation.

Those are summarised in the chart above, together with my predictions for the dates we should expect the remaining minor versions of Tahoe. Those should bring its cycle to look like:

• 26.0 – 15 September 2025
• 26.1 – 3 November 2025
• 26.2 – 12 December 2025
• 26.3 – 11 February 2026
• 26.4 – 24 March 2026
• 26.5 – 11 May 2026
• 26.6 – 27 July 2026
• 26.7 – 14 September 2026.

Where my forecasts are given in italics. Patch releases, such as 26.3.1, and BSIs occur outside that schedule. While we’re on the topic of BSIs, all indications are that Apple only intends to provide them for the current release of macOS, as it did with RSRs, which means that those Macs staying with Tahoe from 26.7 will no longer get them. It’s unclear how significant a loss that might prove.

WWDC this year is being held between 8-12 June, and will almost certainly bring the first developer beta release of macOS 27.0 (and all Apple’s other OSes). That’s likely to be made available to public beta-testers in early July. This is particularly significant this year, as it will be the first version of macOS to run exclusively on Apple silicon Macs.

For those with Intel Macs, or intending to remain with older versions of macOS, likely dates of release for scheduled security updates to Sonoma and Sequoia are:

• 15.7.6, 14.8.6 – 11 May 2026
• 15.7.7, 14.8.7 – 27 July 2026
• 15.7.8, 14.8.8 – 25 August 2026
• 15.8 – 14 September 2026.

The date at the end of August is possible, but less likely than the previous two. So far this year, security updates for Sonoma and Sequoia have been keeping reasonably close to those for Tahoe, in terms of vulnerabilities addressed, so the security gap between them has been rather less than in previous cycles.

However, the important message here is that it’s unlikely that Sonoma will receive any further security updates after the end of August this year. If your Mac is capable of being upgraded to Sequoia, now is the time to plan that, or it’ll all too quickly be September and your macOS will have lost its last support.

Similarly, if you’ve been holding back from upgrading to Tahoe in the hope that it will undergo interface improvements, I’m afraid that’s now looking increasingly unlikely. If it’s an Intel Mac capable of running Tahoe, there’s little point in avoiding making that decision any longer. There’s only limited time and scope left for improvement in macOS 26, with most engineers now more focussed on getting macOS 27 ready for WWDC.

Key forecasts

• 26.5, 15.7.6, 14.8.6 – 11 May 2026
• 27.0 developer beta – 8 June 2026
• 27.0 public beta – 8 July 2026
• 26.6, 15.7.7, 14.8.7 – 27 July 2026
• 27.0, 26.7, 15.8 – 14 September 2026.

Apple has released the update to bring macOS Tahoe to version 26.4, and security updates for Sequoia and Sonoma to bring them to 15.7.5 and 14.8.5.

Download size for the 26.4 update on Apple silicon Mac is very large, at around 7.15 GB, but only about 4.14 GB on Intel Macs.

Release notes for 26.4 include:

• support for new AirPods Max 2
• compact tabs as an option in Safari
• Freeform joins Creator Studio, with advanced tools and a premium content library
• Purchase Sharing in Family Sharing

and eight new emoji.

Security release notes for 26.4 list over 70 fixes, those for Sequoia 15.7.5 list about 56, and those for Sonoma 14.8.5 list about 50. None are reported as being known to be exploited in the wild at present.

Enterprise release notes for 26.4 are here.

Firmware in Apple silicon Macs is updated to a new mBoot firmware version numbering system, with the current version given as 18000.101.7. The macOS build number is 25E246, and Safari is version 26.4 (21624.1.16.11.4). Firmware in Intel Macs with T2 chips is updated from 2094.80.5.0.0 (iBridge 23.16.13120.0.0,0) to 2103.100.6.0.0 (iBridge 23.16.14242.0.0,0).

If you’re running SilentKnight older than version 2.14 (71), then it’s likely that it will crash as a result of the change in firmware version. Please use version 2.14 from here.

I’ll be posting an analysis of what has changed later today.

Updated 09:15 25 March 2026 with firmware details for Intel Macs.

After reading today’s article here about fixing software update problems and the softwareupdate command tool, two eagle-eyed readers, Gurt and upstreamer, insisted that they were being offered two full installers for macOS Sequoia 15.7.5. Although for one of them this might have occurred because of previous membership in a beta-testing programme, that didn’t explain them both. I therefore checked again this evening, and was surprised to see the list of available updates does now offer two apparently identical full installers for macOS Sequoia 15.7.5 Build 24G617.

To find these yourself, simply enter the following in Terminal:
softwareupdate --list-full-installers

If you fancy downloading either of them, use the command
sudo softwareupdate --fetch-full-installer --full-installer-version 15.7.5

That should download the Installer app into your Applications folder.

Software Update doesn’t offer 15.7.5 as an update for Sequoia 15.7.4. There’s no mention of the release of 15.7.5 anywhere else, in particular Apple’s security release notes page, and I can’t see anyone else mentioning this as a newly released update. Has it been released prematurely by accident, perhaps? Or has someone forgotten to finish a job off?

Postscript

Apple has now rectified what had been an inadvertent public release of a release candidate for 15.7.5. Hopefully the next time it appears, it will be the final release.

Apple has released updates to macOS, to bring Tahoe to version 26.3, and security updates for Sequoia to version 15.7.4, and Sonoma to 14.8.4.

The Tahoe update downloads in around 3.7 GB for an Apple silicon Mac, and 2.5 GB for an Intel Mac.

Apple seems to have forgotten what 26.3 fixes or improves, writing just “this update provides important bug fixes and security updates”.

Security release notes for Tahoe 26.3 are here, and list around 52 vulnerabilities addressed, including one that has been previously used in an attack on iOS. Sequoia 15.7.4 has about 30 fixes listed here, and Sonoma 14.8.4 has about 36 listed here.

The build number of 26.3 is 25D125, and iBoot firmware is updated to version 13822.81.10. Safari is version 26.3 (21623.2.7.11.6).

I’ll update this post with further information as I get it. and will later provide details of significant changes in version numbers.

Last updated at 1935 GMT 11 February 2026.

Sometimes apparently simple things are truly simple, but more often than not they need us to turn detective to delve deeper. This has proved the case with local network privacy protection, introduced well over a year ago in macOS Sequoia, and largely glossed over since. As I was compiling my brief summary of what I had been able to discover about it, I had a feeling there was more to come, and there is.

Cast your mind back just over a year to the first couple of release versions of macOS Sequoia. Do you recall all the problems reported with its software firewall and networking? At the time I wrote of 15.0 “There have been widespread reports of problems with networking, many attributable to the software firewall. Products across a wide range of vendors are affected, and many simply can’t function properly in Sequoia.”

Most of those were addressed in 15.1, but their cause was never made clear unless you read Apple’s TN3179 carefully, where it’s mentioned in passing that “macOS 15.1 fixed a number of local network privacy bugs”. It’s no coincidence that macOS 15.0 was the first public release to feature that local network privacy protection.

Another clue came in the statement in that note that “on macOS there’s no way to reset your program’s Local Network privilege to the undetermined state”. This contrasts with pretty well every other category of privacy protection, which are handled by the dreaded TCC, Transparency Consent and Control. The major exception to those comes in Location Services, which are handled and implemented separately.

At this point I could hear the log calling me to take a look at what happens when a new app first requests access to the local network. Thanks to those of you who suggested candidates for this, I chose VideoLAN’s VLC running in a macOS 26.2 VM with bridged networking and a LAN available. I first drew a blank for TCC, as I had expected, which clearly knows nothing about local network privacy. Instead, it was the Network Extension framework that did all the work.

Once VLC had cleared Gatekeeper’s checks, it tried to query the local network, resulting in the standard request for consent.

This in itself is revealing, as it doesn’t appear to be constructed using a prompt string supplied in VLC, neither does it include VLC’s icon. It turns out that was all handled by the Network Extension framework:
06.249975 com.apple.networkextension Showing local network alert for org.videolan.vlc even though not in the foreground
06.249982 com.apple.networkextension Local network preference not yet set, prompting for VLC (org.videolan.vlc)
06.252939 com.apple.networkextension LocalNetwork icon configuration: notification dictionary option {
AlertHeader = "Allow \U201cVLC\U201d to find devices on local networks?";
AlertMessage = "This will allow the app to discover, connect to and collect data from devices on your networks.";
AlternateButtonTitle = "Don\U2019t Allow";
DefaultButtonTitle = Allow;
IconURL = "file:///System/Library/Frameworks/NetworkExtension.framework/Resources/LocalNetworkPrivacy.png";
SBUserNotificationDefaultButtonTag = 32; }

Less than four seconds later, I had clicked on the Allow button, and VLC got the green light:
10.015043 com.apple.mdns Local network alert policy status 'granted' for (org.videolan.vlc).

This added a new entry to the network privacy configuration:
10.023955 com.apple.networkextension NESMPathControllerSession[com.apple.preferences.networkprivacy-04DDB2F9-2C12-49BC-A4DE-B4CE6341E2B0:0C6F88E8-8AB2-4307-88AE-17E072232031]: handling configuration changed: {
name = <73-char-str>
identifier = 0C6F88E8-8AB2-4307-88AE-17E072232031
grade = 2
pathController = {
enabled = YES
pathRules = ( {
matchSigningIdentifier = PathRuleDefaultNonSystemIdentifier
matchDesignatedRequirement =
allowEmptyDesignatedRequirement = YES
noDivertDNS = NO
cellularBehavior = 0
denyCellularFallback = NO
denyMulticast = YES
multicastPreferenceSet = NO
isIdentifierExternal = NO
wifiBehavior = 0
denyAll = NO },
[other apps omitted]
{
matchSigningIdentifier = org.videolan.vlc
allowEmptyDesignatedRequirement = YES
noDivertDNS = NO
cellularBehavior = 0
denyCellularFallback = NO
denyMulticast = NO
multicastPreferenceSet = YES
isIdentifierExternal = NO
wifiBehavior = 0
denyAll = NO }, )
cellularFallbackFlags = 0
ignoreRouteRules = YES
ignoreFallback = YES } }
10.027741 com.apple.networkextension UUID: Found for org.videolan.vlc: ("07F0D29A-6013-3F29-81DC-15EAAB1C50D4")

The apps listed there extend well beyond those in the Local Network section of Privacy & Security settings, and it appears to include apps that don’t even attempt to make any network connection. It’s a useful list, though, that could be valuable if you’re trying to investigate a problem with local network connections. To elicit it, change its configuration and look for log entries from the com.apple.networkextension subsystem containing the word NESMPathControllerSession in the message field.

Knowing what the Network Extension framework can do, this makes it clear that local network privacy is implemented as a packet filter following those pathRules, which matches the statement in TN3179, that “the system implements these TCP and UDP checks deep in the networking stack, and thus they apply to all networking APIs.”

Summary

• Local network privacy isn’t implemented through TCC, but as a packet filter in the Network Extension framework.
• Prompts to allow access to local network features can be made without the app providing an information string.
• A user’s Network Extension configuration contains path rules for apps that aren’t listed in the Local Network section of Privacy & Security settings.
• The subsystem com.apple.networkextension may write its configuration to the log when it’s changed.
• An app’s path rules are applied across all networking APIs.

Further reading

How local network privacy could affect you
Apple TN3179
Network Extension framework

Of all the privacy protections in macOS, those for local networking are among the most recent and the least understood. Introduced in macOS Sequoia, they’re related to protection introduced earlier in iOS and iPadOS version 14, but different, and could trip you up when you’re least expecting yet another privacy prompt.

Fundamental rule

Any process running on your Mac that tries to make a connection to a local network address, to send or receive network packets without being forwarded by a router, requires privilege to do so. Without that privilege being allowed, the system will block it.

That sounds draconian, but most common uses are subject to exemptions, as a result of which the Local Network section in Privacy & Security settings remains empty.

All non-exempted apps and other processes start without any privilege. Those that try to make a local network connection result in the user being prompted to allow or deny their access. Your decision is then recorded in that app’s new entry in the Local Network section, and you can then set that to allow or deny its future access. For that to happen, the responsible app needs an additional item in its property list to explain to you why it requires that access, something that should appear in any prompt for access.

As with other privacy controls in macOS, this is applied for each individual user.

Major exceptions

In macOS, the following are automatically given local network access and don’t appear in Local Network settings:

• any daemon (except agents) started by launchd
• any process running as root
• command tools run from Terminal or using SSH, including their child processes; however, there are reports that closing Terminal while child processes are still running can lose their exemption, and cause their local connection to be broken
• traffic from Safari and WebKit (WKWebView)
• access to a local DNS server or network proxy
• high-level services using Bonjour internally, including AirPlay, printing, device discovery and accessory setup.

Those exempt the majority of processes regular users are likely to run.

Listening for and accepting incoming TCP connections doesn’t require any privilege, nor does receiving an incoming UDP unicast. Resolving a local DNS name, ending in .local, does require privilege, though, as do all Bonjour operations other than those exempted above.

Known problems

A process with a short life that immediately fails if it can’t complete a local network operation may not trigger a user prompt, and can continue to fail repeatedly as it can’t be granted the privilege. Apple recommends changing the code so that it doesn’t exit immediately after failure, to allow the prompt to be displayed and access granted.

There’s currently no way to reset an app’s Local Network setting.

Prompts to grant the privilege of local network access can appear out of the blue when an app accesses certain third-party libraries. It can be hard to trace the origins of those, but if you can work out which app is most probably responsible, you can report this to its developer.

Local network privacy, like other similar protection, relies on tracking apps by their code signature, so works best with code signed with certificates issued by Apple, rather than ad hoc signatures. It also relies on the UUID of the main executable code; in some cases that may be absent, or shared with other code, and can then behave unpredictably. These should be raised with the app developer.

Key points

macOS Sequoia and Tahoe apply restrictions to local network connections. Although few are likely to encounter them, don’t be surprised to be prompted to allow or deny a local network connection. Control those in the Local Network section in Privacy & Security settings as necessary.

Further details

Apple developer TN3179

I’m grateful to Peter for prompting this article, and for additional information about child processes and Terminal.