Customer.io Added Dark Mode to In-App Messages. It's the Opposite of Email Dark Mode

Q: What happens if my app has its own dark-mode toggle?

The message follows the system colour scheme—prefers-color-scheme on web, the device appearance on mobile—not your app's internal theme toggle. If a user sets your app to dark while their device stays in light, the message renders in light mode inside your dark UI. Customer.io's docs describe what the message follows, the system preference, not your app's own state, so design for the two diverging.

ByDavid Crowther·Published28 July 2026·Updated3 August 2026

Customer.io Added Dark Mode to In-App Messages. It's the Opposite of Email Dark Mode

In February 2009, Michael and Lorna Herf released f.lux, a small program that did one thing. As the sun went down where you lived, it warmed the colour of your screen, then cooled it back to daylight in the morning. The idea underneath was quietly radical at the time: the same screen shouldn't show the same colours all day. What looks right at noon is too bright at midnight.

Seventeen years later, that idea is a switch in every operating system. iOS, Android, macOS and Windows all ship a system-wide dark mode, and a lot of people leave it on. In an Android Authority reader poll published on 29 June 2026, 2,280 of 3,110 votes went to always-on dark mode—nearly three in four. That's a self-selected, enthusiast crowd, so treat it as a ceiling rather than an average. Even discounted, the direction is hard to miss.

On 7 July 2026, Customer.io brought that switch to in-app messages. You can now set separate dark-mode colours for a message and let it follow the reader's system preference. This post covers how that works, why it's the opposite of email dark mode, and the one setup step that quietly decides whether any of it shows up on your website.

This is not email dark mode

Start with the thing most teams get backwards. In-app dark mode is the opposite of email dark mode.

In email, dark mode happens to you. Gmail and Outlook decide a message should be dark and force-invert colours you never chose, which is how a crisp logo turns into a glowing box. We covered that trap in forced dark mode inverting your Customer.io email colours, and the fix there is mostly damage control, because you're reacting to a mail client's decision.

In-app, nothing gets inverted. You set the dark values yourself, on purpose, and the message uses them when the reader's device is in dark mode. Customer.io's release note puts it plainly: you set separate dark-mode values for colour properties like fills, text and borders, and the message respects the audience's system preferences. Anywhere you don't set a dark value, the light value applies in both modes. No inversion algorithm second-guessing your palette. That's the whole shift, from damage control to design control.

How to set dark values in Design Studio

You set dark values in the same place you set every other style: Design Studio. On any colour property that supports it, click to expose two values instead of one, a light value and a dark value, and set each. The docs list the properties that take a dark value: Fill, Text colour, border colours and divider colours.

Two things are worth knowing before you start. First, dark mode is colour-only. Spacing, radius and font size stay the same in both modes, so you're recolouring a message, not rebuilding it. Second, you can set dark values in two places: in your global styles, where every message inherits them, or on a single message, where you override the global look for one specific case. Customer.io added global styles for in-app messages in February 2026, so if you set your dark palette once at the global level, new messages pick it up automatically.

While you work, a toggle at the top of the canvas switches the preview between light and dark, so you can check both without leaving the editor. The feature shipped for the JavaScript web integration and the iOS and Android SDKs.

The trap email teams don't have

Email teams never worry about this one, because email dark mode is out of their hands. In-app, you own the setup, and three details decide whether your dark styles actually land.

One catches almost everyone on web: dark values don't render until you turn them on. The mobile SDKs follow the device appearance automatically, but the JavaScript web integration defaults to light and stays there until you set one option, colorScheme: "auto", in the Customer.io In-App Plugin. That option tells the renderer to read the browser's prefers-color-scheme setting. Miss it, and every dark value you carefully set never appears on your website. That's the difference between a message that isn't showing the way you built it and one that works.

Another is the unreadable box, and it comes straight from the fallback rule: anywhere you don't set a dark value, the light value applies in both modes. Set a dark fill but forget the text colour, and in dark mode you get your dark-grey light-mode text sitting on your new dark background. Technically correct, functionally invisible. Half-styling a message is worse than not styling it at all, because it looks fine in the light-mode preview you're probably working in.

The last is subtler. The message follows the system colour scheme, prefers-color-scheme on web and the device appearance on mobile, not your app's own theme. If your product has its own light and dark toggle that a user can set independently of their OS, the two can disagree. Someone running their phone in light mode but your app in dark will get a light-mode message inside your dark UI. The docs describe what the message follows, the system preference; they don't promise it reads your app's internal theme. So design for the case where they diverge, rather than assuming they always match.

Test in both modes, on both kinds of host

Before you ship, test the message in light and dark mode, inside both a light-themed and a dark-themed host, on every platform you send to. That's the matrix email teams don't have to think about, and it's short enough to run by hand.

Work through it like this. On web, confirm colorScheme: "auto" is set, then load the message with your browser in light mode and again in dark. On iOS and Android, flip the device appearance and check each. In every mode, look specifically at the properties you didn't give a dark value: those are the ones falling back to light, and they're where the unreadable combinations hide. Then check the message inside your own product in both its themes, if it has a toggle of its own.

