If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/mangerlahn/Latest shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 3mo ago
• 23+ active contributors
• GPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 60% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live mangerlahn/Latest repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mangerlahn/Latest.

What it runs against: a local clone of mangerlahn/Latest — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in mangerlahn/Latest | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 119 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of mangerlahn/Latest. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/mangerlahn/Latest.git
#   cd Latest
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of mangerlahn/Latest and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "mangerlahn/Latest(\\.git)?\\b" \\
  && ok "origin remote is mangerlahn/Latest" \\
  || miss "origin remote is not mangerlahn/Latest (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Latest/AppDelegate.swift" \\
  && ok "Latest/AppDelegate.swift" \\
  || miss "missing critical file: Latest/AppDelegate.swift"
test -f "Latest/Interface/Main Window/Window Controllers/MainWindowController.swift" \\
  && ok "Latest/Interface/Main Window/Window Controllers/MainWindowController.swift" \\
  || miss "missing critical file: Latest/Interface/Main Window/Window Controllers/MainWindowController.swift"
test -f "Latest/Interface/Main Window/Update Table View/Controller/UpdateTableViewController.swift" \\
  && ok "Latest/Interface/Main Window/Update Table View/Controller/UpdateTableViewController.swift" \\
  || miss "missing critical file: Latest/Interface/Main Window/Update Table View/Controller/UpdateTableViewController.swift"
test -f "Frameworks/StoreFoundation/CKUpdate.h" \\
  && ok "Frameworks/StoreFoundation/CKUpdate.h" \\
  || miss "missing critical file: Frameworks/StoreFoundation/CKUpdate.h"
test -f "Frameworks/CommerceKit/CKSoftwareMap.h" \\
  && ok "Frameworks/CommerceKit/CKSoftwareMap.h" \\
  || miss "missing critical file: Frameworks/CommerceKit/CKSoftwareMap.h"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 119 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~89d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/mangerlahn/Latest"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Latest is a native macOS app that monitors installed applications for available updates from two sources: the Mac App Store and Sparkle-based update frameworks. It provides a unified dashboard showing which apps have updates available, displays release notes, and enables one-click updating—solving the problem of manually checking dozens of apps for new versions. Monolithic Xcode project (Latest.xcodeproj) with a two-tiered framework structure: Frameworks/CommerceKit provides commerce operations (downloads, purchases, account management), while Frameworks/StoreFoundation abstracts App Store and Sparkle metadata (products, updates, downloads). The main app (Latest/) contains AppDelegate and a UI hierarchy under Interface/ with separate controllers for the main window, update table view, and release notes display.

macOS users who want visibility into all pending app updates without visiting each app's website or settings. Secondary audience: macOS developers contributing to this community-driven utility who use Sparkle or publish to the App Store.

Production-ready with active maintenance. The project has a CI pipeline (.travis.yml), structured codebase with 228KB of Swift, multiple frameworks abstracted (CommerceKit, StoreFoundation), and a published CHANGELOG. Single maintainer (mangerlahn) working in spare time means updates are periodic but releases are tagged on GitHub. No recent abandonment signals visible.

Single active maintainer creates key-person dependency risk. The app wraps private Apple frameworks (CommerceKit, StoreFoundation) via header imports—these frameworks may change with macOS releases, potentially breaking functionality. No test suite visible in file structure. Submodules (.gitmodules) indicate external dependencies whose update cadence is unknown.

Active localization effort via Weblate (noted in README). Issues section is populated but specific recent commits/PRs are not visible in provided data. The app accepts contributions across code, translations, and feature requests but maintainer manages a sparse merge pace.

git clone --recurse-submodules git@github.com:mangerlahn/Latest.git && open Latest.xcodeproj — then select the Latest scheme and build in Xcode 11+ with Swift 5. Requires Xcode 11 and Swift 5 minimum per README.

Daily commands: In Xcode: select Latest scheme → Product > Run (⌘R). App launches as native macOS app; no CLI or build server needed.

• Latest/AppDelegate.swift — Entry point for the application; initializes the app, manages lifecycle, and sets up the main window.
• Latest/Interface/Main Window/Window Controllers/MainWindowController.swift — Primary controller for the main UI window; orchestrates update detection and display logic.
• Latest/Interface/Main Window/Update Table View/Controller/UpdateTableViewController.swift — Core table view controller managing the list of available updates and user interactions.
• Frameworks/StoreFoundation/CKUpdate.h — Header defining the Update model from Apple's private frameworks; essential for understanding update data structures.
• Frameworks/CommerceKit/CKSoftwareMap.h — Private framework header for mapping software products; critical for app detection and update resolution.
• Latest/Interface/Main Window/Release Notes/ReleaseNotesViewController.swift — Manages display of release notes for selected updates; bridges update data to user-facing content.

