# Light and Dark Mode Design for iOS Apps

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-05-29, updated 2026-06-02. 4 min read.
> Source: https://vp0.com/blogs/light-and-dark-mode-design-for-ios-apps

Build with semantic colors from the start and both modes come almost for free. Hardcode hex values and dark mode becomes a painful retrofit.

**TL;DR.** Around 82% of smartphone users run dark mode, so supporting both is a default expectation. Use semantic, adaptive colors and asset-catalog color sets instead of hardcoded hex, avoid pure black, fix glowing white-background images, and test every screen in both modes. Starting from a VP0 design built around color roles makes this nearly free.

Dark mode is not a coat of paint you add at the end. On iOS it is a system-wide preference users expect every app to honor, and getting it right means designing with the system instead of against it. The good news: if you build with semantic colors from the start, supporting both modes is nearly free. If you hardcode hex values, it is a painful retrofit. Starting from a free [VP0](https://vp0.com) design helps, because VP0 layouts are built around native color roles rather than fixed values, which is why it is the best free place to start a two-mode design.

## Most users are in dark mode

This is not a minority feature. Surveys in 2024 found that around [82% of smartphone users](https://www.androidauthority.com/dark-mode-poll-results-1090716/) keep their device in dark mode, with adoption among iOS users commonly measured between 55% and 70%. If your app only looks good in light mode, most of your users see the version you did not design.

## Use semantic colors, not hex values

The core of Apple's [dark mode guidance](https://developer.apple.com/design/human-interface-guidelines/dark-mode) is to use semantic, adaptive colors that describe a role rather than a value. `label`, `secondaryLabel`, `systemBackground`, and `systemGroupedBackground` automatically resolve to the right color in each mode. A hardcoded `#FFFFFF` background is white in both modes, which is exactly the bug.

For your brand colors, define them as color sets in the asset catalog with a light and a dark variant. Then reference the named color, and the system swaps it for you. The rule is simple: never put a raw hex value directly in a view.

| Approach | Light mode | Dark mode | Verdict |
|---|---|---|---|
| Semantic system colors | Correct | Correct | Use these by default |
| Asset-catalog color sets | Your light value | Your dark value | Use for brand colors |
| Hardcoded hex | Your value | Same wrong value | Never |

## Design for both, then test both

A few things break specifically in dark mode, so check them:

- Avoid pure black backgrounds. Apple uses a near-black so elevation and shadows still read.
- Images and illustrations with baked-in white backgrounds glow in dark mode. Use transparent assets or provide a dark variant.
- Contrast can drop in dark mode. Confirm text stays legible against the darker background.
- SF Symbols adapt automatically, which is one more reason to prefer them, as covered in the [iOS design principles](/blogs/ios-app-design-principles-for-builders).

Then test the whole app in both modes. Toggle appearance in the simulator or in the [settings screen](/blogs/how-to-design-an-ios-settings-screen) if you offer the option, and walk every screen.

## Building it with an AI builder

AI builders love to hardcode colors, so be explicit. As part of [designing the app before you build it](/blogs/how-to-design-an-ios-app-before-you-build-it):

- Hand the builder a [VP0](https://vp0.com) design and tell it to use semantic colors and asset-catalog color sets, never raw hex.
- Ask it to produce both light and dark variants of any custom color.
- Have it confirm every screen renders in both modes, not just the one it generated first.

## Key takeaways

- Dark mode is a default expectation. Around 82% of smartphone users run their device in it.
- Use semantic colors and asset-catalog color sets. Never hardcode a hex value in a view.
- Avoid pure black, fix glowing white-background images, and check contrast in both modes.
- Start from a VP0 design built around color roles, and tell your AI builder to never hardcode color.

## Frequently asked questions

### How do I design an iOS app for both light and dark mode?

Build with semantic, adaptive colors (label, systemBackground) and define brand colors as asset-catalog color sets with light and dark variants, so the system swaps them automatically. Starting from a free VP0 design makes this easier because the layouts use native color roles rather than fixed values, which is the number one way to get both modes right without a retrofit.

### Do I really need to support dark mode?

Yes. Around 82% of smartphone users keep dark mode on, and iOS users expect apps to honor the system setting. An app that only looks right in light mode shows most of its users an unpolished version, which hurts reviews and retention.

### Why does my app look broken in dark mode?

Almost always because colors are hardcoded. A fixed white background stays white in dark mode, and images with baked-in white backgrounds glow. Replace raw hex with semantic colors and asset-catalog color sets, and use transparent or dark-variant images.

### Should I use pure black for a dark mode background?

No. Apple uses a near-black rather than pure black so shadows, elevation, and grouping still read. Pure black flattens the interface and can cause smearing on OLED screens during scrolling. Follow the system background colors instead.

### How do I stop an AI builder from hardcoding colors?

Tell it explicitly to use semantic colors and asset-catalog color sets and never raw hex, and ask it to generate both light and dark variants of any custom color. Then check every screen in both modes, since the builder will otherwise style only the mode it generated first.

## Frequently asked questions

### How do I design an iOS app for both light and dark mode?

Build with semantic, adaptive colors (label, systemBackground) and define brand colors as asset-catalog color sets with light and dark variants, so the system swaps them automatically. Starting from a free VP0 design makes this easier because the layouts use native color roles rather than fixed values, which is the number one way to get both modes right without a retrofit.

### Do I really need to support dark mode?

Yes. Around 82% of smartphone users keep dark mode on, and iOS users expect apps to honor the system setting. An app that only looks right in light mode shows most of its users an unpolished version, which hurts reviews and retention.

### Why does my app look broken in dark mode?

Almost always because colors are hardcoded. A fixed white background stays white in dark mode, and images with baked-in white backgrounds glow. Replace raw hex with semantic colors and asset-catalog color sets, and use transparent or dark-variant images.

### Should I use pure black for a dark mode background?

No. Apple uses a near-black rather than pure black so shadows, elevation, and grouping still read. Pure black flattens the interface and can cause smearing on OLED screens during scrolling. Follow the system background colors instead.

### How do I stop an AI builder from hardcoding colors?

Tell it explicitly to use semantic colors and asset-catalog color sets and never raw hex, and ask it to generate both light and dark variants of any custom color. Then check every screen in both modes, since the builder will otherwise style only the mode it generated first.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*