Add Homebrew-based update support for limited apps

[Qetesh]

Hi, first of all, thank you for creating this project. I really like this tool and appreciate the work you’ve put into it.

I personally have a strong habit of keeping my apps up to date, so this project is especially useful to me. While using it, I noticed that many apps are currently in a limited state and can only be updated manually. Because of that, I tried adding support for updating those apps through Homebrew, using brew reinstall --cask --force.

Along with that, I also adjusted the description and colors for the limited support state, with the colors inspired by Homebrew’s visual style.

This is a relatively significant change, so I’d like to use this PR as a starting point for discussion: whether this direction makes sense for the project, and whether the implementation approach is appropriate.

Thanks again for the great app — I’d be very happy to hear your thoughts.

[moreaki]

I don't think this is ready to merge yet.

The main problem is that this changes Homebrew from an external/open-only path into a built-in brew reinstall --cask --force <token> flow, but the app-to-cask match is still based on the existing filename/bundle-ID heuristics in UpdateRepository.entry(for:). There is no check that the installed app is actually managed by Homebrew before Latest offers the built-in update action. In practice that means a manually installed app like Firefox.app can now be treated as Homebrew-updatable just because Homebrew is installed locally. At best that produces a failing brew reinstall; at worst it makes Latest take over an install the user never intended to manage with Homebrew.

There is also a regression in the current "limited support" behavior. Homebrew apps still report .limited support, but once Homebrew is installed this PR makes them use a built-in updater action. The list filtering and update counting code still key off usesBuiltInUpdater, so the "include apps with limited support" setting no longer consistently controls Homebrew apps. The same Homebrew-backed app can be hidden when Homebrew is absent and shown when Homebrew is installed, even though its support state is still "limited" in the UI.

Before merging, I'd want either a reliable ownership check that confirms the app/cask is already installed and managed by Homebrew before offering the built-in update path, or to keep Homebrew in the external flow until that check exists.

[Qetesh]

Thank you for the detailed feedback.

I agree that forcing Homebrew to take over apps that were not originally managed by Homebrew is a real problem, and it should not happen implicitly.

A better direction may be to make this an explicit user choice instead of a built-in update path for all limited apps. For example:

• add an action on the limited app page that lets the user explicitly choose to have Homebrew take over that app, or
• add a setting that allows Homebrew to take over limited apps that need updates.

In both cases, Latest could show a clear warning that this may change how the app is managed, may replace a manually installed version with a Homebrew-managed one, and may cause compatibility issues in some cases.

In my own usage, this approach has generally worked well and makes updating very convenient, but I agree that there are still some incompatibility cases and edge cases.

If an app is taken over this way, it may also make sense to introduce a separate Homebrew-specific state instead of keeping it under .full or .limited. That could make the behavior clearer and avoid the inconsistency you mentioned around limited support and built-in updater handling.

If that seems more aligned with the project, I’d be happy to rework the PR in that direction.

Thanks again for the thoughtful review.

[moreaki]

Explicit opt-in is a much better direction.

My main concern is still that Latest should not silently infer "this app is managed by Homebrew now" from a loose name / bundle-ID match plus the presence of Homebrew on the system. If this is reworked, I think the safe bar should be:

• Latest only offers a normal built-in Homebrew update path when it can confirm the app is already managed by Homebrew.
• Anything else should be presented as an explicit takeover action with clear warning text, not as the default update behavior.
• That takeover path should probably not reuse the existing built-in updater semantics unchanged, because it is a materially different operation from updating an already-managed app.

I also think the support/filtering model needs to stay coherent. Right now .limited support has a fairly clear meaning in the UI, and the list filtering / counts depend on that. If Homebrew takeover is introduced, it would help to model that explicitly rather than having the same app move between limited and built-in behavior depending only on whether Homebrew happens to be installed locally.

Implementation-wise, I’d probably split it into two phases:

1. ownership detection

• add a Homebrew ownership check that asks Homebrew what is actually installed locally
• only enable the normal built-in Homebrew update action if that check confirms the app is already managed by Homebrew
• otherwise keep the current external / limited behavior

2. explicit takeover

• add a separate user action for Manage with Homebrew or similar
• gate it behind a confirmation sheet that explains that Latest may replace the manually installed app with a Homebrew-managed one
• after takeover succeeds, persist enough state so the app is clearly treated as Homebrew-managed from then on

I’d also keep the state model explicit instead of deriving everything from usesBuiltInUpdater. For example, something like:

1. externally managed / limited
2. Homebrew-managed
3. eligible for Homebrew takeover by explicit user choice

That should make the UI, filtering, and update counting much easier to keep consistent.

So yes, I think a rework in that direction makes sense. I’d just want the revised PR to keep the distinction clear between:

1. already Homebrew-managed apps
2. apps that could be taken over by Homebrew if the user explicitly chooses that
3. apps that Latest should continue to treat as external / limited only

Also, just for context: I’m not the maintainer here and I’ve only been looking at this project for the past two days, so this is only one more opinion in the discussion. Ultimately the maintainer will need to decide what direction makes the most sense for Latest.