My macOS TestFlight app keep deactivating its windows as if there's another invisible window in front

Question

Thomas Tempelmann OP

Created 3w

Replies 2

Boosts 0

Participants 1

Has anyone else seen this happen with their macOS apps in TestFlight?

The situation:

When I launch my app that's been downloading via TestFlight.app, it often comes up with its main window deactivated.

Also, when I have open more than one window and close one, the other window doesn't come to front either.

In either case, activating the app or clicking into a window will activate it properly.

It feels as if there's another window that's not visible but somehow keeps getting activated.

I have this happen on two Macs running both Sonoma and Monterey.

Also, if I take the very same build that I had uploaded to TestFlight and run it directly, it works correctly. So I suspect that TestFlight somehow messes with my app's windows.

If you want to test this yourself: Get the app thru this link: https://findanyfile.app/TestFlight/

Then launch it. Often, the Find window will already come up without being active. Activate it, then open the Preferences window by typing cmd-comma. Then close the Prefs window with cmd-W. This should re-activate the Find window but will instead leave it deactivated, and none of the menu shortcuts (such as cmd-comma, cmd-N or cmd-Q) work. That's the bug.

I wonder how I can debug this to find a work-around for this odd behavior.

E.g, I'd like to see if there is indeed a semi-hidden window causing this. How would I do this? I could probably make a new TestFlight build that queries the app's windows array and logs it. But are there other ways to query an app's windows? I tried AppleScript, but since my app isn't scriptable, I only get an error -1728 for tell app "Find Any File" to get windows.

Answered by Thomas Tempelmann in 788823022

Nevermind this - it was indeed a bug in my code, but not where I looked. I have a helper app that may keep running in the background, and that is tied to the running app in a way that if they're not synched, like it is when the app is signed for TestFlight, it gets something wrong.

Boost

Answer 1

Thomas Tempelmann OP

3w

(Argh, this damn forum software lost my edit to the original post above after I submitted it because I had been logged out due to inactivity. Sonow I have to type it in again. Grrr!)

New findings:

When I close the Prefs window, the other window becomes briefly activated and then immediately deactivates.
I used CGWindowListCopyWindowInfo to compare the windows of the correctly vs the badly behaving app versions, and found no differences. So it's rather something where my window get explicitly deactivated. I have no such calls in my own code, though.

0

Answer 2

Thomas Tempelmann OP

3w

Accepted Answer

Nevermind this - it was indeed a bug in my code, but not where I looked. I have a helper app that may keep running in the background, and that is tied to the running app in a way that if they're not synched, like it is when the app is signed for TestFlight, it gets something wrong.

0