升级1.4后无法检测需要更新的应用（After upgrading to version 1.4, apps that need to be updated cannot be detected）

[TianLi-520]

先打开applite更新频道无法检测到需要更新的应用，先打开wailbrew检测到更新信息后applite刷新状态就可以看到了
If you open the Applite update channel and it doesn't detect any apps that need updating, open Wailbrew first to check for updates; once it detects them, refresh the Applite status and you'll see them.

[bunnysayzz]

Hi, I'd like to fix this one. I traced the code and it looks like a 1.4 regression in how Applite refreshes Homebrew's metadata.

Root cause: getOutdatedCasks() (InstalledCaskService.swift) only runs brew outdated --cask -q, and brew outdated reports what's in Homebrew's local formula metadata. Nothing in the current tree refreshes that metadata: there is no brew update call anywhere, and the annex refresh (refreshAnnexBrew in AnnexBrewManager.swift) explicitly no-ops unless the annex is the selected brew (guard BrewPaths.selectedBrewOption == .annex). So for users on their own Homebrew (e.g. Wailbrew's), the outdated list is only as fresh as the last metadata update that happened outside Applite, which matches the report: open Wailbrew first (it runs brew update), then refresh Applite and the updates show up.

This wasn't always the case. The 1.4 annex commit (6626f52, "Replace first-run onboarding with a CLT-free annex Homebrew") removed updateHomebrew(), which ran Shell.runBrewCommand(["update"]) from the old Brew Management view. So 1.4 dropped the only in-app metadata refresh for the user-brew path.

Fix plan: refresh the formula metadata before/alongside the outdated check for the non-annex path, e.g. run brew update (gated on the same staleness check Homebrew uses, and on the annex path keep the tarball refresh), with verification that the outdated list reflects fresh metadata afterward. Happy to adjust the approach if you'd rather handle metadata freshness differently.

I can't reproduce the reporter's exact setup here, so I'd appreciate your confirmation that this matches what you intended before I open a PR. Thanks!

[milanvarady]

Let me check this first. I'm not a at my computer right now, I'll get back to this in a few days.

[TianLi-520]

Hi, I'd like to fix this one. I traced the code and it looks like a 1.4 regression in how Applite refreshes Homebrew's metadata.

Root cause: getOutdatedCasks() (InstalledCaskService.swift) only runs brew outdated --cask -q, and brew outdated reports what's in Homebrew's local formula metadata. Nothing in the current tree refreshes that metadata: there is no brew update call anywhere, and the annex refresh (refreshAnnexBrew in AnnexBrewManager.swift) explicitly no-ops unless the annex is the selected brew (guard BrewPaths.selectedBrewOption == .annex). So for users on their own Homebrew (e.g. Wailbrew's), the outdated list is only as fresh as the last metadata update that happened outside Applite, which matches the report: open Wailbrew first (it runs brew update), then refresh Applite and the updates show up.

This wasn't always the case. The 1.4 annex commit (6626f52, "Replace first-run onboarding with a CLT-free annex Homebrew") removed updateHomebrew(), which ran Shell.runBrewCommand(["update"]) from the old Brew Management view. So 1.4 dropped the only in-app metadata refresh for the user-brew path.

Fix plan: refresh the formula metadata before/alongside the outdated check for the non-annex path, e.g. run brew update (gated on the same staleness check Homebrew uses, and on the annex path keep the tarball refresh), with verification that the outdated list reflects fresh metadata afterward. Happy to adjust the approach if you'd rather handle metadata freshness differently.

I can't reproduce the reporter's exact setup here, so I'd appreciate your confirmation that this matches what you intended before I open a PR. Thanks!

是的，我想解决的问题就是这个（Yes, that's exactly the problem I want to solve.）