Multiple instances/menubar icons

[mhamann]

Describe the bug Over time, I seem to have accumulated multiple Alt-tab instances. I'm not sure where these all came from--I didn't do anything to launch them as far as I know. As seen below, multiple menubar icons are present as are multiple entries in Activity Monitor.

I'm not sure how to reproduce this, but I think it occurred within the last 24 hours. My machine's current uptime is roughly 7 days. I believe I've seen this before, but it's not consistent.

All of the running processes have a parent of launchd.

I apologize that this isn't a more helpful bug report.

I'm using version 6.46.0.

Screenshots / video

Steps to reproduce the bug

1. Use Alt-tab as normal
2. Unknown...

[lwouis]

If you double-click on AltTab multiple time, you will notice that it doesn't open multiple instances. Instead, it opens the Preferences window of the already-opened instance.

This leads me to think that you have multiple different versions of AltTab installed on your system. Because you said "Over time, I seem to have accumulated", I'm also guessing that it may be because you use homebrew to install/update AltTab? I could imagine homebrew installs the various versions in various locations on your disk, and if all have the "Launch at login" checkbox checked, then they all separately launch at login (macOS launchd is launching them, technically).

Did you use homebrew to install AltTab? If not, how do you update AltTab? Using the auto-update built into the app, or downloading new versions manually on the website maybe?

[mhamann]

I don't have AltTab installed via Homebrew and I can only find one copy of AltTab.app in Applications. I use the built-in updater to install updates.

$ brew info alt-tab
alt-tab: 6.46.1 (auto_updates)
https://github.com/lwouis/alt-tab-macos
Not installed
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/alt-tab.rb
==> Name
AltTab
==> Description
Enable Windows-like alt-tab
==> Artifacts
AltTab.app (App)
==> Analytics
install: 3,759 (30 days), 13,477 (90 days), 36,510 (365 days)

[lwouis]

@mhamann could you please run and share the results of this command?

ps auxwwwe | grep AltTab

It should tell us where the apps are launched from.

[mhamann]

I terminated all of the instances and restarted the process to get things working again, but when it occurs again I'll capture this additional info!

[lwouis]

I'm not going to release an update soon. So I'm afraid this issue may rot. What I can suggest is that you download an older version of AltTab here, you replace your current one with it. Then you open it and trigger the self-update.

That's kind of artificially getting an auto-update to happen. It may trigger the issue, then you can inspect as we discussed above.

[darthwalsh]

@mhamann could you please run and share the results of this command?

ps auxwwwe | grep AltTab

It should tell us where the apps are launched from.

@lwouis Not OP, but I've had the issue of having two AltTab instances a few times. Just now, after OS update, now I'm seeing:

ps auxwwwe | grep AltTab
walshca           1683   0.0  0.3 36616556  85136   ??  S    12:45PM   0:08.87 /Applications/AltTab.app/Contents/MacOS/AltTab USER=walshca SECURITYSESSIONID=186a7 COMMAND_MODE=unix2003 __CFBundleIdentifier=com.lwouis.alt-tab-macos PATH=/usr/bin:/bin:/usr/sbin:/sbin HOME=/Users/walshca SHELL=/usr/local/bin/pwsh LaunchInstanceID=02DACD4F-D096-48BA-8F4F-9F78DF04965E __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 XPC_SERVICE_NAME=application.com.lwouis.alt-tab-macos.99453784.99453790 SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.Vsytr3rwMd/Listeners XPC_FLAGS=1 LOGNAME=walshca TMPDIR=/var/folders/qq/x85h5m0x4l9f33041hpnvq680000gn/T/
walshca           1639   0.0  0.2 36611644  76552   ??  S    12:45PM   0:07.88 /Applications/AltTab.app/Contents/MacOS/AltTab XPC_SERVICE_NAME=com.lwouis.alt-tab-macos SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.Vsytr3rwMd/Listeners PATH=/usr/bin:/bin:/usr/sbin:/sbin XPC_FLAGS=1 LOGNAME=walshca USER=walshca HOME=/Users/walshca SHELL=/usr/local/bin/pwsh TMPDIR=/var/folders/qq/x85h5m0x4l9f33041hpnvq680000gn/T/
walshca           8623   0.0  0.0 34271308   1012 s008  S+    1:51PM   0:00.01 /usr/bin/grep AltTab

The CLI args are very different, but one thing suspicious to me is XPC_SERVICE_NAME is com.lwouis.alt-tab-macos vs application.com.lwouis.alt-tab-macos.99453784.99453790. Could different AltTab versions have set up a different launchd?

