# PR: macOS: \[bugfix\] Keep the main menu updating after a MenuBarModel change

**URL:** <https://forum.juce.com/t/pr-macos-bugfix-keep-the-main-menu-updating-after-a-menubarmodel-change/69488>\
**Category:** MacOSX and iOS\
**Created:** [September 11, 2026, 9:40pm UTC](https://forum.juce.com/t/pr-macos-bugfix-keep-the-main-menu-updating-after-a-menubarmodel-change/69488 "2026-09-11T21:40:12Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![emezeske](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/emezeske/32/15528_2.png) [@emezeske](https://forum.juce.com/u/emezeske)\
**Post date:** [September 11, 2026, 9:40pm UTC](https://forum.juce.com/t/pr-macos-bugfix-keep-the-main-menu-updating-after-a-menubarmodel-change/69488/1 "2026-09-11T21:40:12Z")

</div>

This is a straight-up reproducible bug on macos with a simple fix.

> <https://github.com/juce-framework/JUCE/pull/1745>
>
> On macOS, items in the native main menu bar stop reflecting their enabled state …after the first MenuBarModel::menuItemsChanged() call: opening a menu shows whatever state the commands had at that moment, and later changes are not picked up until the next call. Any app that uses setMacMainMenu() together with setApplicationCommandManagerToWatch() hits this as soon as keyboard focus moves, because ApplicationCommandManager calls commandStatusChanged() on every focus change and that ends in menuItemsChanged().
> 
> To reproduce, register a command whose getCommandInfo() enabled state depends on something that can change without moving keyboard focus, such as a selection made with a keyboard shortcut, and put it in a menu shown through setMacMainMenu() with setApplicationCommandManagerToWatch() in effect. Move focus once so the bar is rebuilt, then change that state and open the menu. The item still shows the old state, and keeps showing it until focus moves again.
> 
> The menus built when the bar is first populated get the JuceMenuCallbackClass delegate, whose menuNeedsUpdate: rebuilds the menu from the model each time it opens. The replacements that menuBarItemsChanged() creates through updateTopLevelMenu() were allocated without that delegate, so they were never refreshed on open. This change creates them through createMenu() with the delegate attached, as the initial menus are.
> 
> Tested on macOS 26 with a standalone app: reading the menu's items through Accessibility before and after a keyboard-driven selection change now shows the enabled states following the model, where before the change they stayed at the values from the last focus change.

---

_[View the full topic](https://forum.juce.com/t/pr-macos-bugfix-keep-the-main-menu-updating-after-a-menubarmodel-change/69488)._