Replay 0.9.5

Download

Replay-0.9.5.zip — unzip it and drag Replay.app to Applications.

Running 0.9.3 or newer already? Settings ▸ About ▸ Check for updates will offer this one and
install it for you, checking it against the SHA-256 published beside the zip. A Homebrew copy
is left to brew upgrade, as it should be.

macOS will refuse to open it the first time. Here is why, and what to do.

Replay has no Apple Developer ID yet, so macOS marks it as unverified and shows
"Apple could not verify Replay is free of malware" — offering only Move to
Trash or Cancel. That message is about a missing certificate, not about
anything found in the app. Every unsigned app gets it.

To open it:

1. Try to open Replay once and dismiss the warning.
2. Go to System Settings ▸ Privacy & Security, scroll down, click Open Anyway.
3. Confirm. It opens normally from then on.

Or one line in a terminal, which does the same thing:

xattr -dr com.apple.quarantine /Applications/Replay.app

Right-click ▸ Open does not work. That bypass existed for years and Apple
removed it in macOS 15. It is still the advice in most projects' READMEs.

Or skip all of that

Homebrew compiles it on your machine, so it is never downloaded, never quarantined,
and opens with no warning at all:

brew tap nurkamol/tap
brew install nurkamol/tap/replay-app    # the application
brew install nurkamol/tap/replay        # the command-line reader

A signed, notarised disk image — no warnings, nothing to click through — appears
here the day there is a certificate. The workflow that builds it is already written.

---

The update check spending its own attempts badly, and one claim measured rather than
believed.

Fixed

• A refused check counted as the day's check. The "last checked" stamp was written the
  moment a reply arrived, whatever it said — so a rate-limited attempt recorded a check and
  the next one was 24 hours away, while an attempt that failed because the Mac was offline
  threw before the stamp and retried freely. Backwards in both directions: the failure that
  clears within the hour burned the day, and the one that might last all day did not. Only a
  200 or a 304 counts now.

Added

• It says when the limit clears. GitHub names the moment in x-ratelimit-reset; the
  message reads "It clears at 6:05 AM" rather than "try again later", and the daily check will
  not ask again before then — an attempt inside a window GitHub has already closed can only be
  refused, and spends one of the sixty an hour that were the problem.
• The check asks a smaller question. It sends If-None-Match with the tag from the last
  answer, so a day when nothing has changed comes back as an empty 304 rather than a release
  it already had. The release it did have is kept between launches, so that empty reply is
  still a complete answer.

Measured, and it went the other way

A 304 does not save rate limit on this endpoint. GitHub documents conditional requests
as exempt, and that is written for authenticated ones — on the unauthenticated per-IP cap
this app uses, three requests decremented the counter three times whether they answered 304
or 200. The table is in docs/FINDINGS.md. If-None-Match stays for the
two reasons that survived measurement, bytes and clarity, and this entry exists because the
first draft of it claimed the saving.