Use Hex color in SwiftUI
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
SwiftUI's Color type does not accept a hex string out of the box, so the usual solution is a small extension that converts hex into normalized red, green, blue, and alpha values. That works well for design-system colors, but you should still be clear about which hex formats you support and when an asset catalog color is a better choice.
A Practical Color Extension
Here is a simple extension that supports #RRGGBB and #RRGGBBAA:
Usage:
That is enough for most apps that receive design colors as hex values.
Be Explicit About the Hex Format
The most common source of bugs is disagreement about the byte order. Some teams mean:
- '
RRGGBBAA'
while others mean:
- '
AARRGGBB'
The extension above uses RRGGBBAA for 8-digit values. That needs to be documented clearly. Otherwise a designer hands you 80FF0000, you parse it the wrong way, and the app shows the wrong color with the wrong opacity.
If your team uses a different convention, change the bit shifts and keep the API documentation explicit.
Integer-Based Initializers Also Work Well
If you prefer not to parse strings repeatedly, you can accept an integer literal:
Usage:
This is sometimes cleaner in code, especially when the values are constants and do not come from JSON or design exports.
Prefer Asset Catalog Colors for Adaptive UI
Hex parsing is convenient, but it is not always the best architectural choice. If a color should adapt to:
- light mode
- dark mode
- high contrast variants
- platform-specific appearance settings
then an asset catalog color is often better than a hard-coded hex literal.
Example:
That gives designers and the app theme system more flexibility than scattering hex values through views.
Use Hex for Constants, Not for Dynamic Theme Sprawl
Hex is a good fit when:
- you are matching a fixed design spec
- values come from a remote config or API
- you need a lightweight conversion helper
It becomes less attractive when every screen hard-codes its own colors independently. In that case, you end up with weak theme discipline and harder maintenance.
A better pattern is usually:
- parse once
- expose named semantic colors
- reuse those names across the UI
That keeps the view layer readable.
Common Pitfalls
The biggest mistake is mixing up 8-digit byte order. If the code expects RRGGBBAA and the design system provides AARRGGBB, the color will be wrong.
Another issue is silently falling back to black or another default on invalid input without logging or testing. That can hide broken theme data.
Developers also often overuse hard-coded hex values where asset catalog colors would be better for dark mode and broader design consistency.
Finally, make sure the color space is intentional. .sRGB is a sensible default for most app UI work, but it should not be chosen accidentally.
Summary
- SwiftUI does not natively parse hex strings into
Color, so a small extension is the usual solution. - Document the supported formats clearly, especially for 8-digit colors with alpha.
- Integer-based initializers are a clean option for static color constants.
- Use asset catalog colors when adaptive appearance matters more than raw hex convenience.
- Keep hex parsing centralized instead of scattering ad hoc conversions throughout the UI.