Two tools make this quicker. The canvas toggle in Design Studio previews light and dark while you edit, and a test send or live preview shows the message in a real browser or on a real device. When a web message still won't behave, Customer.io's in-app debugger reads out the SDK's live state, so you can see what it thinks is happening instead of guessing.

You don't need an app release to fix it

Because in-app content is server-driven, you can add or fix dark styles without shipping an app update. You draft the message in Customer.io, and the SDK fetches it when the person next opens your app or site. The content lives on Customer.io's side, not baked into a build. Change a dark value, publish, and the next delivery carries it.

That's the same property that makes inline in-app messages attractive: you update the content, not the codebase. One caveat is worth stating plainly. Server-driven covers the content and its styles, not the SDK itself. The app has to already run a version of the SDK that supports in-app messages; if it doesn't, no amount of publishing helps until you ship the update. Once it's in, though, your dark palette is a Design Studio change, not an engineering ticket.

Dark mode is a small feature with an outsized failure mode. It looks perfect in the editor and breaks in the field, silently, for the many people who keep dark mode on. Get the setup right once—colorScheme on web, a dark value on every colour property, a pass through the test matrix—and it stays right. If you're still deciding which in-app messages to build first, we've written about the three worth setting up before a welcome modal; dark styling is the polish you add once they've earned their place.

If you'd rather hand the whole thing off, setup, testing and the fiddly cross-platform checks, that's the kind of work we do. Tell us what you're building, or read more about our Customer.io work.

Frequently asked questions

How do I set dark mode for in-app messages in Customer.io?

In Design Studio, click any colour property that supports dark mode to expose separate light and dark values, then set the dark one. You can do this in your global styles, so every message inherits the dark palette, or on a single message to override the global look. A toggle at the top of the canvas previews light and dark while you edit. Dark values cover colour properties—fills, text, borders and dividers—so it's a recolour, not a rebuild.

Does Customer.io auto-invert my in-app colours in dark mode?

No. Unlike email clients, Customer.io doesn't invert anything. You set separate dark-mode values yourself, and the message uses them when the reader's system is in dark mode. Anywhere you don't set a dark value, the original light value applies in both modes, so nothing changes unless you change it.

Which integrations and SDKs support Customer.io in-app dark mode?

The 7 July 2026 release added dark-mode styles for the JavaScript web integration and the iOS and Android SDKs. On iOS and Android, messages follow the device appearance automatically. On web, you have to set the colour scheme option before dark values render.

Why does my in-app message look wrong in dark mode?

Usually one of two reasons. Either you set a dark value on some properties but not others, so the unset ones fall back to their light values and clash—dark-mode text vanishing on a dark fill, for example. Or, on web, you haven't set colorScheme: "auto", so the message ignores dark values entirely. Check that every colour property has a dark value, and confirm the web setup.

My website's in-app messages still show light mode. What's wrong?

On web, in-app messages default to light and stay there until you set colorScheme: "auto" in the Customer.io In-App Plugin in your JavaScript integration. That option tells the renderer to read the browser's prefers-color-scheme setting. Without it, dark values never appear, no matter how carefully you set them. The mobile SDKs don't need this—they follow the device appearance by default.

What happens if my app has its own dark-mode toggle?

The message follows the system colour scheme—prefers-color-scheme on web, the device appearance on mobile—not your app's internal theme toggle. If a user sets your app to dark while their device stays in light, the message renders in light mode inside your dark UI. Customer.io's docs describe what the message follows, the system preference, not your app's own state, so design for the two diverging.

Do I have to set a dark value for every colour property?

No, but you should for any property that would look wrong in dark mode. The rule is simple: anywhere you don't set a dark value, the light value applies in both light and dark mode. A half-styled message is the main cause of the unreadable-box problem, because the properties you skipped keep their light colours on a dark background.

Does dark mode change fonts, spacing or layout too?

No, dark mode is colour-only. Fills, text colour, borders and divider colours can take separate dark values. Spacing, radius and font size stay the same in both modes, per Customer.io's docs. You're recolouring the message, not building a second layout.

Do I need an app release to change in-app dark styles?

No. In-app content is server-driven: you change the styles in Design Studio, publish, and the SDK picks them up the next time the message is delivered. The one requirement is that your app already runs a version of the SDK that supports in-app messages. Adding or fixing a dark value after that is a content change, not an engineering release.

Does this apply to modals, inline messages, tooltips and the notification inbox?

Dark-mode values apply to in-app messages across display types—modal, overlay, inline and tooltip—because you set them on the message's components and background. The notification inbox is a separate channel, and Customer.io's dark-mode documentation covers in-app messages, not the inbox, so don't assume the same controls carry over there.

How is in-app dark mode different from email dark mode?

Email dark mode is forced on you: Gmail and Outlook invert colours you never chose, and you react to it. In-app dark mode is opt-in: you set the dark colours yourself in Design Studio, and nothing is inverted. One is damage control after a mail client's decision, the other is design control you hold from the start.