Design token automation for applications

Due to the type of project in which we work, we have to support different application brands. From the design point of view, we have different themes, each of them with different colors, radii, fonts, and sizes. In order to manage all of these options that depend on the brand, the design team created a list of tokens that have a different value depending on the theme. These tokens are used in the designs in Figma to be able to generate them for all the brands without the need to change them one by one. Using these tokens is beneficial for design and developers teams because both of them have a clear catalog with all the things that have to change taking into account the brand. To avoid problems and have a common language, these tokens are exported as a JSON file per brand and managed in its own GitHub repository allowing us to have different branches and a historic with all the changes.

The original way of working

When we started to tokenize things like colors, the way of working was:

Design team creates/updates the color tokens.
Design team creates three Jira tickets for each development team (Android, iOS, and Web).
Each development team implements these changes manually in its own repository.

This way of working was the ideal at the beginning but it came with several problems:

Each minimal change in the tokens had to have a Jira ticket. This was a manual task that could lead to human errors because it was easy to forget to add some of the changes.
It was a repetitive task without any value at the end.
Minor errors in the flow, like for example forgetting to notify some of the changes, were translated into a review of all the color tokens one by one (tens of tokens) by the developers team to update each of them to the updated value. This resulted in wasting a lot of time on a simple task.
After some time working like that, having that type of problems and seeing the benefits of using these tokens (it was just not only used for colors), we started a project to automate all of this process. We would have to invest some development time from the three platforms but we thought that it would compensate in just a few months.

The goal with this project was that mostly without any user interaction, the tokens were updated in the three platforms when the design team would decided.

The solution

We decided to use GitHub actions to automate all of these process. The idea was to execute one in the Mística design repository which invoked the other three repositories to update the tokens to the last version. Just running this GitHub action, three PRs would be created (one per platform) and the only job of the developers would be review these PRs. Much better than review each token one by one in a JSON to move the changes to the code.

Diagrama del proceso

The decision of having multiple GitHub actions instead of just one was due to each platform is really different and has to generate its own files or code so using its own technology simplifies the process.

The implementation

In the next points we will enter in more detail about the implementation that we follow in each platform.

Android

The Android version of Mística supports two implementations of the components: classic android views and Compose. We need a very different output in each case. For android views, we generate different XML files with attributes and styles that later we use in our code. To generate these XML files easier, we use the library Kotlin XML Builder. In the Compose version, we have to generate different Kotlin classes. In order to do this, we use the library Kotlin POET to simplify the proccess of generate Kotlin code. You can see the details of our implementation in our repository.

iOS

On the iOS side we need to generate Swift files that defines the public protocol of the palettes and the specific implementation for each brand. We decided to use a code generator called Hygen that allows us to create multiple generators using EJS templating language that save us a lot of time and the possibility of reusing them separately. You can see the details of our implementation in our repository.

Web

On the web side, we have a script in Javascript which generates one JS file per brand with all the information needed inside. You can see the details of our implementation in our repository.

Conclusion

Developing this project took some weeks from different people but as soon as the first changes in tokens arrived, we saw the big upgrade that we expected. Changes in multiple colors that in the past were a nightmare, now are just a couple of clicks, allowing the teams to concentrate in tasks that give us more value. You can see here the type of PRs that our GitHub actions generate. A lot of changes that are done automatically.

Development

Android

Mock API Server: Easy Testing for Android Development

Discover how the Android Mock API library simplifies application testing by simulating backend responses. Learn how to set up mock servers and speed up your development with this MockWebServer-based tool.

01/24/2024

Development

Apps

Advanced typography in TypeScript

Learn how to manage tickets (coupon, ticket and pass) with type predicates, narrowing and function overloading. Read more here

05/17/2023

Distributed Tracing with OpenTelemetry in Telefónica Kernel

Software Engineering

Metrics

Implementation of Distributed Tracking with OpenTelemetry at Telefónica Kernel

At Telefónica Kernel, we implemented distributed tracking with OpenTelemetry to improve the observability of complex systems. Using service meshes such as Istio, we were able to track requests between components without modifying code, optimizing performance and diagnosing bottlenecks in our native cloud platform.

05/03/2023

Design Token Automation: Enhancing the Development Process