How to Choose a Color Palette for App Design

App color palettes are functional systems — not mood boards. Learn how to build a complete color system for mobile and web apps, from brand hue to semantic tokens, states, and dark mode.

App DesignColor SystemsUI DesignDesign TokensDark Mode

Key points

Build a tonal scale of your primary color with at least 9 steps — use mid-range steps for interactive elements, light steps for backgrounds, and dark steps for text and icons.

Design both light and dark mode from day one — trying to invert a light-mode palette later requires rethinking nearly every decision.

Brand color and system color are different things — your signature hue may need adjusting to work reliably as a functional UI color across all states and surfaces.

Start with semantic roles, not colors

The most common mistake in app color design is starting with a favorite color and trying to make it work everywhere. Start instead by defining the semantic roles your palette needs to fill: primary action, secondary action, surface background, surface elevated, destructive, success, warning, info, text primary, text secondary, text disabled. Each role gets a color token. The brand color fills the primary action role and informs the palette — it doesn't fill every role. This semantic-first approach makes dark mode, theming, and future brand updates dramatically easier.

Build a tonal scale from your brand hue

Once your brand hue is established, generate a tonal scale with at least 9 steps from near-white to near-black. Tools like Tailwind's color scale (50-950) or Material's tonal palette provide a useful reference model. Light values (50-200) work for backgrounds and tinted surfaces. Mid values (300-600) work for interactive elements and accents. Dark values (700-950) work for text and high-contrast elements. Verify that adjacent steps have at least 1.3:1 contrast ratio for legible surface layering, and that your interactive color achieves 4.5:1 against both white and your darkest surface.

Define semantic colors for system states

Beyond your brand color, every app needs a consistent set of semantic state colors: destructive/error (typically a red), success (a green), warning (an amber or orange), and informational (often a blue). These colors communicate system status and user feedback — they must be immediately recognizable across cultural contexts. Avoid using a saturated version of your brand color as your error color unless your brand color is red, as users have strong associations with red for errors. Test state colors against your surface palette in both light and dark modes.

Test at device scale and real brightness

Colors that look balanced in Figma at 100% on a calibrated monitor frequently misbehave at actual device sizes and real-world brightness levels. Colors that are too similar collapse together at small text sizes. Saturated colors become harsh on high-brightness displays and muted on low-brightness. Test your palette on actual devices with screen brightness varied from 30% to 100%. iOS and Android both have specific safe zones for colors near navigation bars and status bars — review platform HIG guidelines for your target platform before finalizing colors for those areas.

Practical next step

Move from the guide into a concrete palette lane

Guides explain the use case. Collections prove the taste. Packs handle the export and implementation layer.

Browse packs More guides

Related guides

Dark Mode Color Guide

How to Choose Colors for Dark Mode: A Complete System Design Guide

Dark mode requires fundamentally different color decisions than light mode — not just inverted values, but rethought contrast hierarchies, reduced saturation, and carefully calibrated surface elevations.

Color Systems

Chromatic Neutrals: Why Gray Is Never Actually Gray in Professional Design

Pure achromatic gray almost never appears in well-designed color systems. Professional palettes use chromatic neutrals — grays with a subtle hue bias — because they feel intentional, anchor the palette to a temperature, and read as crafted rather than defaulted. This guide explains how to build warm and cool chromatic neutral scales and why the temperature choice matters.

Accessibility

Color Accessibility in 2025: WCAG 2.1, APCA, and the Dual-Standard Audit

WCAG 2.1's contrast ratio formula was not calibrated for font weight or size — it treats a 400-weight 12px label and a 700-weight 48px heading identically. APCA (Advanced Perceptual Contrast Algorithm), the foundation of the forthcoming WCAG 3.0, corrects this with a model that varies required contrast by font size and weight. This guide explains the practical differences, how to run a dual-standard audit, and what to prioritize during the standards transition.