How to Build a Color Palette for a Mobile App from Scratch
Building a color palette for a mobile app is similar to building one for web — but the constraints are tighter, the context is more variable, and the operating system platform you are designing for has opinions about how color should be used. A palette built without understanding these mobile-specific factors often looks fine in Figma mockups and falls apart in production on an actual device. Here is how to build it correctly from the start.
Mobile-Specific Color Constraints
Several constraints apply specifically to mobile that desktop web designers can largely ignore.
Screen size and information density: Mobile screens display significantly less content per view than desktop. This means each color in the palette appears in larger, more visible blocks — a navigation bar's background color occupies a proportionally larger share of the viewport on a 390px-wide phone than in a desktop browser. Colors that look like subtle background choices on desktop read as bold color statements on mobile.
Display variety: Mobile devices range from budget LCD screens with poor color accuracy to premium OLED displays with exceptional vibrancy and true black. Your palette will look different across this range. Colors that appear appropriately saturated on a calibrated OLED may look washed out on a budget LCD. Design and test at multiple saturation levels, using physical devices where possible.
Operating system design language: iOS (Apple Human Interface Guidelines) and Android (Material You / Material Design 3) both have specific color system recommendations. iOS favors dynamic system colors that adapt automatically to light and dark mode and to user accessibility settings. Material Design 3 uses a sophisticated dynamic color system that can generate a complete palette from a single seed color. Building a custom palette that works alongside these system recommendations — rather than against them — produces a more native-feeling experience.
Thumb navigation zones: On large phones, the bottom portion of the screen is the primary interaction zone (thumb reach). Color-coded interactive elements in the thumb zone need to be especially distinct — the user is interacting while looking at the content, not always at the navigation element itself.
Step 1 — Define Platform and Theme Support
Before choosing a single color, decide: iOS only, Android only, or cross-platform? Dark mode support from day one, or light mode first? These decisions shape the entire palette architecture.
If building cross-platform (React Native, Flutter, or similar), you need a platform-agnostic palette that works acceptably on both iOS and Android without relying on either platform's native color system. If building native iOS, consider how your palette will work with system colors and dynamic type. If building native Android with Material You, the dynamic color system may generate much of your palette automatically from a seed color — your design decisions are then about the seed color and the semantic mappings.
Dark mode support is no longer optional for any mobile app released in 2025. Both iOS and Android have had system-level dark mode for years, and users expect apps to respect their system preference. Build for both themes from the start. The architecture for dual-theme color systems is covered in our article on Dark Mode Color Palettes: How to Design for Both Themes.
Step 2 — Build Your Core Palette
Mobile app palettes are typically simpler than web palettes — fewer colors, deployed more consistently across a smaller set of component types. A well-structured mobile color palette includes:
Primary brand color: Used for the most important interactive elements — the primary action button, the active tab indicator, key links, the primary icon color. One color, one purpose. On mobile, the primary color appears in smaller, more specific contexts than on web, which means it can be somewhat more vivid without overwhelming the interface.
Background hierarchy (3-4 values): The main view background, the card or sheet background (slightly different from the view background to create elevation), the navigation bar background, and optionally an elevated modal or overlay background. In light mode, these progress from lightest (view background) to slightly deeper (elevated surfaces). In dark mode, they invert — deepest for the view, progressively lighter for elevated surfaces, following the Material Design elevation model.
Text hierarchy (3 values): Primary text (highest contrast), secondary text (medium contrast for labels, descriptions, timestamps), and disabled or placeholder text (lowest contrast, still meeting WCAG minimums). For mobile specifically, primary text contrast should exceed the 4.5:1 WCAG minimum — the outdoor use cases discussed in our article on Color Accessibility for Mobile: Designing for Small Screens make a higher contrast target (6:1 or above) worth pursuing for primary body text.
Semantic colors: Error red, success green, warning amber — each at a value appropriate for both light and dark theme use. Test these carefully; semantic colors that work on white backgrounds often fail on dark surfaces and need separate dark-mode values.
Step 3 — Design for OLED Dark Mode
If your app targets iOS or premium Android devices, OLED display optimization is worth specific attention in your dark palette. On OLED screens, pixels emitting zero light are completely black — creating true black that saves battery and produces exceptional contrast. This makes true black (#000000) a valid and desirable background color for dark mode on OLED mobile apps, even though it is too harsh for desktop dark mode use.
Consider offering two dark mode background variants: a "Pure Black" mode for OLED (backgrounds at #000000, elevated surfaces at #0d0d0d to #1a1a1a) and a "Dark Gray" mode for LCD devices (backgrounds at #121212, elevated surfaces at #1e1e1e to #2a2a2a). Many popular iOS and Android apps offer this distinction explicitly in settings.
Step 4 — Test on Physical Devices Across Brightness Levels
No Figma mockup substitutes for testing on actual hardware. Verify your palette on at least:
An OLED device (iPhone 12 or later, Samsung Galaxy S series) in both light and dark mode, at full and reduced brightness. An LCD device (older iPhone, budget Android) at full and reduced brightness. Outdoors or under bright overhead lighting — the conditions under which low-contrast choices become unreadable. With system text size increased (large accessibility text sizes affect how colors interact with type weight and scale).
Run WCAG contrast checks on every text-on-background and interactive-element-on-background combination using the process in our article on How to Test Color Contrast Ratios Before Launching Your Site — the same thresholds apply to mobile apps.
Step 5 — Document as Design Tokens
Mobile apps built with Swift/SwiftUI, Kotlin/Jetpack Compose, or cross-platform frameworks all support design token-style color theming. Define your palette as named semantic tokens — colorPrimary, colorBackground, colorTextPrimary, etc. — with separate light and dark values for each. This token layer is what enables automatic dark mode switching without component-level conditional logic.
For a complete understanding of how semantic token architecture works and why it matters for scalable color systems, see our article on How to Design a Color System for a SaaS Product — the principles transfer directly to mobile, even though the implementation languages differ.