macOS26: MenuBarExtra item not showing

How is your app launched?

What API are you using to run your status item? AppKit? Or SwiftUI?

macOS 26 beta has a new requirement that programs running in the background must be visible to the user somehow. Normally a status menu item would be sufficient to meet that requirement, but it’s possible that something is going wrong in your case.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

Thanks for the answer.

Our app is run from a subfolder of the /Application folder. In debug mode, I run it from CLion. Both methods used to work well and showed the icon in the status bar up to macOS 15.

What API are you using to run your status item? AppKit? Or SwiftUI?

We use the QSystemTrayIcon from Qt framework. But I also tried directly using NSStatusBar from AppKit with same result (app is running, but no icon is showing in the status bar).

I have also created some "dummy" apps, one using Qt in c++, the other directly using NSStatusBar from AppKit in swift. In both cases, the app icon is showing correctly in the status bar.

Are there any mandatory properties that must appear (that should not appear) in the Info.plist file?

Actually, our app bundle "myApp.app" contains 2 executables, "myApp" and "myApp_client". "myApp_client" is the one responsible for the tray icon, which is not showing. However, if I create a tray icon from the "myApp" executable, it is correctly showing in the StatusBar.

Are there any restrictions on executable names in relation to the application bundle?

Thanks again for your help.

Thanks for contributing to Samsung Developer Forums!

Remember, we’re all real people. Please be kind to your fellow community members.

myApp_client is the one responsible for the tray icon, which is not showing.

Ah, interesting. That separate process is clearly a factor here, and that doesn’t surprise me.

As to the best way to fix this, that kinda depends on the relative lifecycle of these two processes. Usually that falls into a few categories:

• The helper is more-or-less tied to the main app, that is, it starts when the main app start and stops when the main app stops.
• The helper runs after the main app has quit, usually to complete some long-running work.
• The helper runs all the time, that is, it starts at login and remains running during the login session.

Does your app fall into one of these?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The helper is more-or-less tied to the main app, that is, it starts when the main app start and stops when the main app stops.

Yes, we are in this first case. More specifically, the main app starts the helper during its own startup phase. Then, the 2 processes communicate through a socket. The helper is responsible for everything UI related. When the user wants to quit the app, the helper first sends a request to the main process asking it to quit, then quit.

I have seen other apps that embed a helper as a full bundle stored in the /Resources, not just an executable stored in /MacOS like we do. And in that case, it is the name of the helper bundle that is showing in "Menu Bar > Allow in the Menu Bar", not the name of the main bundle.

What do you think is the best way to embed a helper into our main bundle?

The helper is responsible for everything UI related.

Hmmm.

So:

• You have two executables, the main app and the helper.
• The user double clicks the main app.
• It launches the helper as a child process.
• The main app has no UI — no menu bar, no Dock icon, and so on — because you’ve set LSUIElement on it.
• The helper has no UI because it’s not an app, it’s just a standalone executable.
• Except that the helper displays a status item in the menu bar.
• Except that doesn’t work on macOS 26 beta.

Is that right?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The helper has no UI because it’s not an app, it’s just a standalone executable.

The helper has a UI, allowing to set the app parameters and show the activities, but the only way to access it for the user is through the menu bar icon. We can pop up the main window through a terminal command, and the UI is ok as well on macOS 26.

For the other statements, yes, it is correct.

OK, so that’s weird. In general, Mac users don’t expect apps to just disappear when they launch them. They expect the app to start with a menu bar, dock icon, and so on. Is there some special reason you structured it this way?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The app is only doing some background tasks. Once everything is set up, the user usually do not have to check the UI.

Is there some special reason you structured it this way?

Not especially, it is more a legacy thing. Originally, everything was in 1 executable, but it was then split into 2 to improve responsiveness of the UI. So the main process in more the "engine" process while the helper process manage the UI.

We have a big overhaul planned where we will probably stop using Qt and use AppKit instead for the macOS part. We should revise the structure while doing it. If you have any tips or guidelines, I'll gladly take them :)

And, in the meantime, as a workaround, I will move the management of the menu bar icon into the main process.

If you have any tips or guidelines, I'll gladly take them :)

