SwiftHEXColors: turning a hex string into a UIColor without touching the components

Two initialisers, one for a string and one for an integer

SwiftHEXColors does one job: it lets you build a UIKit or AppKit colour from a hex value without splitting it into components by hand.

The string initialiser comes in three shapes, and the examples in the documentation show all of them:

// With hash
let color: UIColor = UIColor(hexString: "#ff8942")

// Without hash, with alpha
let secondColor: UIColor = UIColor(hexString: "ff8942", alpha: 0.5)

// Short handling
let shortColorWithHex: UIColor = UIColor(hexString: "fff")

The leading hash is optional, the alpha argument is optional, and the short three digit form is accepted alongside the six digit one. The integer form exists for people who do not want to type the double quotation marks, and it takes a real hex value:

// With hash
let color: UIColor = UIColor(hex: 0xff8942)

// Without hash, with alpha
let secondColor: UIColor = UIColor(hex: 0xff8942, alpha: 0.5)

What stands out is the scope. This is an extension with initialisers, nothing more. There is no converter to turn a UIColor back into a hex string, no adjustment function for lightening or darkening, and no struct wrapping a palette. If you are looking for a colour utility library rather than a hex parser, this is not that.

The same calls work on NSColor for macOS

The documentation gives a parallel set of examples for the AppKit side, which is the point of the library being a colour extension rather than a UIKit one.

// With hash
let color: NSColor = NSColor(hexString: "#ff8942")

// Without hash, with alpha
let secondColor: NSColor = NSColor(hexString: "ff8942", alpha: 0.5)

// Short handling
let shortColorWithHex: NSColor = NSColor(hexString: "fff")

The integer initialiser follows the same pattern on NSColor, with and without alpha.

So the same import gives you a hex initialiser on both platforms, and the call site reads the same way whether the code targets iOS or macOS. For a project with a shared model layer or a design system written once and used on both platforms, that symmetry is the actual value of the library, more than the parsing itself.

The Apple frameworks still offer their own initialisers, of course. UIColor and NSColor both take red, green, blue and alpha components directly, and they take that route through a colour space conversion. What the hex initialiser removes is the manual step of splitting a string into three components and dividing them by 255, which is where the bug usually lives.

Four ways to add it, and only one that needs a network fetch

The library predates the current Swift tooling, so the documentation covers four installation paths, and they differ in how much ceremony they involve.

With Swift Package Manager you add the dependency in your Package.swift file, pointing at the repository with a version requirement from 1.3.1.

With CocoaPods you specify it in your Podfile, which the documentation shows with a platform line for iOS 8.0 and use_frameworks! enabled, followed by the pod declaration. Then you run:

$ pod install

and add import SwiftHEXColors to the top of the files that use it.

With Carthage, which the documentation describes as a decentralized dependency manager that builds your dependencies and provides you with binary frameworks, you install the tool with Homebrew:

$ brew update
$ brew install carthage

The Cartfile entry is a single line, github "thii/SwiftHEXColors". You then run carthage update to build the framework and drag the built SwiftHEXColors.framework into your Xcode project.

And there is a fourth path with no tooling at all. You drag and drop the SwiftHEXColors.swift file into your project.

That last option is the most interesting for a library this small. A single Swift file with no dependencies can be vendored into a project, which removes the package manager from the decision entirely, at the cost of no automatic updates.

What the repository contains and how it is built

The tree is small and conventional for a Swift package of this vintage. There is a Sources/ directory for the code, a Tests/ directory, a Package.swift manifest, a SwiftHEXColors.podspec for CocoaPods, and a SwiftHEXColors.xcodeproj for the Xcode project. A Gemfile and a Gemfile.lock sit at the root, and a fastlane/ directory is present, which is the release automation tool chain, so publishing a new version is a fastlane lane rather than a manual step.

Continuous integration is configured through a .travis.yml file, and the README carries a build status badge pointing at Travis CI. There is also a .github directory and a .gitignore.

The CocoaPods badges in the header point at a CocoaPods doc set named SwiftColors rather than SwiftHEXColors, which is a small inconsistency in the metadata. The CocoaPods doc percentage badge, the Swift Package Manager compatible badge, the Carthage compatible badge and the platform badge are all in the header, so the header tells you the package is consumable through all three of those routes.

There are no GitHub releases for the project, so the version history is not visible from the repository page, and the last push was on 2026-06-23.

The stated requirements date the project, and the docs do not cover bad input

Two things are worth knowing before you adopt this, and neither is a reason to reject it, but both change what you should expect.

The first is the requirements line: Swift 3 and iOS 8.0 or above. Swift 3 is three major versions behind the current toolchain, so the stated requirement reflects the era of the library rather than a constraint of modern Swift. The iOS 8.0 floor is the more useful number for a deployment target, since most current applications set a much higher minimum and would not notice the difference.

The second is what the documentation does not say. There is no section on invalid input. The examples show a valid six digit value, a valid three digit value and a valid integer, but the README does not state what happens when the string is the wrong length, contains a character that is not a hex digit, or is empty. That is a documentation gap rather than a known defect, and it matters because a colour initialiser that silently returns a black or clear colour on bad input is a bug waiting to happen in a design token pipeline. If your hex values come from a build step or a remote config, parse them and validate them yourself before they reach this library, or wrap the initialiser with a checked version of your own.

There is also no support here for dynamic colours, which is what UIColor's dynamic provider is for in a dark mode aware application, and no conversion in the opposite direction. If either is on your list, this library does not cover it.

Writing the extension yourself, or importing one that does more

The honest alternative here is not another package. It is the option of writing the same extension in your own codebase, which for a single initialiser is a page of code.

The difference in approach is ownership. Vendoring the file means nobody else updates it, and you decide when the parsing rules change. Importing the package means the parsing rules are somebody's problem, and a version bump can change behaviour in a project that was not otherwise touched.

The other alternative is to stop parsing hex at runtime. A design token pipeline that generates Swift source from the palette file removes the string parsing altogether, at the price of a build step and a code generation step to maintain. That is a heavier arrangement than a colour extension, and it pays off when the palette changes often or when the colours are shared across platforms that do not run Swift.

There is a middle position worth considering, which is to import this library for the parsing and to wrap it in your own small layer that adds validation, a dark mode variant and the conversions you miss. That gets you the parsing immediately and leaves you free to change the library later, since the call sites all go through your wrapper.

What you should not do is reach for a full featured colour package to get this one initialiser. A library that also does colour space conversion, palette generation and image analysis brings its own assumptions about how your colours are stored, and the parts of it you do not use still have to build.

Editorial conclusion

Adopt SwiftHEXColors if your codebase is full of hex values that currently get split into red, green and blue components by hand, and you want one initialiser that covers iOS and macOS. Do not adopt it if you need colour space conversion, dynamic colours for dark mode, or a validated parse that reports invalid input, because the library exposes initialisers only. Verify first that the syntax you want is supported, since the string form takes an optional alpha and a separate integer form exists, and check the deployment target your project already uses against the iOS 8.0 requirement stated in the documentation.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. thii/SwiftHEXColors on GitHub