~ launchctl print gui/501/com.lwouis.alt-tab-macos | grep path                              
        path = /Users/walshca/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist

~ launchctl print gui/501/application.com.lwouis.alt-tab-macos.99453784.99453790
gui/501/application.com.lwouis.alt-tab-macos.99453784.99453790 = {
        active count = 4
        path = (submitted by runningboardd.269)
        state = running
        bundle id = com.lwouis.alt-tab-macos

        program = /Applications/AltTab.app/Contents/MacOS/AltTab
...

I'm out of my depth for what runningboardd is...

[lwouis]

@darthwalsh that's quite interesting and confusing as well. I googled runningboardd and it seems to be internal to Apple, thus undocumented.

Could you please share these info?

• Your AltTab version. If you upgraded recently, how did you upgrade and from which version to which version
• The contents of /Users/walshca/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist

Thank you

[darthwalsh]

@lwouis I was on AltTab 6.46.1. I saw there was an update though, so I updated to 6.47.0 just now.

com.lwouis.alt-tab-macos.plist is:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.lwouis.alt-tab-macos</string>
    <key>LimitLoadToSessionType</key>
    <string>Aqua</string>
    <key>Program</key>
    <string>/Applications/AltTab.app/Contents/MacOS/AltTab</string>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

(upgrading didn't change the plist)

[b-pfl]

I can confirm the issue of having 2 instances (but not more) from time to time as well. The way I can notice it is that once I press Alt+Tab the App window appears but starts flickering.

Once the issue appears again, I'll do a ps auxwwwe and will share the results.

I think I downloaded the first version from the Website and since then I use the auto-update procedures once an update is available.

[Neoconair]

My post #2510 has been closed & merged into this one but it only appeared after upgrading to macOS 13.3.1 using 6.56.0

Now happens on every startup.

[lwouis]

@Neoconair from what i've seen so far, my best guess is that there is a bug in macOS that affect only certain people who fall in a narrow path of being at version X and upgrading to version Y, while having a certain version of AltTab.

We can't reproduce it consistently, and people on the latest AltTab + macOS don't have this issue. Or have it then don't have it again after they fix it.

Nothing much we can do here unless someone has more data to help characterize the issue

[darthwalsh]

people on the latest AltTab + macOS don't have this issue. Or have it then don't have it again after they fix it.

@lwouis by "fix" do you mean the workaround of killing both AltTab processes, then launching the AltTab Application? I'm not seeing another fix on this thread.

• I've been consistently seeing the bug of 2 AltTab instances after reboot.
• brew (where AltTab is installed) is updating every day. (I'm on AltTab Version 6.58.0 now, even though I haven't manually updated since I last commented).
• I always install the latest macOS blessed by our IT (upgraded to macOS 13.4.1 today).

---

I'm wondering now if the com.lwouis.alt-tab-macos service is actually the unexpected process here here, and the application.com.lwouis.alt-tab-macos.133465628.133465634 service is expected:

When I search for some other brew apps I've installed, many have an application. prefix"

10275   0       application.com.lwouis.alt-tab-macos.133465628.133465634
3079    0       application.digital.twisted.noTunes.102655377.102655383
2478    0       application.com.googlecode.iterm2.117782967.117782973
3143    0       application.leits.MeetingBar.112503608.112503614

I'm seeing steam and karabiner also have services with the application. prefix, but they don't also have another service with the prefix.

-       -9      com.lwouis.alt-tab-macos
-       0       com.valvesoftware.steamclean
- 3295  -9  org.pqrs.karabiner.NotificationWindow
-   0   org.pqrs.karabiner.agent.karabiner_grabber
3046    0   org.pqrs.karabiner.karabiner_console_user_server
3062    0   org.pqrs.karabiner.karabiner_session_monitor
-   0   org.pqrs.karabiner.agent.karabiner_observer

---

Something I noticed last time I was debugging:

$ brew install alt-tab
Running `brew update --auto-update`...
...
==> Installing Cask alt-tab
==> Moving App 'AltTab.app' to '/Applications/AltTab.app'
🍺  alt-tab was successfully installed!

$ launchctl list | grep alt-tab

87851   0   application.com.lwouis.alt-tab-macos.133465628.133465634

$ ls /Users/walshca/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist
/Users/walshca/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist

$ ps auxwwwe | grep AltTab
walshca          87851   0.0  0.2 36594496  65964   ??  S     2:40PM   0:06.36 ... XPC_SERVICE_NAME=application.com.lwouis.alt-tab-macos.133465628.133465634 XPC_FLAGS=1

So, right after brew install alt-tab there was only a application.com.lwouis.alt-tab-macos.133465628.133465634 service loaded.

The file com.lwouis.alt-tab-macos.plist existed on disk, but the service hadn't been loaded yet. What caused com.lwouis.alt-tab-macos to be loaded?

[lwouis]

Hi @darthwalsh,

This is interesting.

Here is my setup:

• I've set AltTab to launch at login through its preferences. Then I've quit it. At this point, no AltTab instance is running.
• I've manually launched AltTab via the LaunchPad UI
• I've manually launched AltTab via Launchd using this command launchctl load -w ~/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist
• At this point, I have 2 instances of AltTab running at once, even though they are from the same .app, and the app contains explicit code to ask the OS not to allow multiple instances. I guess that code only prevents instances initiated by the user, not Launchd.

Now comes the interesting part. Using launchctl commands, we can

~
$ launchctl list | grep alt-tab
63429   0   application.com.lwouis.alt-tab-macos.32215388.32215394
63613   0   com.lwouis.alt-tab-macos

~
$ launchctl print gui/$(id -u)/com.lwouis.alt-tab-macos | head -8      
gui/501/com.lwouis.alt-tab-macos = {
    active count = 4
    path = /Users/lwouis/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist
    type = LaunchAgent
    state = running

    program = /Applications/AltTab.app/Contents/MacOS/AltTab
    inherited environment = {

~
$ launchctl print gui/$(id -u)/application.com.lwouis.alt-tab-macos.32215388.32215394 | head -8
gui/501/application.com.lwouis.alt-tab-macos.32215388.32215394 = {
    active count = 4
    path = (submitted by runningboardd.372)
    type = Submitted
    state = running
    bundle id = com.lwouis.alt-tab-macos

    program = /Applications/AltTab.app/Contents/MacOS/AltTab

So the application.com.lwouis.alt-tab-macos.*** is actually the instance from manually launching through the UI. Quitting the app indeed removes this entry from launchctl list.

Could you please show me what similar commands show in your case, when you have 2 instances running at the same time? I'm especially interested in the path and program lines from launchctl print.

Thank you

[b-pfl]

I can confirm the issue of having 2 instances (but not more) from time to time as well. The way I can notice it is that once I press Alt+Tab the App window appears but starts flickering.

Once the issue appears again, I'll do a ps auxwwwe and will share the results.

I think I downloaded the first version from the Website and since then I use the auto-update procedures once an update is available.

My current assumption is that the 2nd instance is related to a system restart. Could it be that the option to restart all applications (in MacOS) on restart is cause for this issue?

[bwt615]

I have the same issue! I feel this should be treated as a bug. Two thoughts:

1. Add a check for running instances prior to launch
2. Use this bundle key: LSMultipleInstancesProhibited

Seems a inherently risky to not have some sort of safeguard against this.

[lwouis]

I looked into LSMultipleInstancesProhibited. It has this downside: "it will also prevent multiple users (fast user switching) from using your application concurrently". So not a good candidate to fix the issue.

Regarding the issue in general, I don't know how easy it would be to handle with new logic around the launch code. Some scenarios to keep in mind:

• When updating the app using the built-in auto-update system (i.e. Sparkle), there may be a need to have 2 apps at the same time for a short time, when the new version is launched by the previous version.
• There is already an override of applicationShouldHandleReopen. This is used so that, if AltTab is already running, and the user launches it, it will not launch another instance, and instead will simply open the Preferences window.
• There is code in AltTab to restart itself. That code happens for example if the user removes some System Permission, while the app is running. The app will restart itself and present the permission dialog.

The restart code is the following:

func restart() {
   // we use -n to open a new instance, to avoid calling applicationShouldHandleReopen
   // we use Bundle.main.bundlePath in case of multiple AltTab versions on the machine
   Process.launchedProcess(launchPath: "/usr/bin/open", arguments: ["-n", Bundle.main.bundlePath])
   App.shared.terminate(self)
}

Notice how we first launch another instance, then we terminate the current instance. I'm not sure how we could do it differently.

Finally, the identity of an app is not that simple, I believe. There is the BundleIdentifier, but also the location of the app, and probably other factors. Identify is part of the issue of not launching multiple instances of the same app.

It's not an easy problem. If you have an idea on how to tackle this, please share a PR, and I'll gladly review its code 👍

[bwt615]

Hmm - what if we had a toggle for the first one? I think a majority of Macs tend to be single user devices! That might be the quick win :)

[lwouis]

There would still be the issues I mentioned about Sparkle and permissions, which require a restart, and that restart being implemented as "start new instance, then stop current instance".

[darthwalsh]

Could you please show me what similar commands show in your case, when you have 2 instances running at the same time? I'm especially interested in the path and program lines from launchctl print.

@lwouis sorry for the delay. My work switched me from Intel macbook, to a new Apple Silicon Macbook. On this new machine, I have never had the problem with multiple AltTab instances.

On this new machine, I installed AltTab through brew's cask "alt-tab". IIRC at some point I got prompted to install an AltTab update, and I just clicked the default. (I set brew to install updates every night, but I'm never sure how that's supposed to interact with apps that can auto-update.)

bash-3.2$ launchctl list | grep alt-tab
45941   0   application.com.lwouis.alt-tab-macos.8626781.8626787
-   0   com.lwouis.alt-tab-macos
bash-3.2$ launchctl print gui/$(id -u)/com.lwouis.alt-tab-macos | head -8
gui/502/com.lwouis.alt-tab-macos = {
    active count = 0
    path = /Users/walshca/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist
    type = LaunchAgent
    state = not running

    program = /Applications/AltTab.app/Contents/MacOS/AltTab
    inherited environment = {
bash-3.2$ launchctl print gui/$(id -u)/application.com.lwouis.alt-tab-macos.32215388.32215394 | head -8
Bad request.
Could not find service "application.com.lwouis.alt-tab-macos.32215388.32215394" in domain for user gui: 502

To anybody else having this problem with multiple instances, I wonder if a workaround to uninstall AltTab, ensure both the above launchctl are deleted, then installing latest AltTab, would solve the problem?

[FamilyGuy0395]

I have AltTab start when I boot up my Mac and I have it stay in the menu bar. However, when I boot up my Mac from a powered off state, instead of it appearing once in the menu bar, it appears twice.

AltTab version: 6.65.0 macOS version: 14.3.1

[wiserockryan]

I'm not sure whether this affects anyone else, but I realized I had both checked the option to "Start at login" and added AltTab to my "Open at Login" Login Items in the General Settings. This resulted in the same problem. I've tested removing the latter and leaving the "Start at login" checked, which resulted in only one instance and no flicker. I don't remember if I manually added it to the Login Items or not.

[lwouis]

One way to launch 2 AltTab instance at once, as we saw from https://github.com/lwouis/alt-tab-macos/issues/3550#issuecomment-2298104408, is to:

Maybe because I checked inside app "Start at login" and also register this app as "Open at login" in General Setting?

I can't think of a reason why users may want multiple AltTab instances running. We could implement a check a launch, so AltTab refuses to launch if it detect another instance. However, this could have issues:

• How to detect other instances? We should be able to use the BundleID, I imagine. That shouls be safe
• What if the first instance launched is the "bad" one. Launched by something mecanism unknown to the user. Should we also check who the parent of the instance is? It seems hard to know what's legitimate and what's not. Users can have custom setups they enjoy. Maybe just blocking any instance after 1 is already running would be enough?

[darthwalsh]

How to detect other instances? What if the first instance launched is the "bad" one

In my experience: either try to take a named semaphore or an exclusive file lock (possibly those have the same underlying implementation on macOS). This avoids any race condition or needing to decide which instance is "bad."

As a first pass, printing log messages about parent process sounds useful, so the next time "[In-app feedback]" gets created we can start to see the root cause?

[lwouis]

In my experience: either try to take a named semaphore or an exclusive file lock (possibly those have the same underlying implementation on macOS). This avoids any race condition or needing to decide which instance is "bad."

I don't think we could implement something as simple as "first instance gets the spot; other instances will quit". Let's take the example I shared above: the user has checked the checkbox to get AltTab to launch at login. At the same time, they've added AltTab to their Login Items manually. Which one of those should we keep? Also should have the dance of both instance trying to launch, and the second fails, on every login? Or should we take more actions, and try to disable secondary launches root cause (e.g. remove the Login Items programmatically, or remove the LaunchAgent programmatically?

[Thomas1664]

I also encountered the flickering problem caused by multiple instances of AltTab. I did some digging and came across this SO article: https://stackoverflow.com/questions/74714844/how-to-use-named-object-in-macos-to-limit-app-instances

[lwouis]

Thank you @Thomas1664

As I stated above, the issue is not that we can't prevent secondary instances from launching. I think we could do that if we wanted. The issue is then if a user has a wrong setup, 2 instances would try to launch each time, and one would auto-close.

I think a proper solution would be to attack the root cause and disable either the Login Item, or the LaunchAgent, if we notice that both exist.

In the meantime, the best is probably to add logs to see where these instances are coming from.

@Allsochen has added a logging library on the branch we are working on. I think after we merge it, we should use it to add a new log on launch, showing the parent process / the origin of the launch.

Thank you