Add a new app source or update detection method

1. Create a new detection protocol/class in UpdateTableViewController that conforms to app scanning pattern (Latest/Interface/Main Window/Update Table View/Controller/UpdateTableViewController.swift)
2. Add init method to probe apps in new source (e.g., Homebrew, third-party installer) (Latest/Interface/Main Window/Update Table View/Controller/UpdateTableViewController.swift)
3. Integrate new app source into the main scan loop and update the table data source (Latest/Interface/Main Window/Update Table View/Views/UpdateTableView.swift)

Add a new settings preference

1. Add UI control (checkbox, popup, etc.) to the appropriate settings view controller (Latest/Interface/Settings/General/GeneralSettingsViewController.swift)
2. Wire up the control to read/write UserDefaults or equivalent preference storage (Latest/Interface/Settings/General/GeneralSettingsViewController.swift)
3. Update MainWindowController or UpdateTableViewController to respect the new preference during update detection or display (Latest/Interface/Main Window/Window Controllers/MainWindowController.swift)

Add support for a new release notes format or content type

1. Create a new view controller inheriting from ReleaseNotesContentProtocol pattern (Latest/Interface/Main Window/Release Notes/Controller/ReleaseNotesContentProtocol.swift)
2. Implement custom rendering logic (e.g., Markdown, JSON, custom XML) (Latest/Interface/Main Window/Release Notes/Controller/ReleaseNotesTextViewController.swift)
3. Update ReleaseNotesViewController to detect content type and instantiate appropriate controller (Latest/Interface/Main Window/Release Notes/ReleaseNotesViewController.swift)

Add a new UI element to the update list (e.g., status badge, progress indicator)

1. Create new custom NSView subclass for the UI element (Latest/Interface/Main Window/Update Table View/Views/UpdateItemView.swift)
2. Add the element to UpdateCell layout or create a new specialized cell type (Latest/Interface/Main Window/Update Table View/Views/UpdateCell.swift)
3. Wire data binding in UpdateTableViewController to populate the new element (Latest/Interface/Main Window/Update Table View/Controller/UpdateTableViewController.swift)

• Swift (primary language) — Modern, type-safe macOS development; better than Objective-C for new features and maintainability.
• Cocoa/AppKit (UI framework) — Native macOS UI paradigm; required for NSTableView, NSViewController, and Deep Aqua integration.
• Private frameworks (CommerceKit, StoreFoundation) — Only way to query Mac App Store installed apps and check for updates without public API; unstable but necessary.
• Sparkle (third-party update framework) — De-facto standard for independent macOS app updates; handles secure signed feeds and delta updates.

• Use private Apple frameworks (CommerceKit, StoreFoundation) for MAS app detection

  • Why: No public API exists to enumerate Mac App Store installed apps or their update status.
  • Consequence: Fragile dependency on undocumented APIs; may break with macOS updates; complicates app review and distribution.

• Scan user's Applications folders at runtime instead of maintaining app registry

  • Why: Avoids sync issues; always reflects current filesystem state; no background service overhead.
  • Consequence: Slower on large /Applications folders; cannot detect updates before app is installed; no offline cache of update metadata.

• Build as single-window macOS app rather than multi-window or menu-bar app

  • Why: Simpler UI model; aligns with 'focused utility' positioning; touch-bar support and standard macOS HIG.
  • Consequence: Users must open the app to check for updates; no background monitoring or notifications without additional daemon.

• Rely on app developers to maintain valid Sparkle feeds and MAS listings

  • Why: No authority over third-party update sources; Latest only mirrors what developers publish.
  • Consequence: Cannot fix broken or missing release notes; update checks only as current as feed publishers maintain them.

• Does not automatically install updates in the background; requires user action.
• Does not run as a menu-bar daemon; only works when app is open.
• Does not support Windows or Linux; macOS-only.
• Does not parse or execute arbitrary software; only detects and displays available updates.
• Does not handle system software or OS updates; only third-party apps.
• Does not require authentication or user account; offline-first operation.