And I’m happy to offer them (-:

Mac users expect apps to act like apps. If you double click an app, it should present a UI. But they also understand app lifetimes. If the user starts a long-running task in the app, they expect the task to be tied to the lifetime of the app. So, if they quit the app, it wouldn’t come as a surprise for if that cancels the task. Most apps like this will present a ‘Are you sure you want to quit?’ alert in this case, just to be sure.

If you want to separate the code into two separate processes, that’s fine. I see two common reasons for this:

• Security — You want to restrict or extend what resources this code has access to.
• Reliability — You don’t want a crash in this code to take out your entire app.

There are two common ways to do this:

• Put the code in an XPC service.
• Or a helper process.
• Or a helper app.

App-scoped XPC services have their lifetime tied to the client app, so you’d still need the ‘Are you sure you want to quit?’ alert.

For helper processes, there was traditionally no connection between their lifetime and that of the parent app. However, macOS 26 beta changes that story. The helper process has to display some sort of UI after the app quits. If you don’t, you can run into the “[App] is running in the background after it was closed” alert. That’s not fatal, but it’s annoying and definitely something you want to avoid if you can.

Note A status item should work for this. Which brings us back to your original issue. I’m not sure why that’s failing in your current setup. Normally I’d offer to dig into that, but your setup is weird enough that I don’t think that’s warranted. Rather, your short-term workaround should be fine and we can focus on fixing it in the long term.

A helper app is a special case of a helper process. The difference is:

• The app is in an app-like wrapper, which makes it easier to set the bundle ID, include resources, and so on.
• The app can be started by NSWorkspace rather than launched as a child process.

The first point makes it easier for the app to display a status item. I’m pretty sure that’ll work just fine; there are lots of third-party apps that work this way.

Finally, if you want the lifetime of this other process to be completely separated from the lifetime of your app, you can use use SMAppService to register it as a login item or launchd agent. These get started when the user logs in. This is a common setup for programs that want to lurk in the background providing functionality to the user. For example, the macro product I use on my main work Mac works this way.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Awesome, thank you so much for your help and precious advice. We will adapt our structure to match one of these cases.

Quinn mentioned this thread to me, so I could jump in…

Hi, In macOS 26 beta, our app icon is not showing anymore in the Menu Bar. It is also not displayed in the new section "Menu Bar > Allow in the Menu Bar", which seems to be the way to show/hide Menu Bar icons in macOS 26.

The icon is correctly displayed and working in macOS 15. Our app is signed and notarized. It also has the "LSUIElement" value set to "true" in the Info.plist file.

Is there some new mandatory entitlements to add in order to have our app showing in the "Allow in the Menu Bar" section?

I happened to be looking into an issue similar to this for another developer, and I have some information that may be helpful. Two things to be aware of:

1. The engineering team is aware that this is happening and is making some changes (r.155484172) to address those issues, at which point it's possible this will start working for you.

2. The underlying issue here seems to be that the system is unable to map certain processes back to bundle IDs. WHY that is failing is unclear, and the fix for #1 is going to rely on alternative tracking data (probably executable path) to bypass the issue without attempting to determine or resolve the underlying cause*.

*This might seem like an odd choice, but the issue here is that the range of process configurations that run on macOS is so large and complicated that focusing too much on underlying causes can be counterproductive, as you can end up endlessly chasing edge cases.

My concern here is that #2 can have wide and expected consequences, both now and in the future. So, a few different suggestions and comments here:

• I would strongly recommend investigating this issue "now" while the status bar issue is still present. The workarounds like #1 are very common throughout the system, which can make it hard to notice something "wrong". This is a good opportunity to use "our bug" to preemptively prevent future problems.

• I haven't confirmed this, but I suspect the primary cause here is bypassing/replacing NSApplicationMain. While this has long been technically possible, it's never really been recommended and it's only become more problematic over time. If switching to NSApplicationMain() resolves the issue and you’re able to make that transition, then please do so.

• If you ARE using NSApplicationMain() and are still seeing this issue, then please let me know, as that's an edge case worth investigating further.

• If you're using a 3rd party framework that bypasses NSApplicationMain(), then I'd recommend contacting them so that they can follow up with us about workarounds and alternatives.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi Kevin, Thanks a lot for jumping in.

The engineering team is aware that this is happening and is making some changes (r.155484172) to address those issues, at which point it's possible this will start working for you.

Great, I'll let you know if the icon is showing again with our current app version.

If you're using a 3rd party framework that bypasses NSApplicationMain(), then I'd recommend contacting them so that they can follow up with us about workarounds and alternatives.

We are using the Qt framework indeed. Do they bypass NSApplicationMain? I think so but I'm not sure. I have posted on their forum to confirm this and I let you know.

Anyway, this issue definitively pointed out some weak points in our design that we will fix in a near future. Primarily, we will move away from Qt and build our app "more natively" using AppKit.

We are using the Qt framework indeed. Do they bypass NSApplicationMain? I think so, but I'm not sure. I have posted on their forum to confirm this, and I’ll let you know.

I believe so; however, the easiest way to check this for yourself is to add an "abort()" call at some point after your app is "done" launching. Then, just look at the crash log to see what's there. This is what that looks like for a "basic" AppKit app:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	       0x18e8a3388 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x18e8dc8cc pthread_kill + 296
2   libsystem_c.dylib             	       0x18e7e5c60 abort + 124
3   NSApplication_EventMonitor    	       0x104814cd8 -[AppDelegate applicationDidFinishLaunching:] + 44 (AppDelegate.m:19)
4   CoreFoundation                	       0x18e9bd62c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148
5   CoreFoundation                	       0x18ea4cce8 ___CFXRegistrationPost_block_invoke + 92
6   CoreFoundation                	       0x18ea4cc2c _CFXRegistrationPost + 436
7   CoreFoundation                	       0x18e98ca78 _CFXNotificationPost + 740
8   Foundation                    	       0x18ff48680 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88
9   AppKit                        	       0x1928f623c -[NSApplication _postDidFinishNotification] + 284
10  AppKit                        	       0x1928f5fec -[NSApplication _sendFinishLaunchingNotification] + 172
11  AppKit                        	       0x1928f45e8 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 488
12  AppKit                        	       0x1928f41fc -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 488
13  Foundation                    	       0x18ff70e40 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 316
14  Foundation                    	       0x18ff70c38 _NSAppleEventManagerGenericHandler + 80
15  AE                            	       0x1963c513c 0x1963ba000 + 45372
16  AE                            	       0x1963c4a7c 0x1963ba000 + 43644
17  AE                            	       0x1963be044 aeProcessAppleEvent + 484
18  HIToolbox                     	       0x19a3b0828 AEProcessAppleEvent + 68
19  AppKit                        	       0x1928eddb8 _DPSNextEvent + 1456
20  AppKit                        	       0x19328c630 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
21  AppKit                        	       0x1928e0c64 -[NSApplication run] + 480
22  AppKit                        	       0x1928b735c NSApplicationMain + 880
23  NSApplication_EventMonitor    	       0x104814ca0 main + 44 (main.m:14)
24  dyld                          	       0x18e53aea8 start + 6860

The details above 19/20 will vary depending on exactly what the app is doing when it crashes, but everything below that point is basically common to any "standard" AppKit apps.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware