Apple Intelligence is quietly overwriting your Customer.io preheader: what the AI summary actually reads, and three Liquid patterns that steer it
On 11 December 2024, Apple shipped iOS 18.2. That was the release that put Apple Intelligence on iPhones in earnest, alongside Image Playground, Genmoji, Siri's ChatGPT integration, and quietly, inside the Mail app, AI-generated message summaries that appear in the inbox under the subject line (Apple Newsroom, 11 December 2024). Eighteen months on, the feature has spread across iPhone 15 Pro and iPhone 16 households, and for any marketer running a Customer.io programme to a consumer or B2B audience with significant Apple Mail share, the preheader has become a smaller surface than it used to be.
The shift is subtle enough that most teams haven't noticed. The preheader still ships. It still loads. It still does its job for Gmail users and for recipients on older Apple devices. But for the slice of your audience using Apple Intelligence with the summary toggle on, what they see in the inbox preview isn't your preheader at all. It's a sentence Apple's on-device model wrote from the body of your email. This post covers what the AI summariser actually reads, how the problem differs from Mail Privacy Protection, and three Liquid patterns in Customer.io that let you steer the summary by segment.
What changed on 11 December 2024, and why the preheader is now a smaller surface
Apple's iOS 18.2 release introduced AI-generated message summaries in the Mail app, displayed in the inbox list under the subject line. With the user's "Summarize Message Previews" setting turned on, that summary replaces what marketers have spent twenty years treating as the canonical inbox preview line: the preheader (Stripo, 10 February 2026).
The feature is not universal. At launch, Apple Intelligence ran only on the iPhone 15 Pro, iPhone 15 Pro Max, and the iPhone 16 lineup, with macOS support gated to M-series Macs (NGP VAN, October 2024). With a three-year smartphone replacement cycle, roughly half of all Apple Mail opens by 2026 are on AI-eligible hardware, and that share grows every quarter. The other half still see your preheader.
Two things follow from this. First, you can't ignore the AI summary as a fringe case. Apple Mail and Gmail together account for almost 90% of tracked email opens (Litmus Email Client Market Share, 2026), and Apple alone runs at around 45%. Second, the fix isn't to abandon the preheader. Gmail still uses it. Older Apple devices still use it. Recipients who've left the summary toggle off still use it. The fix is to stop treating the preheader as the only inbox preview surface.
How Apple's AI summary actually picks what to show
The summary is written from the body of the email, not the preheader and not the subject line. Apple Intelligence runs the model on-device, reads the rendered text content, and produces a short line that prioritises what looks like the email's key information. Storytelling intros tend to get collapsed into something plain. Front-loaded value tends to get preserved (Stripo, 20 May 2025).
In practice, the first 200 to 300 characters of body copy do most of the work. If your opening paragraph reads "Hi Sarah, hope your week is going well, I wanted to write today because we've got something we think you'll love...", that's what the AI has to summarise. The output will be flat, because the input is flat. If your opening paragraph reads "Your 25% off code expires Sunday. Use ROCKET25 at checkout.", you're handing the AI something extractable, and you'll often get an inbox preview that mentions the discount and the deadline.
This isn't a writing trick. It's a structural change to where the most important sentence in your email lives. The most important sentence used to be the preheader. For half your Apple audience, it now needs to be the first line of body copy.
How this differs from Apple Mail Privacy Protection
Mail Privacy Protection and the AI summary are two separate problems with two separate fixes. MPP pre-fetches your tracking pixel and inflates your open rate. The AI summary rewrites what shows up in the inbox preview. Different layer of the stack, different surface, different remediation.
If you haven't already fixed your behaviour triggers (the ones that branch on email_opened for a journey decision), that's a different post: Apple Mail Privacy Protection has quietly broken your day-2 onboarding trigger walks through the migration to Customer.io's Human Opened and Human Clicked metrics. This post is about the inbox preview, which sits one step earlier in the funnel. A subscriber decides whether to open based on what the preview shows. If MPP has broken your trigger logic on the back end, the AI summary is breaking the persuasion layer on the front end.
You need both fixes. They don't substitute for each other.
What's still safe: Gmail, older Apple devices, recipients with summaries off
Gmail still uses your preheader as the inbox preview line. Gmail's AI summaries, generated by Gemini, appear after the email is opened: in the Gemini sidebar, in search results, sometimes inside the message view. They don't replace the preview line in the inbox list. So for the roughly 24% of opens that come from Gmail clients, your preheader still does the job it always did (Litmus Email Client Market Share, 2026).
On the Apple side, Apple Intelligence summaries are gated on three things: a supported device (iPhone 15 Pro and Pro Max, iPhone 16 lineup, M-series Macs at launch), a supported region and language, and the user having toggled "Summarize Message Previews" on. Apple shipped the feature defaulted off, with a discoverable toggle and an explicit warning that the summaries can be inaccurate (MarTech, 28 January 2026). For users where any of those conditions is missing, your preheader still shows the way it always did.
What this means in practice: don't abandon the preheader. Set it as you always have. Use it for the Gmail and non-AI-eligible Apple share. Then engineer the body's opening line as a second preview surface for everyone else.
Customer.io fix #1: write the body's opening line as a preheader
Write the first sentence of the body so it could serve as the preheader on its own. This is the smallest change and it works on every email you send. Offer first. Deadline first. Action first. The preheader still ships unchanged, but the body's first sentence is now doing double duty for the AI summary.
A worked example. A renewal-reminder email, before:
Subject: Your monthly statement is ready
Preheader: Save up to £200 on your renewal this month
Body opens: Hi Sarah, just a quick note to let you know that your monthly statement for April is now available in your dashboard. While you're there, you might also want to check out our renewal options...
And after:
Subject: Your monthly statement is ready
Preheader: Save up to £200 on your renewal this month
Body opens: Save up to £200 on your renewal. Your April statement is ready and your renewal window is open until 15 May.
The preheader hasn't changed. Gmail users see "Save up to £200..." the way they always did. Apple users on supported devices now see an AI summary that has the renewal offer in it, because the body's first sentence handed the model something to extract. The greeting and the warmth still belong in the email; they just live in the second paragraph now.
Customer.io's preheader field is unchanged by all of this. You configure it the same way: in the campaign editor under the message-level settings (Customer.io docs: Custom preheader text). The only thing that's different is what you put in the body's opening line.
Customer.io fix #2: three Liquid patterns to steer the summary by segment
If you've used Customer.io Liquid for personalisation, you already know the syntax. These three patterns use it to write different opening sentences for different segments, so the Apple-Mail-share audience sees a body opener crafted for AI extraction while the rest of your list sees something warmer.
Pattern A: a body opener crafted for the Apple-Mail-share segment
Use Liquid to branch the opening paragraph on the recipient's email client. If you populate an email_client attribute on the profile (typically via a delivery webhook or a reverse-ETL pipeline from your warehouse), the conditional is direct:
{% if customer.email_client contains "Apple" %}
Save up to £200 on your renewal. Your April statement is ready and your renewal window is open until 15 May.
{% else %}
Hi {{customer.first_name}}, your April statement is ready. We've also flagged a renewal offer worth up to £200 if you act before 15 May.
{% endif %}
The Apple branch front-loads the offer for the AI summariser. The non-Apple branch can open warmly because the preheader is doing the offer-leading work for Gmail and older Apple recipients.
Customer.io doesn't ship the email_client attribute by default. You'll need to populate it yourself, either from delivery webhooks (which report the client when known) or from your warehouse data. If you don't have it, use Pattern B instead.
Pattern B: branch on behavioural signals when you don't have client data
If email_client isn't on your profiles, behavioural signals make a reasonable proxy. Customers who've recently clicked from an iPhone are likely to be on Apple Mail. Customers whose last device platform was iOS are likely on an iPhone. Either gives you a workable conditional:
{% if customer.last_click_device == "iphone" or customer.platform contains "iOS" %}
Save up to £200 on your renewal. Your April statement is ready and your renewal window is open until 15 May.
{% else %}
Hi {{customer.first_name}}, your April statement is ready. We've also flagged a renewal offer worth up to £200 if you act before 15 May.
{% endif %}
One warning. Customer.io Liquid will silently break the moment any of these attributes is null on a recipient. Always include an {% else %} branch and never assume the attribute exists. The QA recipe in that anti-patterns post catches this exact failure mode before launch.
Pattern C: A/B test the first-paragraph CTA placement, measured on click-through
You can't read the AI summary back from Customer.io's analytics. Apple doesn't tell you what the model generated, and no email service provider has visibility into it either. So measure the next signal along instead: click-through rate, not open rate.
Set up a two-variant A/B test in Customer.io using its built-in A/B test feature (Customer.io docs: A/B testing):
- Variant A: standard opening paragraph (greeting, context, then the offer)
- Variant B: front-loaded CTA opening paragraph (offer first, context second)
Run it against your Apple-Mail-share segment. Measure on click-through rate over 72 hours. Open rate is noise in 2026 (more on that below), so the A/B test report you care about is the click side. A/B test it properly by sizing the test for statistical significance before declaring a winner.
Customer.io fix #3: stop reporting open rate as a single number
This is the lifecycle marketing scorecard argument, reframed for the AI-summary era. Open rate is now noise twice over. Mail Privacy Protection inflates it on the technical side, with roughly half of all reported opens in 2026 attributable to MPP pre-fetched pixel loads (Digital Applied Email Deliverability Benchmarks 2026). And Apple Intelligence summaries reshape it on the persuasion side, because the line that determines whether a recipient opens is no longer the one you wrote.
Build the scorecard around what you can actually measure: click rate, click-to-open rate using Human Opened as the denominator, and downstream conversion or revenue. That's the part of the funnel you still own. Open rate as a single headline number is misleading in both directions, and senior stakeholders making investment decisions on it are reading bad data.
What you cannot influence
Three things sit outside your control no matter how you write the email.
The user toggle is theirs, not yours. If a recipient has "Summarize Message Previews" off, they see your preheader. If they have it on, they see the AI summary. You can't detect which state they're in, and Apple has no public API for marketers to query it.
Apple's accuracy warning is real. Apple itself tells users the summaries can be inaccurate, and there are documented cases of the AI inverting the meaning of a message or surfacing a marginal line as the headline. That's a feature limitation, not a marketer problem. You can reduce the risk by writing a clear first sentence, but you cannot eliminate it.
Receipts and transactional layouts still get summarised. Apple Intelligence doesn't carve out an exemption for order confirmations, shipping updates, or password resets. If you're using Customer.io for transactional sends, the AI will write a summary of the receipt regardless of how you phrase it. The fix is the same as for marketing sends: front-load the most useful piece of information (the order number, the dispatch date, the reset link confirmation) in the first sentence of the body.
A 30-minute audit to put this into practice today
Three steps. Half an hour, end to end.
First, build the Apple-Mail-share segment in Customer.io. Build the Apple-Mail-share segment using either the email_client attribute if you have it, or behavioural proxies like last_click_device if you don't. Customer.io's data-driven segments will keep it updated automatically (Customer.io docs: Segments).
Second, pull your five most-sent campaign emails. Open each one and read the first 200 characters of the body. Ask one question: if you had to write a one-line summary of this email using only those 200 characters, would the line be useful to the recipient?
Third, pick the worst offender. Rewrite its opening sentence to front-load the offer or the action. Leave the preheader alone. Send the new version once to your Apple-Mail-share segment, send the original to the rest of the list, and compare click-through rate over the next 72 hours. That's the smallest viable experiment, and it'll tell you whether the rewrite is worth doing at scale.
Two sends, one rewrite, real measurement. Then repeat across the next four templates.
Frequently asked questions
Does Apple Intelligence read the preheader at all?
No, not by default. The AI summary is generated from the body content of the email. The preheader is a meta-level field that lives outside the body, and Apple Intelligence doesn't treat it as the source for the summary. If your preheader text also appears at the top of the body (which some templates do as a fallback), then yes, the AI will see it there. But the preheader field itself isn't what the summariser is reading.
Will my Customer.io preheader still show on Gmail?
Yes. Gmail uses your preheader as the inbox preview line the same way it always has. Gmail's own AI summaries, powered by Gemini, appear after the recipient opens the email, not in the inbox list. So if a significant share of your audience is on Gmail, your preheader is still doing real work. Don't strip it out.
Can I detect whether a recipient has Apple Intelligence summaries turned on?
No. Apple has no public API or signal that tells senders whether an individual recipient has the "Summarize Message Previews" toggle on or off. The best you can do is segment by likelihood: recipients on iPhone 15 Pro or iPhone 16 hardware are eligible, and a fraction of those will have the toggle enabled. Treat it as a probability across the segment, not a per-recipient flag.
Should I stop writing preheaders altogether?
No. Gmail still uses preheaders. Older Apple devices still use preheaders. Recipients with the AI summary toggle off still see preheaders. Roughly half of all email opens still depend on the preheader for the inbox preview. The change isn't to abandon it but to add a second surface (the first sentence of body copy) that handles the AI-summary share.
Does Apple's AI summary use the subject line?
No. The subject line shows above the summary in the inbox list, the way it always has. The summary is generated from the body of the email, not from the subject. You still need a strong subject line, because it sits next to the summary in the preview and both contribute to the open decision.
How accurate are Apple Mail's AI summaries?
Apple itself warns users that the summaries can be inaccurate, and there are documented cases of the model inverting meaning or surfacing a non-load-bearing line as the headline. Accuracy is generally reasonable for short, structured emails (receipts, single-CTA promos) and degrades for long, narrative-style messages. The fix is to write a clear first sentence so the AI has less room to misinterpret.
Will Apple Intelligence summaries affect deliverability or just preview text?
Just preview text. Apple Intelligence doesn't influence whether an email lands in the inbox, the Promotions tab, or the spam folder. Deliverability is governed by authentication (SPF, DKIM, DMARC), sender reputation, engagement signals, and compliance with bulk-sender requirements from Gmail and Yahoo. The AI summary affects whether a recipient opens once the email has been delivered, not whether it gets delivered.
Which iPhones support Apple Intelligence summaries?
At launch, Apple Intelligence ran on the iPhone 15 Pro, iPhone 15 Pro Max, and all iPhone 16 models. Older iPhones (including the standard iPhone 15 and earlier) do not support it. On the Mac side, M-series chips are required. As of mid-2026, the eligible install base covers roughly half of all Apple Mail opens, with the share rising each quarter as devices are replaced.
Does Apple Intelligence rewrite transactional emails too?
Yes. The summary feature applies across all incoming mail by default when the user has the toggle on, including order confirmations, shipping notifications, password resets, and account alerts. Apple makes no exception for transactional content. The same fix applies: write the first sentence of the body so the most useful information is front and centre.
Is there a way to opt my emails out of being summarised?
No. There's no sender-side flag, header, or markup that excludes an email from Apple Intelligence summarisation. The toggle is entirely controlled by the recipient. If you don't want your email summarised, the only option is to write content that summarises well anyway.
Does the AI summary use my image alt text?
Apple hasn't published technical details on which body elements the on-device model reads, but the consensus in the email marketing community is that text content drives the summary far more than image alt text. Live text in the body is what the summariser preferentially extracts. If your email is image-heavy with minimal live text, you'll get worse, less predictable summaries. Use live text in the opening of every email.
What's the difference between Apple Mail Privacy Protection and Apple Intelligence summaries?
Two separate features at two different points in the email lifecycle. Mail Privacy Protection (shipped September 2021) pre-fetches your tracking pixel through an Apple proxy, which inflates your open rate and masks IP addresses. Apple Intelligence summaries (shipped December 2024) rewrite the inbox preview line for users with the toggle on. MPP affects measurement; Apple Intelligence affects persuasion. The fixes are different. The article above covers the Apple Intelligence fix; the Apple Mail Privacy Protection post covers the MPP fix.
Sources
- iOS 18.2 launches today: Here are all the new features. Apple Newsroom, 11 December 2024.
- How marketers can influence AI summaries in Gmail and Apple Mail. Oleksii Burlakov, Stripo, 10 February 2026.
- AI summaries in email clients: What Gmail and Apple Mail changes mean for marketers. Oleksii Burlakov, Stripo, 20 May 2025.
- What Apple and Google's 2025 updates mean for email and SMS in 2026. Brian McKenna, MarTech, 28 January 2026.
- Apple Intelligence: what it means for your email program. NGP VAN, October 2024.
- Email Client Market Share: Trends & Statistics 2026. Litmus, 2026.
- Email Deliverability Benchmarks 2026: Industry Report. Digital Applied, 8 April 2026.
- Custom preheader text. Customer.io documentation.
- A/B testing campaigns. Customer.io documentation.
- Segments. Customer.io documentation.


