fix: unresponsive UI and MCP

[xverges]

What happened?

After the weekend, the app is malfunctioning, with the UI not updating the activity displayed even when changing dates.

Screen.Recording.2026-05-11.at.11.04.35.mov

MCP requests are timing out for both tools.

UI export ends up in a spinning ball before asking for the file name.

Logs

Last log from log stream --predicate 'subsystem == "com.renjfk.SimplyTrack"' --style compact seems to be
2026-05-07 17:49:45.569 E SimplyTrack[43547:4b1475d] [com.renjfk.SimplyTrack:FirefoxBrowser] Firefox accessibility tree not available. User needs to set accessibility.force_disabled to -1 in about:config.. Note that the 7th is the last day where vertical bars in the UI are displayed

Expected behavior

Just Works :-)

Steps to reproduce

Use my laptop and take the weekend off 😛

macOS version

15.7.4

App version

Version 0.9-pr69.3402e45 (12)

Browser involved

No response

Screenshots

No response

[renjfk]

Hey @xverges, I've also been hitting the same (or a very similar) issue on my end. I've spent quite some time looking for the root cause but haven't been able to pinpoint it yet.

For now, my temporary workaround has been to restart the app every two or three days.

It's definitely good to have this tracked for future reference. I'll keep investigating and update here if I find anything.

[xverges]

I sampled the app while it was hanging. The main thread looks idle in the normal run loop, but several Swift async tasks appear blocked in AppleScript/Apple Events calls (NSAppleScript → OSAExecute → AESendMessage); maybe some scripts are hanging and this ends up impacting everything. The sample also shows NIO event-loop threads parked in kevent, that looks expected to me. I can share the sample if useful.

I also see several instances of SimplyTrackMCP; here the fault must be on the MCP clients, but I thought it is worth mentioning.

[renjfk]

These are great findings really so if you could share it would be great considering they don't include anything sensitive 🙏

[xverges]

Hi @renjfk
Here it is Sample of SimplyTrack.txt

[renjfk]

Let's see if v0.10-pr73.52c893b helps a bit. I'll use it couple of days and see how it behaves.

[xverges]

It is been almost a week, and, in my laptop, so far, so good 👏

BTW, I just noticed

+        logger.log(
+            "activity_tracking decision=active_app_changed source=\(source, privacy: .public) bundle=\(identifier, privacy: .public) name=\(name, privacy: .public)"

and I think it is very cool and supersedes my initial reason for wanting an export (but I got more reasons now 😉). I wonder, though, if it should be at DEBUG level.

[renjfk]

Humm, I don't know which version you have been testing with but I had some issues with the prerelease I mentioned earlier and created another one with v0.10-pr73.2dcf407 and this has been working perfectly for me.

As for the logging level; I've also thought about it but wanted to keep it since it doesn't (shouldn't!) cause too much verbosity and would also help tracking future issues even without asking the users to enable logging explicitly. Or did you mean to just change the level to DEBUG but still keep it enabled all the time?

[xverges]

Interesting. I was on Version 0.10-pr73.52c893b (15), but I am not a Safari user.

Yep, I'd keep it enabled all the time. I was just suggesting switching to logger.debug, but mine is definitely not an informed opinion, as I have not looked at how are the rest of the logs go.

[renjfk]

Regarding logs, there's some additional consideration; the logs with debug level are not persisted to disk so in this case it wouldn't really be useful for future scenarios. I'll proceed with merging current PR and make new release.