Apple FindMy app shows stale item locations for paired accessories while the fetchReports lane serves fresh reports for the same keys

[LtSalt]

Apple FindMy app shows stale item locations while the fetchReports lane serves fresh reports for the same accessories

Summary

Over the past week, three paired FindMy accessories of ours kept displaying stale item locations in the official Apple FindMy app (iOS and macOS), while the anonymous hash-key report lane consistently serves up-to-date reports for exactly these accessories' rolling keys. The divergence is per-item, and it is not data loss — the fresh reports are on Apple's servers right now, decrypt fine, and two independent reading clients under two different accounts see the same fresh set.

Setup (anonymized)

• Owner Apple account; all items paired and fully working in the app historically.
• Three accessories involved:
  • Item A — a certified third-party wallet-card tracker, paired for about a month.
  • Item B — the same model, paired more recently.
  • Item C — a second-generation AirTag, paired for a couple of months.
• Reading clients we can compare against:
  • OpenTagViewer (Android app, iCloud-connect route) — shows fresh positions for the items where the official app shows stale ones.
  • Our own FindMy.py-based poller, running under a different Apple account than the owner's — also sees identical fresh reports (so this is not an account/session-specific problem).

What we observe

• Item A: the app (iOS and macOS) has shown the same "last week" position for days. The fetchReports lane serves ~40 fresh reports over the last 25 hours, at roughly 5-minute sighting cadence, for this item's current key slots.
• Item B: similar staleness. Interesting sub-case: this accessory was power-cycled at some point, and afterwards its advertising key usage moved one whole secondary-key block (+96 primary key slots) further in the key space — Apple's documented reboot behaviour, as modelled in FindMy.py's _secondary_keys_at (+1/+2 candidates). Our client re-aligned and fetches fresh reports again through the raw lane. Notably, the App's item display was already stale before that event, and stayed stale after we re-aligned — so the block jump alone does not explain the App-side divergence.
• Item C: app shows a position labelled "yesterday"; the raw lane serves sightings from that same morning.
• On the macOS Find My app, each of these items additionally appears three to four times in the Items sidebar with identical metadata; some duplicates flicker away after re-sync. The iOS app shows the same stale locations but never duplicates — suggesting the duplication is a macOS client cache artifact, while the stale display is upstream.
• "Play Sound" is greyed out for all three, which is consistent with the accessories being far from any of the owner's Apple devices (BLE-proximity design, per Apple's docs). We mention it only because it started in the same time frame.

What we ruled out

• Data loss: the fresh reports exist server-side, decrypt fine, and two unrelated sessions (owner account + an unrelated account) retrieve identical fresh results. Not a rate-limit or session problem: our polling volume is small (hourly cadence, under the documented key caps).
• macOS cache only: iOS shows the same stale locations, so the App-lane staleness is not merely the Mac's local cache (that cache only explains the duplicate rendering).
• Narrow fetch windows: sweeping a window far wider than the default search range (roughly ±3 days of key indices, plus extra slots beyond the "at most one roll per 15 minutes" cap) still returns the fresh reports under their correct current keys — the keys we ask and the keys the accessories currently advertise match.

Questions

• Has anyone else observed the paired-item pipeline lag days behind the fetchReports lane for individual items?
• Is there a known relationship between Apple's per-item display state and (a) secondary-key block transitions after power cycles, or (b) key-schedule drift? Our hypothesis: Apple's per-item key-slot bookkeeping may stall, detaching the raw report store from the item display pipeline — reports land in the store, but the item's "last known location" stops advancing.
• Could the item display simply be serving a cached "last solved position" that macOS additionally renders with duplicate client-side entries?

Sanitized details (versions, timelines, key-index/bookkeeping evidence) available on request. We are filing this here because of the shared fetching stack — the finding may be useful to anyone tracking paired accessories with FindMy-based clients next to the official app.

[parawanderer]

OpenTagViewer and FindMy.py read the same per-key report store that Apple's app should be reading, and you're getting fresh results through it, so this is a staleness problem inside Apple's Find My app rather than in this stack. All three of your items appear to be away from the owner's devices, and I've seen the same thing with a tag of mine that is in that situation. My working assumption is that Apple's app holds back location updates for trackers separated from their owner, as part of its anti-stalking measures. That is unconfirmed: Apple doesn't document it. The +96 shift after a power cycle is the expected secondary-key behaviour and is already handled. Nothing on this side can change what Apple's app displays, so I've moved this to Discussions. If OpenTagViewer itself ever shows stale or missing locations for these items, please open an issue with the app version and a log.

Interactively co-authored by Claude Code and @parawanderer

[jondeniegajr]

Login failed: InvalidCredentialsError: Email verification failed: This action cannot be completed at this time.