Private frameworks: CommerceKit and StoreFoundation are Apple private frameworks accessed via header imports. Xcode or future macOS versions may restrict or change these APIs without warning—no stable SPI contract exists. Sparkle integration details not explicit: how Sparkle app feeds are discovered and monitored is not visible in provided files; likely in extension or plugin mechanism not shown. No CocoaPods/SPM: traditional Xcode project.pbxproj structure; adding dependencies requires manual framework addition. Storyboard-based layout: Main.storyboard is a binary file; merge conflicts in Git are difficult to resolve without Xcode. Localization via Weblate: English strings in code must be extracted and uploaded; missing coordination can cause translation rot.

• Sparkle Framework (App Update Protocol) — Latest's ability to detect non-App-Store updates depends entirely on understanding how Sparkle advertises versions via appcast feeds; knowing this is critical for maintaining Sparkle integration and debugging update detection failures
• Apple Private Frameworks (CommerceKit, StoreFoundation) — Latest wraps undocumented Apple private APIs rather than public frameworks; understanding their stability, typical patterns, and version changes across macOS releases is essential for avoiding breakage
• NSTableView and View Controller Data Sources — UpdateTableViewController.swift uses macOS NSTableView (not SwiftUI) with custom data sources; mastering this older but still-pervasive pattern is necessary to modify the app list display
• Objective-C/Swift Bridging — The codebase mixes Swift and Objective-C (43KB of .h headers); understanding how bridging headers, @objc annotations, and module maps enable interop is critical for extending framework functionality
• macOS App Signing and Sandboxing — Latest accesses the App Store and monitors installed apps, operations that require specific entitlements; understanding code signing and App Sandbox rules (if any) is needed to avoid security/distribution issues
• View Controller Containment and Composition — ReleaseNotesViewController composes multiple child controllers (ReleaseNotesTextViewController, ReleaseNotesLoadingViewController, ReleaseNotesErrorViewController) dynamically; mastering container view controller patterns is essential for extending release notes display
• Protocol-Driven UI (ReleaseNotesContentProtocol) — The release notes module uses a custom protocol to decouple content types from controllers; understanding this abstraction pattern enables adding new release note sources (e.g., GitHub releases, custom HTTP endpoints) without duplicating controller logic

• sparkle-project/Sparkle — The de facto standard for macOS app updates outside the App Store; Latest integrates with Sparkle feeds to detect available versions
• mas-cli/mas — Command-line tool for Mac App Store operations; provides complementary CLI interface to the same underlying App Store frameworks Latest uses
• homebrew-cask/homebrew-cask — Package manager used to distribute Latest; repository where Latest appears as an installable formula
• macadmins/nudge — Enterprise macOS update enforcement tool; similar problem space (tracking app updates) but targets organizational deployment rather than personal use
• SwiftPackageIndex/SwiftPackageIndex-Server — Metadata aggregator for Swift packages; demonstrates patterns for indexing and monitoring external dependency updates similar to Latest's multi-source approach

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for Sparkle update detection in StoreFoundation framework

The repo currently has no visible test suite despite handling two critical update sources: Mac App Store (via CommerceKit) and Sparkle updates (via StoreFoundation). The Frameworks/StoreFoundation directory contains core update detection logic (CKUpdate.h, SSDownloadStatus.h, SSDownloadMetadata.h) that lacks test coverage. This is high-value because update detection is the core functionality and regressions here directly impact users.

• [ ] Create Tests/ directory structure with StoreFoundationTests target
• [ ] Add unit tests for SSDownload.h and SSDownloadStatus.h state transitions
• [ ] Add unit tests for CKUpdate.h parsing and version comparison logic
• [ ] Add integration tests for mock Sparkle feed parsing in Frameworks/StoreFoundation/
• [ ] Reference Latest.xcodeproj/project.pbxproj to add new test target

Add GitHub Actions CI workflow for building and code signing verification

The repo uses .travis.yml (deprecated service) but macOS app building requires specific signing certificates and provisioning profiles. A modern GitHub Actions workflow would verify that Latest builds without errors on every PR, catching regressions early. This is specific because the xcodebuild command for Latest.xcodeproj needs macOS runners and app signing validation.

• [ ] Create .github/workflows/build.yml with macos-latest runner
• [ ] Add xcodebuild step to build Latest.xcodeproj for Release configuration
• [ ] Add code signing verification step (xcodebuild -showBuildSettings to validate signing identity)
• [ ] Add step to verify framework imports work correctly (build both CommerceKit and StoreFoundation)
• [ ] Remove or archive outdated .travis.yml file

