fix(desktop): repair application picker

[mauropereiira]

This PR was implemented by an AI agent working interactively under @mauropereiira's direction. The diff and test results were reviewed before submission.

Issues

Fixes #3920.

Description

The installed-app catalog already returns bundle identifiers such as com.apple.TextEdit and md.obsidian. AppSearchIndex::populate() then incorrectly filters those identifiers by checking whether they end in .app, so ordinary applications never enter the search index.

This removes that path-only suffix check. No other picker, catalog, cache, or frontend behavior is changed.

How Has This Been Tested?

• Built an isolated Apple Silicon macOS app from the PR base with only this fix.
• Confirmed Harper's real Spotlight catalog finds TextEdit (com.apple.TextEdit) and Obsidian (md.obsidian).
• Manually confirmed both appear in the application picker and that Obsidian can be added.
• cargo check -p harper-desktop --all-targets
• pnpm check in harper-desktop (0 errors, 0 warnings)
• cargo fmt --all

AI Disclosure

• I am a human and didn't use any AI.
• I used LLM features of my editor, but not an agent.
• I consulted one or more coding AIs, but didn't use an agent.
• I used an AI agent interactively.
• I am an agent or I got an agent to do the work autonomously.

If Your PR Implements or Enhances a Linter

Not applicable.

Checklist

• I have performed a self-review of my own code
• I have added tests to cover my changes
• I have considered splitting this into smaller pull requests.

[elijah-potter]

You've made quite a few changes here that seem beyond the scope of the issue. Did you try the recommended fix from the issue? Did it work?

[mauropereiira]

Good call asking this. I did some tests when we shipped the PR, but I went back and tested it again and it seems to be working correctly.

I built a separate macOS app from the PR base with only the .app suffix check removed. Harper’s real Spotlight catalog found both TextEdit (com.apple.TextEdit) and Obsidian (md.obsidian), and I manually confirmed that both appeared in the picker and that Obsidian could be added.

That also made it clear the original PR had gone well beyond the issue. I’ve cleaned it up and removed the extra tests, dependencies, Browse feature, cache changes, plist parsing, and frontend work. The PR is now just the recommended fix: one file changed, six lines removed.
Sorry for the extra work. 😅

[hippietrail]

If you really want to keep working on this now or in the future, there are macOS APIs that get different results that what mdls gets. I can't remember if I posted any of my experiments with them as draft PRs or if I just mentioned the names of the APIs.

I found both ways to be quite finicky with what needed to be filtered and everything I tried either left out stuff that should've been included or included stuff that shouldn't really be there. I tried manually and with different AIs and hunted around the Internet for best ways to filter them.

You can search for "bumble" either in the PRs here or in my GitHub for a standalone Mac App that builds much faster for experimenting and iterating.

[mauropereiira]

Thank you so much for looking at this.

I did spin up an agent to go hunting for the mythical "bumble" and it came back empty, both across your public repos and the PRs here. So if you happen to track down where it ended up, let me know.

The API names would be super useful too, even just from memory. Thanks!

[hippietrail]

Thank you so much for looking at this.

I did spin up an agent to go hunting for the mythical "bumble" and it came back empty, both across your public repos and the PRs here. So if you happen to track down where it ended up, let me know.

The API names would be super useful too, even just from memory. Thanks!

Oops you're right. I think I only mentioned it but maybe not even by name. Looks like I've got 3 versions here. I'll have a quick look and then publish one or more of them to GitHub...

[hippietrail]

Here you are. I've forgotten most of what I did back then. There's a Tauri app and two commandline apps. The commandline app using the objc2 crate is the newest but the Tauri one is most comparable to how the Harper Desktop app works form the user perspective.

https://github.com/hippietrail/bumble

