Towards a Design System in iOS: Colors
An important aspect to the success of an application is how it looks, and how easy it is to use. These two aspects are what we call UI/UX, and they are not easy to get right, even though, fortunately, the iOS frameworks already give us a very good result with default components.
Consistency is key to achieve a good UI/UX in an app. From a user’s perspective, it is paramount that things that are the same, look the same, and are used the same. This helps them relate knowledge from previous features in your app, or in the system, and quickly learn how to use new functionality. But that does not stop there; from a developer’s perspective, it also has great benefits, as existing components and interactions can be easily reused.
As part of our efforts to enhance consistency across GoodNotes, our team has been working on a Design System: a library of tokens and components that we can refer to when implementing new features into the app. It serves as a common language between designers and developers to unambiguously refer to certain items in our software and improve the way we work.
We are still in the process of adopting it, but we found some interesting aspects that we would like to share with you. In this first post, we will focus on colors.
Colors in iOS
In our project, we try to use named colors defined in our Assets in Xcode. This lets us define semantic colors that include variants for light and dark modes, and get the right one without too much hassle.
This also lets us have a visual representation of all colors in the application, and verify that they are correct in both themes. These colors are available through the Interface Builder, or we can instantiate them using the UIColor(named:) initializer.
There is a small problem though: our designers usually work in Figma, not in Xcode. We need a way to import their list of colors into our project. Moreover, when they change something, we don’t want to go over the list of colors and manually update them in our Assets.
There are tools to automate the generation of colors from Figma, like Style Dictionary, and it not only works for iOS, but for other platforms, which may become useful in the future. However, if you take a look at the generated output, it has two main shortcomings:
- It does not use named colors in Assets.
- It does not distinguish between light and dark mode colors.
Tweaking Style Dictionary
Fortunately, Style Dictionary is customizable through plugins, so we wrote one to let us customize the output to match our needs. The task became surprisingly easy thanks to using Handlebars, a template system that can render our data in the format we would like.
First, we created a template for named colors that allows us to put together both light and dark versions of a color. It took us a bit of reverse engineering how Xcode represents colors in the colorset folders.
The template looks like:
Most of the template corresponds to the JSON format that Xcode uses to represent named colors, but the values enclosed by double curly braces ({{ }}) are the gaps that we can fill with light and dark variants of our color. We run this template for each color our designers define in Figma.
Finally, in order to have a convenient way of using these colors programaticaly, we generate a custom UIColor extension with values for the generated colors:
This way, whenever our designers refer to the color GoodNotesDenim600, with variants for light and dark mode, we only need to call UIColor.goodNotesDenim600, and the system will handle variants for us. If, for some reason, our designers decide to add new colors, or update existing ones, we only need to generate them again.
In case we transitioned to use SwiftUI (or you are already using it), our template to generate colors wouldn’t change much:
Similar to its UIKit counterpart, this offers a good API to work with colors in SwiftUI. The Assets catalog is shared, so we can even have both versions (UIColor and SwiftUI.Color) coexisting in the same code base.
Conclusions
Style Dictionary is a very useful tool to translate resources provided by designers using Figma, into resources that can be targeted to different platforms, like iOS in our case. However, it has some shortcomings when it comes to dealing with named resources, and light and dark modes. Thanks to its powerful extension capabilities, we can customize the generation process to fulfill our needs and unlock additional benefits, like nicer APIs to work with colors.
Did you like what we are doing? Do you want to join us, and help us shape up the future of GoodNotes? We are hiring!
This article was written by:
Tomás Ruiz-López is a Senior Software Engineer working in the iOS team at GoodNotes. He enjoys learning new technologies in the Apple ecosystem and looking at them from the prism of Functional Programming. He has developed several open source projects related to the Bow library, an attempt to bring FP concepts into Swift.
