No centralized cache
iMessage has no server-side cache to invalidate. Each sender’s device fetches your page independently and generates its own preview. Two people sharing the same link might see different previews if your page changed between their shares.
Compare this with Facebook (server-side cache, ~30-day TTL) or Twitter (~7 days). With iMessage, there’s no single cache to clear.
No official debugger
Apple provides no link preview debugger. There’s no equivalent to Facebook’s Sharing Debugger or Twitter’s Card Validator. The only way to see your preview is to send an actual iMessage (or use a third-party tool like OpenGraph+).
Device-level caching
Individual devices cache preview data locally, but Apple doesn’t document the behavior. If someone shares a link twice, the device may reuse the first preview instead of re-fetching.
The cache duration seems influenced by standard HTTP cache headers (Cache-Control, Expires, ETag, Last-Modified):
Cache-Control: max-age=3600
Workarounds for stale previews
Change the URL
Append a query parameter to bust the cache:
https://example.com/page?v=2
iMessage caches by exact URL, so this forces a fresh fetch. Previously shared links keep their old preview.
Use short cache headers
Short Cache-Control values reduce the staleness window for future shares. Won’t help with already-cached previews.
Toggle iMessage (end user workaround)
If someone keeps seeing a stale preview:
- Go to Settings > Messages and toggle iMessage off
- Wait a few seconds, toggle it back on
- Delete the conversation thread with the stale link
- Re-send the link
Results aren’t guaranteed, but it’s the best option available to end users.
Implications for developers
- Test by actually sending messages in the Messages app
- Use short cache headers during development
- Expect eventual consistency – different users may see different previews
- Avoid changing OG tags on existing URLs when possible, since you can’t force-invalidate