I made sure they all build and run but didn't look at the code yet so I can't remember if some use the macOS APIs and some still run the shell command. I could've sworn I had one that displayed in a lightweight AppKit window but that shows how much I've forgotten in two months (-:

[mauropereiira]

Thanks for digging these out and publishing them.

The README actually answers the bit you were unsure about:

They all use the macOS Spotlight APIs directly (NSMetadataQuery). Before this I experimented with capturing the output of the mdls shell command.

So all three are on the API already, and the shell version was the earlier experiment.

Useful comparison for here: Harper Desktop is still on the shell side of that line. app_catalog.rs shells out to mdfind with kMDItemContentType == "com.apple.application-bundle", then again per bundle ID with kMDItemCFBundleIdentifier. So it is reading the same Spotlight index bumble does, just through a subprocess instead of NSMetadataQuery.

That suggests the valuable part of bumble for us is not the data source, since that is already the same, but the things you listed around it. The 300ms timeout with cancellation in the Tauri version, and the /Applications/ path filtering in the objc2 one. The mdfind calls here are blocking with no timeout, and the filtering is exactly the finicky part you warned about.

I am going to keep that out of this PR though. This one stays the six-line removal, since that is what the issue actually reported and I have already made it too big once. If the NSMetadataQuery swap looks worth doing, I would rather open a separate issue and point it at bumble.

[hippietrail]

Thanks for digging these out and publishing them.

The README actually answers the bit you were unsure about:

They all use the macOS Spotlight APIs directly (NSMetadataQuery). Before this I experimented with capturing the output of the mdls shell command.

Yes I got an AI to whip up a readme from looking at the code after I wrote my previous reply.

So all three are on the API already, and the shell version was the earlier experiment.

Useful comparison for here: Harper Desktop is still on the shell side of that line. app_catalog.rs shells out to mdfind with kMDItemContentType == "com.apple.application-bundle", then again per bundle ID with kMDItemCFBundleIdentifier. So it is reading the same Spotlight index bumble does, just through a subprocess instead of NSMetadataQuery.

That suggests the valuable part of bumble for us is not the data source, since that is already the same, but the things you listed around it. The 300ms timeout with cancellation in the Tauri version, and the /Applications/ path filtering in the objc2 one. The mdfind calls here are blocking with no timeout, and the filtering is exactly the finicky part you warned about.

Well it suggests that, but if you play with both you find that the reality doesn't match the expectation. While I'm sure mdfind must surely use the Spotlight APIs, since I couldn't find any other relevant APIs, it must do some kind of filtering. And from what I remember of my experiments back then, both were different from the ideal, which was matching what the new "Apps" app introduced in Tahoe does.

I am going to keep that out of this PR though. This one stays the six-line removal, since that is what the issue actually reported and I have already made it too big once. If the NSMetadataQuery swap looks worth doing, I would rather open a separate issue and point it at bumble.

No worries.

[mauropereiira]

On my machine that query returns 441 bundles, and only about 55 of them are under /Applications:

mdfind 'kMDItemContentType == "com.apple.application-bundle"'   ->  441
  of those, outside /Applications                               ->  386
/Applications/*.app on disk                                     ->   43

Some of the 386 are things nobody wants in a picker:

/System/Library/CoreServices/DiskImageMounter.app

but plenty are things you clearly do want, like /System/Applications/Mail.app, Preview.app and TextEdit.app. So the /Applications/ filter from bundlebee-objc2 would be far too aggressive on this machine, which I take it is exactly the kind of thing you kept running into.

Amusingly /System/Applications/Apps.app is itself in the results, so the Tahoe app you were treating as the ideal is sitting right there in the list.

I have written it up as #4084 with these numbers, including your point that the two do not return the same thing in practice, and the Tahoe Apps app as the target definition. This PR stays as it is.

[hippietrail]

I think the best approach will probably be to keep an eye out for bug reports about it not finding apps. I know not all apps are in /Applications/. I often run things directly out of ~/Downloads/ until I decide to permanently install them. And there's also apps I build for myself which I run out of where I work on them.

I also know the system will run any apps off any external drive I attach, whether it's an older macOS install with an /Applications/ dir or just random saved stuff. Spotlight seems to find them when you attach a drive. I can't remember what apps Harper wasn't finding that caused me to want to dig deeper with this but I'm guessing it was some editors or IDEs I'd downloaded and unarchived in ~/Downloads/ but not installed and that I could still run via Spotlight.

[mauropereiira]

Agreed, and this machine backs you up. There are app bundles in ~/Desktop, ~/Code and ~/Applications here, so an /Applications-only filter would hide exactly the cases you describe.

I have put the numbers on #4084, including one thing I did not expect: about 11% of what Spotlight returns for that content type is not a directory at all. Harper already survives it, but it means the content type alone is not a reliable signal.

Watching for "it did not find my app" reports seems like the right call, and it is a much better failure to debug than silently dropping someone's editor.