I'd also recommend contacting QT suggesting they file their own bug(s) and/or contact DTS to talk about options.> Yes, it is done. In the meantime, I have installed macOS 26 beta 6 and the icon is back!

Hi, Indeed, I do not see any call to NSApplicationMain just like you have: Thread 0 Crashed: 0 libsystem_kernel.dylib 0x19f8e85b0 __pthread_kill + 8 1 libsystem_pthread.dylib 0x19f922848 pthread_kill + 296 2 libsystem_c.dylib 0x19f828808 abort + 124 3 kDrive 0x1009954a4 KDC::AppServer::init()::$_1::operator()() const + 20 (appserver.cpp:404) 4 kDrive 0x100995450 QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, KDC::AppServer::init()::$_1>::call(KDC::AppServer::init()::$_1&, void**) + 44 (qobjectdefs_impl.h:146) 5 kDrive 0x1009953ec void QtPrivate::Functor<KDC::AppServer::init()::$_1, 0>::call<QtPrivate::List<>, void>(KDC::AppServer::init()::$_1&, void*, void**) + 36 (qobjectdefs_impl.h:256) 6 kDrive 0x100995388 QtPrivate::QFunctorSlotObject<KDC::AppServer::init()::$_1, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) + 168 (qobjectdefs_impl.h:420) 7 QtCore 0x10520b0d8 QtPrivate::QSlotObjectBase::call(QObject*, void**) + 20 (qobjectdefs_impl.h:375) [inlined] 8 QtCore 0x10520b0d8 QSingleShotTimer::timerEvent(QTimerEvent*) + 204 (qtimer.cpp:358) 9 QtCore 0x1051ef36c QObject::event(QEvent*) + 88 10 QtWidgets 0x103180740 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 272 (qapplication.cpp:3409) 11 QtWidgets 0x103181974 QApplication::notify(QObject*, QEvent*) + 532 12 QtCore 0x1051af7ac QCoreApplication::notifyInternal2(QObject*, QEvent*) + 208 (qcoreapplication.cpp:1067) 13 QtCore 0x10530bb04 QTimerInfoList::activateTimers() + 840 (qtimerinfo_unix.cpp:639) 14 libqcocoa.dylib 0x1037a4624 QCocoaEventDispatcherPrivate::processTimers() + 8 (qcocoaeventdispatcher.mm:131) [inlined] 15 libqcocoa.dylib 0x1037a4624 QCocoaEventDispatcherPrivate::activateTimersSourceCallback(void*) + 24 (qcocoaeventdispatcher.mm:125) 16 CoreFoundation 0x19f9c1ad8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 17 CoreFoundation 0x19f9c1a6c __CFRunLoopDoSource0 + 172 18 CoreFoundation 0x19f9c17d8 __CFRunLoopDoSources0 + 232 19 CoreFoundation 0x19f9c0468 __CFRunLoopRun + 820 20 CoreFoundation 0x19fa7e898 _CFRunLoopRunSpecificWithOptions + 532 21 HIToolbox 0x1ac38c714 RunCurrentEventLoopInMode + 316 22 HIToolbox 0x1ac38f99c ReceiveNextEventCommon + 464 23 HIToolbox 0x1ac5191c0 _BlockUntilNextEventMatchingListInMode + 48 24 AppKit 0x1a428a620 _DPSBlockUntilNextEventMatchingListInMode + 236 25 AppKit 0x1a3da6edc _DPSNextEvent + 588 26 AppKit 0x1a47eeb6c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 27 AppKit 0x1a47ee878 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72 28 AppKit 0x1a3d9f720 -[NSApplication run] + 368 29 libqcocoa.dylib 0x1037a4fb8 QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 1712 (qcocoaeventdispatcher.mm:430) 30 QtCore 0x1051b8b3c QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 36 (qeventloop.cpp:139) [inlined] 31 QtCore 0x1051b8b3c QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 500 (qeventloop.cpp:230) 32 QtCore 0x1051afe88 QCoreApplication::exec() + 128 (qcoreapplication.cpp:1382) 33 kDrive 0x1008e1f7c exec(std::__1::unique_ptr<KDC::AppServer, std::__1::default_delete<KDC::AppServer>>&) + 1996 (mainserver.cpp:193) 34 kDrive 0x1008e2134 main + 160 (mainserver.cpp:203) 35 dyld 0x19f565924 start + 6400 If switching to NSApplicationMain() resolves the issue and you’re able to make that transition, then please do so. We will not be able to make that transition on the short term, but that is definitively toward this solution that we want to move in the next few months.

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.

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

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.

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.

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?

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.

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?

Looks like this issue is visible only after using a third party software to uninstall the app. To remove the extension, I has to install a different version of the app (and extension). The blocking extension was correctly terminated and the new one was enabled. Then, deleting the app directly from the Application folders (without any third party software involved) worked perfectly and the extension was correctly terminated.

Hi, Looks like it is fixed on Monterey 12.3!!

Hi, It's done: FB9737187 (Third party app sidebar icons not following accent colour on macOS 12.0) Thank you for your feedback. Regards