How to Pick Colors for a Mobile App UI

Picking colors for a mobile app is harder than it looks. You are designing for a surface that gets used in bed at night, in direct sunlight on a street, in a dark gym, and on a cramped train. The same palette needs to work across OLED and LCD screens, at 30% brightness and 100%, in light mode and dark mode. Getting this right from the start saves months of redesign later.

Start with One Primary Color

Mobile UI palettes work best when built around a single primary color. This primary drives all core interactions: active tab bar icons, primary CTA buttons, selected states, progress bars, and interactive highlights. Using more than one color for interactive elements confuses users about which elements are tappable.

Your primary color should pass WCAG AA contrast against both white and your main dark surface when used as a button background with white or dark text. Generate the full 50-950 scale using the Tints & Shades Generator — you will use the lighter tints for pressed backgrounds and highlight tints, the base value for the primary button, and deeper shades for pressed states.

Define Surface Levels for Light and Dark Mode

Mobile apps need at least three surface levels in both light and dark mode. In light mode: a white or off-white page background, a slightly elevated card surface, and an even more elevated modal or sheet background. In dark mode: the hierarchy inverts — lighter values sit higher, darker values sit lower.

• Light: page #FFFFFF, card #F9FAFB, modal #FFFFFF (elevated with shadow)
• Dark: page #09090B, card #18181B, modal #27272A
• Both modes: use a consistent 3-level system so components feel spatially consistent

iOS vs Android Color Conventions

iOS and Android have different color personalities. iOS uses translucent materials with a vibrancy effect — your brand colors need to look good against blurred, translucent backgrounds. Android Material Design uses a more flat, bold color approach with color-filled surfaces (M3 color roles). Building for both means testing your palette against platform-specific patterns, not just your own mockups.

For cross-platform apps (React Native, Flutter), define your palette as CSS-style tokens and test on real devices for both platforms. What looks correct in Figma on a macOS monitor can fail badly on an Android screen with a lower-quality panel and different color profile.

Semantic Colors for Feedback States

Mobile apps show a lot of feedback: success messages, error toasts, warning banners, loading states. These need a consistent semantic color set — green for success, amber for warning, red for error, blue for info — that is distinct from your primary brand color and works in both light and dark modes.

• Success light: #16A34A, dark: #4ADE80
• Warning light: #D97706, dark: #FBBF24
• Error light: #DC2626, dark: #F87171
• Info light: #0284C7, dark: #38BDF8

Dark Mode is Not Optional

Both iOS and Android support system-level dark mode that apps are expected to respect. Build your dark mode palette from the start, not as an afterthought. Define all colors as semantic tokens with both light and dark values, and switch them based on the system color scheme setting. Avoid hard-coded hex values in your components — use token references throughout.

Accessibility on Small Screens

WCAG contrast requirements apply equally to mobile — and matter more, because small screens are often used in variable lighting. Target WCAG AA (4.5:1) for all text, and aim for AAA (7:1) for primary reading content like feed items and article text. Touch targets should be at least 44x44pt on iOS and 48x48dp on Android. The minimum contrast for UI component borders (input fields, buttons) is 3:1 against the surrounding background.