Dark Mode Design Best Practices: What Google, Apple, and the Research Say

Dark mode is a table-stakes feature now, and most teams still build it the laziest way possible: take the light theme, flip the colors, ship it. The result is an app that looks like a photographic negative — gray text on black soup, brand colors that scream, cards you can barely tell apart from the background. Google and Apple both wrote detailed specs explaining why that approach is wrong. And the battery story that justifies half of it? For most users it's 3–9%, not the headline numbers.

The battery myth: 47% is real, and it almost never applies to you

The strongest battery claim comes from good science. Purdue researchers Pranab Dash and Y. Charlie Hu built a per-pixel OLED power profiler and tested four phones (Pixel 2, Moto Z3, Pixel 4, Pixel 5) across six Google apps. Switching from light to dark mode saved 39–47% of display power — at 100% brightness. That's the number everyone quotes.

Here's the part that doesn't fit in a headline: at 30–50% brightness, the saving was 3–9%. Most people use auto-brightness, which sits around 30–40% indoors. The researchers' verdict was blunt: the saving is so small at normal indoor brightness that most users wouldn't notice. On LCD screens — budget phones, most laptops, older iPads — it's essentially zero, because the backlight stays on regardless of pixel color.

Dark mode is a real battery feature outdoors at max brightness, where the 39–47% shows up. Everywhere else it's a comfort and aesthetics feature. Stop selling it as battery management and start designing it as what it is.

Don't invert — rebuild: what Google's spec actually says

Google's Material Design dark theme guidance reads like a direct answer to the invert-and-ship crowd. The baseline surface is #121212, not pure black. Text comes in two tiers: white at 87% opacity for high-emphasis text, 60% for medium. The big idea is elevation: since dark shadows are invisible on a dark background, depth is communicated by making higher surfaces brighter — thin white overlays on top of the base surface, getting stronger with elevation. In Google's codelab, a bottom app bar gets the base #121212 plus a 12% white overlay. Cards, dialogs, and sheets all follow the same logic.

Color gets a rule most teams skip: desaturate. Saturated brand colors vibrate against dark backgrounds, so Material tells you to pull them back and use them sparingly — "limited color accents," preferring the surface color over the primary color in most chrome. Even your error red needs a dark-mode version: the same fire-engine red that reads fine on white vibrates on black, so the guidance is a dustier, dimmer red. If your red is still shouting at the same volume in dark mode, nobody adjusted it.

Apple took a different path — and both agree on one rule

Apple's approach is semantic instead of numeric. iOS (since 2019's iOS 13) and macOS define colors as roles — label, secondaryLabel, systemBackground — that automatically adapt to the trait environment. Use UIColor.label and dark mode mostly handles itself; hardcode a hex for your text and you've broken dark mode before you tested it. Apple's actual values show the same discipline as Material's: label text is white at 85% opacity, elevated cards step up through dark grays (#1C1C1E, #2C2C2E) to signal depth, and community measurements put dark-mode systemBlue slightly brighter than its light-mode counterpart to hold its contrast.

One disagreement worth noting: Apple's base system background is pure black (#000000), where Material explicitly avoids it. The honest reading: Apple's black maximizes OLED savings and contrast for content; Material's dark gray is friendlier for long sessions and makes elevation layering visible. Both are defensible. What neither defends is a theme nobody designed.

Contrast doesn't retire when you go dark

A common assumption is that dark mode is automatically more accessible. The opposite can be true: light text on black at full strength causes halation — text that seems to bleed into the background — which is why the platforms cap text opacity at 85–87% instead of pure white. WCAG's 4.5:1 ratio for body text still applies; it just gets harder to eyeball on a dark canvas, especially for saturated accents.

Practical checks that catch the most failures: view the whole UI in grayscale to expose contrast problems instantly; re-check every accent color against its dark background (your light theme's accessible blue is often a failing blue in the dark); and never trust the simulator — test on a real OLED screen outdoors, where dark interfaces lose legibility fastest. For contrast science beyond the old 4.5:1 rule, the perceptual color work in my OKLCH and APCA guide applies here too.

Type, images, and the ten small things

The details that separate a designed dark theme from a flipped one: bump font weights slightly — thin type that was elegant in black-on-white turns spindly in white-on-black; small text may need a size bump too, since the readability gap between modes grows as type gets smaller. Images and logos need dark-mode variants or at least transparent backgrounds, or you'll ship white boxes around every logo. QR codes are a real gotcha: an inverted QR code won't scan. Interactive states (hover, pressed, disabled) must stay distinct without relying on brightness alone. And animate the theme switch with a subtle transition — a hard flash at midnight is the kind of detail users feel even if they never name it.

Respect the user: give them the switch, then listen to the data

Ship both modes, default to the system preference via prefers-color-scheme, and always offer a manual toggle that persists. A Nielsen Norman Group survey of 115 mobile users found opinion split exactly three ways: a third want dark, a third want light, a third switch. There is no default everyone loves.

And here's the finding every designer should sit with: in NNGroup's summary of the German readability research (Piepenbrock and colleagues, Institut für Experimentelle Psychologie Düsseldorf), light mode won on every measured dimension — visual acuity and proofreading, for young and old adults — and produced no difference in fatigue. Yet participants reported no difference in readability. As NNGroup puts it: don't listen to users. Measure the reading task.

The takeaway isn't "ship light mode only." It's that the mode that looks good in a screenshot and the mode that performs in a reading test are different problems, and a designed dark theme accounts for both.

What to do this week

Audit your dark theme with five checks: is your base surface dark gray rather than pure black (or pure black with a deliberate reason)? Does elevation make cards brighter instead of relying on shadows? Is your loudest accent color desaturated relative to light mode? Does body text clear 4.5:1 on the actual dark background? And can a user override the system default? If any answer is no, you don't have a dark theme yet — you have an inverted light one.

References

• Nielsen Norman Group — "Dark Mode vs. Light Mode: Which Is Better?" — summary of Piepenbrock et al. readability studies; 115-user preference survey (1/3 dark, 1/3 light, 1/3 mixed)
• ScienceDaily — "Dark mode may not save your phone's battery life as much as you think" — Purdue Dash & Hu OLED profiler study (MobiSys '21): 3–9% savings at 30–50% brightness, 39–47% at 100%
• Google Codelabs — "Design a dark theme with Material and Figma" — #121212 surface, 87%/60% text opacity, elevation overlays, limited color accents
• Android Developers — Material Design 2 in Compose — elevation overlay behavior, primarySurface limited-accent guidance
• Median.co — "Apple's Human Interface Guidelines: Dark Mode do's and don'ts" — semantic colors, vibrancy, base/elevated backgrounds
• AppCherish — "Dark Mode Isn't Optional Anymore" — iOS semantic-color checklist, hardcoded-color pitfalls since iOS 13