Improve cached startup state and keep directory scans responsive

[moreaki]

Summary

On top of fix/combined-directory-monitoring, this branch turns the app into a much better "show something immediately, finish work in the background" experience, and adds guardrails for the slow-path cases.

The main user-facing changes are:

• Latest restores the last known app list on launch from cache in AppDataStore, instead of starting with an empty main window every time.
• Cached update availability is restored too, via Update, App, and UpdateButton, but stale cached updates are treated as non-actionable until a fresh check confirms them.
• Snapshot generation for the main table was moved off the main thread and coalesced in UpdateTableViewController, UpdateTableView+Search, and AppListSnapshot, so large refreshes no longer block the UI while snapshots are rebuilt.
• The Settings locations list no longer repeatedly rescans the same directory count on every redraw; AppDirectoryCellView now uses a shared cached/deduplicated count provider.
• Adding a very broad scan root like /, the home folder, or a whole volume now triggers a warning in AppLocationViewController, so users are nudged toward choosing a narrower app folder instead of accidentally selecting an entire disk.

Under the hood, scan performance and scan behavior were tightened:

• BundleCollector now enumerates candidate .app bundles first and processes them concurrently for larger result sets.
• Source detection no longer needlessly reopens bundles, via BundleCollector, MacAppStoreCheckerOperation, SparkleCheckerOperation, and UpdateCheckCoordinator.
• AppDirectory now performs collection work on a utility queue instead of doing that work inline on a generic serial queue with a misleading name.

The branch also includes diagnostics and failure UX that fit naturally on top of the combined monitoring base branch:

• Observation failures are buffered until a delegate exists in UpdateCheckCoordinator, so startup failures are not dropped.
• Opt-in diagnostics tracing lives in Observable, disabled by default, so we can later build richer app-aware tracing on top of it.
• Real observation/access failures are shown through the polished custom sheet in MainWindowController, and the same component is reused from Settings when a location count hits the same failure mode.
• Strings for the broad-folder warning and permission/access guidance were added in Localizable.strings.

So the PR story is basically:

• base branch fix/combined-directory-monitoring fixes correctness: no startup crash, recursive monitoring, visible access-failure handling
• this branch improves responsiveness and usability on top of that: cached startup state, nonblocking UI refresh, faster/more efficient scanning, smarter Settings behavior, and retained diagnostics support

Verification

• xcodebuild -project Latest.xcodeproj -scheme Latest -configuration Debug CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= build

I did not run the full test suite end-to-end because the existing test-target dependency issue with CommerceKit / StoreFoundation still applies.

[DannyGoodall]

@moreaki, what is the status of your fork and this pull request?

I am concerned that the original author is unable to dedicate the time to fix some of the show-stopping bugs that seem to be present in the upstream repo.

[moreaki]

@moreaki, what is the status of your fork and this pull request?

I am concerned that the original author is unable to dedicate the time to fix some of the show-stopping bugs that seem to be present in the upstream repo.

@DannyGoodall — thanks for raising this.

I haven’t revisited the fork in detail recently, but from a technical standpoint the pull request should still be valid.

To provide some context: the changes I proposed were driven by concrete, reproducible issues affecting real-world usage. These weren’t edge cases—they were problems that materially impact reliability and user experience. In its current state, the tool struggles in areas that are fundamental for something intended to be depended on.

Following the initial feedback from the maintainer, it became clear that my contribution approach wasn’t aligned with the project’s current workflow. I respected that and stepped back rather than forcing a direction that wasn’t shared.

That said, the underlying situation hasn’t really changed. A number of the issues identified are relatively straightforward to resolve but have remained unaddressed, while the codebase itself carries a level of historical complexity that makes incremental improvement slower and less effective than it could be—particularly on the UI side.

From a product perspective, this creates a gap between what users need—a reliable, predictable update-checking tool—and what the current implementation consistently delivers. At that point, the question is less about individual fixes and more about direction: whether to actively stabilize and streamline the existing codebase, or to move toward a more focused and maintainable approach.

If there is genuine interest in addressing this in a structured way, I’m open to re-engaging—either by progressing the fork with clearer ownership and priorities, or by pursuing a more deliberate reimplementation. But that would need alignment on goals and expectations to be effective.

[DannyGoodall]

Thanks for your detailed feedback @moreaki.

I did see some comments and deleted posts on one of the change requests that made me wonder why the PR wasn't accepted - and whether it might not have been welcomed. So your explanation makes sense. Like you, I can respect the view of the author, but I'm also aware that there are many un-actioned issues and PRs building up.

I note that the author's dev branch is significantly ahead of main but that nothing appears to have been actioned for 3+ months. Again, I respect that Latest is a part time project for the author and free/free.

I have zero experience of Mac OS desktop software but I did manage to fork, fix and build a version that addressed the particular bug I had.

I think for the time being I will fork your fork, apply my fix and work from that for now.

If I manage to engage the original author, I will try to stress your willingness to re-engage on a mutually aligned basis.

👍