Links and previews on iOS

The one rule that matters most

No link in a first message to a new contact. It reduces reply rates, increases reports, and is the most common self-inflicted cause of a degraded line. Send the link after they reply, when it answers a question they asked. Everything below applies to messages after that point.

When iOS shows a rich preview

A rich preview, meaning the card with title, description, and image instead of a bare URL, depends on conditions on the recipient's device, not on anything the API sends. In practice the preview renders when:

1. The thread is established. Previews are much more likely once the recipient has replied at least once.
2. The sender is known. A saved contact gets previews that an unknown number does not, which is another argument for the contact-card flow in sender identity.
3. The URL sits on its own. A link at the very start or very end of a message previews more reliably than one buried mid-sentence.
4. There is exactly one URL. Multiple links in one message usually collapse to plain text.
5. The destination serves Open Graph tags and responds quickly to the fetch.

You cannot force a preview and you should not build a flow that depends on one. Write the message so it works with a bare URL, and treat the preview as a bonus.

Make the destination preview-ready

If you want the card to render well when it does render, the destination page needs og:title, og:description, and og:image set, an image around 1200 by 630 pixels, a fast first response, and no interstitial or redirect chain in front of it. Redirects through a tracking domain are the most common reason a preview fails on a page that otherwise has correct tags.

Use your own domain

Do not use public URL shorteners. Bit.ly-style domains are strongly associated with unwanted messaging, they suppress previews, and they give the recipient nothing to verify before tapping. A link on your own domain, ideally one that matches the company name in your message, does the opposite on all three counts. If you need click tracking, run it on a subdomain you own.

Deep links

A link into an app opens that app directly when the app is installed. Two shapes work:

Universal links, meaning normal HTTPS URLs on a domain that publishes an apple-app-site-association file, open the app when installed and the web page when not. This is the shape to use: it degrades gracefully.

Custom URL schemes, like yourapp://path, open the app but fail with an error when the app is not installed, and are not clickable in some contexts. Avoid them in outbound messages.

Common destinations that behave well in a thread: a calendar booking page, a payment link, a map link, a tel: number, and a mailto: address. Calendar and payment links in particular convert well as the second or third message, after the conversation has established what the link is for.

Tracking without breaking things

Query parameters survive fine, so UTM tags work. Two constraints: keep the URL short enough to stay readable in a bubble, and never put personal data in the query string, since the URL is visible in the thread and in any screenshot the recipient takes or forwards.

Testing before a campaign

Send the exact message to a device in an established thread and a second device that has never received from the line. Check whether it previews, whether the URL is tappable, and how the message reads if the preview does not render. The second case is the one that ships.