When starting FluidVoice, if the SwiftUI main window takes too long to render (e.g., when the system is under heavy load or audio subsystems take a moment to initialize), the app's AppDelegate attempts to force the window open by requesting a LaunchServices reopen.
However, this reopen command spawns a completely new process instance in the background because it appears to be using createsNewApplicationInstance = true (or equivalent open -n logic) instead of just bringing the existing instance to the front. Because the original instance never actually terminates, the user ends up with duplicate FluidVoice processes running at the same time, causing conflicts with global hotkeys and microphone capture.
Logs showing the behavior:
[RUN] PID=44596 AppVersion=1.6.7 Build=18 OS=Version 15.7.7
[13:11:17.107] [DEBUG] [AppDelegate] Main window not ready during launch reveal retry
...
[13:11:17.632] [DEBUG] [AppDelegate] Main window not ready during launch reveal retry
[13:11:17.632] [INFO] [AppDelegate] Requesting LaunchServices reopen to create SwiftUI main window
[13:11:17.651] [INFO] [SimpleUpdater] SimpleUpdater: Successfully relaunched app, terminating old instance
[RUN] PID=44611 AppVersion=1.6.7 Build=18 OS=Version 15.7.7 (Build 24G720)
At this point, both PID 44596 (the original) and PID 44611 (the duplicate) remain running indefinitely.
Suggested Fix:
The LaunchServices configuration in AppDelegate should not use setCreatesNewApplicationInstance: YES when attempting to restore the SwiftUI window scene. Instead, it should just request the existing application to activate, or the retry logic for the SwiftUI lifecycle should be re-evaluated.
When starting FluidVoice, if the SwiftUI main window takes too long to render (e.g., when the system is under heavy load or audio subsystems take a moment to initialize), the app's
AppDelegateattempts to force the window open by requesting a LaunchServices reopen.However, this reopen command spawns a completely new process instance in the background because it appears to be using
createsNewApplicationInstance = true(or equivalentopen -nlogic) instead of just bringing the existing instance to the front. Because the original instance never actually terminates, the user ends up with duplicateFluidVoiceprocesses running at the same time, causing conflicts with global hotkeys and microphone capture.Logs showing the behavior:
At this point, both
PID 44596(the original) andPID 44611(the duplicate) remain running indefinitely.Suggested Fix:
The LaunchServices configuration in
AppDelegateshould not usesetCreatesNewApplicationInstance: YESwhen attempting to restore the SwiftUI window scene. Instead, it should just request the existing application to activate, or the retry logic for the SwiftUI lifecycle should be re-evaluated.