Add comprehensive documentation for CommerceKit and StoreFoundation framework usage

The Frameworks/CommerceKit/ and Frameworks/StoreFoundation/ directories contain private Apple framework headers (CKDownloadQueue.h, ISServiceProxy.h, SSPurchase.h) but there is no documentation explaining how these are used. New contributors cannot understand the update detection flow. This is valuable because AppDelegate.swift and UpdateTableViewController.swift depend on these frameworks but their integration is opaque.

• [ ] Create Frameworks/FRAMEWORK_GUIDE.md explaining CKDownloadQueue lifecycle and SSDownload state machine
• [ ] Document how CommerceKit.CKAccountStore integrates with ISStoreAccount for authentication
• [ ] Add architecture diagram in README showing data flow: App → CommerceKit → CKDownloadQueue → UpdateTableViewController
• [ ] Document the purpose of module.modulemap files in both frameworks and why private headers are bridged
• [ ] Add example code snippets showing how to query app updates via CKSoftwareMap and CKUpdate

• Add unit tests for ReleaseNotesTextViewController.swift to verify HTML/text parsing and rendering—currently no test files visible in structure, making regression detection difficult.
• Improve search UX in UpdateTableView+Search.swift by adding unit tests for edge cases (special characters, empty results, rapid successive searches) and documenting the search algorithm.
• Document the CommerceKit and StoreFoundation framework APIs (function signatures, usage examples) in a CONTRIBUTING.md or Wiki page—currently only headers are visible, making onboarding harder for contributors unfamiliar with Apple private frameworks.

Latest is a relatively well-structured macOS application with moderate security concerns. The primary risks stem from: (1) dependency on private Apple frameworks which are undocumented and subject to change, (2) potential network communication vulnerabilities related to App Store API interactions, and (3) insufficient input validation for displaying external content (release notes). The codebase lacks visible automated security scanning in its CI/CD pipeline. The application does not appear to handle sensitive credentials or contain SQL injection risks. Recommendations include migrating to public APIs, implementing certificate pinning, adding input validation, and enhancing the security testing strategy.

• Medium · Use of Private/Undocumented Frameworks — Frameworks/CommerceKit/, Frameworks/StoreFoundation/. The codebase imports and uses private Apple frameworks (CommerceKit and StoreFoundation) that are not part of the public SDK. These frameworks are subject to change without notice and their use may violate App Store guidelines. This creates maintenance risk and potential security vulnerabilities if Apple changes internal APIs. Fix: Migrate to public APIs such as StoreKit 2.0 or use officially documented App Store frameworks. If private framework usage is necessary, implement abstraction layers and regular security audits.
• Medium · Potential Insecure Network Communication — Frameworks/StoreFoundation/ISServiceProxy.h, Frameworks/CommerceKit/. The app uses StoreFoundation and CommerceKit frameworks which handle network requests to Apple's servers. Without visible implementation details, there is a risk of insecure SSL/TLS configuration, lack of certificate pinning, or man-in-the-middle vulnerabilities if the frameworks are not properly configured. Fix: Implement certificate pinning for all network communications. Verify SSL/TLS configuration is set to require TLS 1.2 or higher. Conduct security audit of network communication implementation.
• Medium · Lack of Input Validation in Release Notes Display — Latest/Interface/Main Window/Release Notes/Controller/ReleaseNotesTextViewController.swift, Latest/Interface/Main Window/Release Notes/ReleaseNotesViewController.swift. The ReleaseNotesViewController and related components display user-generated content (release notes) from external sources. Without proper sanitization, this could be vulnerable to XSS-like attacks if the content is rendered as HTML/web content. Fix: Implement strict input validation and content sanitization for all release notes. If displaying web content, use WKWebView with disabled JavaScript execution and validate all content sources.
• Low · No Visible Security Headers or Configuration — .travis.yml. The .travis.yml file indicates CI/CD pipeline usage, but no visible security scanning tools (SAST, dependency scanning) are configured in the build process. Fix: Add automated security scanning to the CI/CD pipeline using tools like SonarQube, Dependabot, or Apple's security tools. Implement regular security dependency checks.
• Low · Missing Code Signing and Notarization Verification — Latest.xcodeproj/. While this is a macOS app, there is no visible evidence of code signing certificates or notarization in the provided file structure. This could affect distribution security. Fix: Ensure proper code signing with Apple Developer certificates and implement macOS notarization. Document the signing and notarization process in README or build configuration.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.