On-device preview generation

iMessage generates link previews on the sender’s device, not on Apple’s servers. When someone pastes a URL, their iPhone or Mac fetches the page, parses it, and bakes the preview into the outgoing message.

The HTTP request comes from the sender’s residential IP, not an Apple datacenter. In your server logs, iMessage fetches look indistinguishable from normal browser traffic.

The spoofed user agent

Here’s the strange part. iMessage sends this user agent string:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/601.2.4 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.4 facebookexternalhit/1.1 Facebot Twitterbot/1.0

It claims to be Safari, Facebook’s crawler, and Twitter’s crawler all at once. Apple does this so servers that already serve OG tags for Facebook/Twitter will also serve them to iMessage. The same Mac-identifying user agent is sent even when the message originates from an iPhone.

Applebot is not iMessage

Applebot is Apple’s crawler for Spotlight and Siri. It has zero connection to iMessage previews. The iMessage fetcher uses the spoofed user agent above and never identifies as Applebot, so robots.txt rules targeting Applebot have no effect on link previews.

No JavaScript execution

The preview fetcher does not execute JavaScript. OG tags must be in the initial HTML response. If your SPA renders meta tags client-side, iMessage will see nothing – you need server-side rendering or pre-rendering.

Testing what iMessage sees

Simulate the fetch with curl:

curl -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/601.2.4 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.4 facebookexternalhit/1.1 Facebot Twitterbot/1.0" https://example.com/your-page

If your server varies content by user agent, iMessage gets whatever you send to this string. Some detection logic will misidentify it as Facebook’s crawler.