Open-sourcing Thumbprint native design system

Photo by Balázs Kétyi on Unsplash

What is Thumbprint?

A few years ago, in an effort to standardize the design of the Thumbtack product across platforms and features, we began creating our design system: Thumbprint. A design system is a collection of reusable components, tokens, and other design standards that can be used by both designers, to guide their work, and software engineers, to speed up UI development. Thumbprint is a cross-platform design system, with implementations for use on web, iOS, and Android.

Why we created a native version of Thumbprint

Thumbtack has had a web design system for several years, but as the company shifted its focus towards our native apps, it was imperative that we expand the design system as well. A design system provides consistency throughout a user’s interactions with a company, which is an important part of strengthening Thumbtack’s brand identity. By designing components holistically for all the platforms we support, we maximize this consistency.

Creating a native design system also speeds up feature development for our native engineers, since they don’t have to rebuild components from scratch for each new project.

How we created Thumbprint iOS

We built Thumbprint for iOS by starting with a few principles:

  • Using Thumbprint components should feel familiar to engineers who have worked with UIKit
  • Standardization should be easy; customization should be possible
  • Accessibility should be built into components from the start

Over the last couple years, the team has worked together to build dozens of components which comprise the significant majority of foundational UI elements needed for new features.

For more information about how we created our iOS design system, see Building a native design system for iOS.

How we created Thumbprint Android

We started the process of creating Thumbprint for Android by evaluating the common components across our codebase. We then took a look at which ones were often being customized and the patterns of customization. After selecting the components to include in the design system (a process which is re-evaluated regularly to see what new components should be added), we created the set of components while aligning to the set of following principles:

  • Components should use the Android library components as their base if possible
  • Components should be easily configurable and clearly documented
  • Components should include accessibility features from the start

When creating a new component, the Android lead for Thumbprint meets with design to help conceptualize the component, making sure it fits the necessary requirements and is aligned with Android standards. The Android lead then sources a volunteer from the Android engineers at Thumbtack (as each engineer puts in a certain amount of time to infrastructure improvements which Thumbprint falls under) and holds an API review/kickoff meeting. After the Android component is completed, it is put up for review and the appropriate documentation is added to

Why we open-sourced Thumbprint Native

While there are many web design systems that are open-sourced (including our own, Thumbprint for Web) there are fewer resources available for people who want to consider making their own design system for mobile or are simply looking for an easy to use mobile design system. By open-sourcing our mobile design systems we hope to help contribute and give back to the tech community.

Open-sourcing Thumbprint iOS

Before open-sourcing Thumbprint for iOS, we needed to solve a few problems that would arise when releasing it publicly.

  1. Dependencies on private code: Since Thumbprint previously lived in the same repo as the rest of our iOS codebase, it also shared some of the same helper classes for automated testing. We didn’t want to start maintaining a separate CocoaPod just for this testing code, but it also didn’t make sense to include as part of Thumbprint. To get around this, we ended up duplicating the code. While it breaks DRY a little, sometimes that’s the best worst option.
  2. Dependencies on assets with limited licenses: Thumbprint also relied on icon and font assets which are bound by licenses which would not permit us to release them publicly. To solve this, we updated the Font and Icon types in Thumbprint with a static “register” function that would take in a resource bundle. Our main iOS apps could pass in a bundle with these private assets, while demo code in our open-source repo could pass in open-source versions of these assets.
  3. Continuous integration & release process: Most internal codebases at Thumbtack use Jenkins for CI, but we wouldn’t be able to use our internal Jenkins configuration for an open-source repo. So we migrated to GitHub Actions both to run our test suite on pull requests and to release new versions of the Thumbprint pod.

Once these dependencies were resolved, moving Thumbprint’s source code was a much easier task–not quite as simple as cut and paste, but almost. We created a new repo for Thumbprint, copied over all the code, and then once we had published the first version of the Thumbprint pod, updated our iOS apps to point to that pod.

Since open-sourcing Thumbprint we’ve seen some additional friction when developing for Thumbprint since making changes involves (1) making the change to Thumbprint, (2) releasing a new version of the Thumbprint pod, and (3) upgrading the upstream codebase(s) to the new version. But we strongly believe in the value of open-sourcing code where we can to share with the community, and this overhead has been manageable so far.

Open-sourcing Thumbprint Android

We had the same three problems as iOS when starting the process of open-sourcing Thumbprint for Android (though obviously our solutions were different).

  1. Dependencies on private code: Our Android codebase is highly modular so there were not too many interdependencies between the module that housed Thumbprint in our Android codebase and the rest of the Android codebase. However, we did need to untangle a few helper classes from the general codebase.
  2. Dependencies on assets with limited licenses: This was the biggest problem we ran into. Both our icon assets and font assets were not under licenses that would allow us to open-source them. For icons, we moved them to their own module in the Android codebase, separating them from the module that would become the Thumbprint for Android repository. There were not too many components that required icons but for the ones that did we created a helper function that allows users of Thumbprint for Android to swap in their own icons for the boilerplate icons we added, whether through xml or through code. For font assets we created a similar function -> the user of the library can define a “thumbprintFont” item in their theme and Thumbprint for Android will substitute the given font in. Otherwise the default Android font will be used.
  3. Continuous integration & release process: In our main Android codebase we use Jenkins for CI and releases. We wanted something more lightweight for Thumbprint for Android so we decided to use GitHub Actions to handle CI and create GitHub Releases. JitPack then automatically creates the build artifacts every time a new release is created. You can view them here.

Once we had resolved these problems, we moved the Thumbprint for Android code from its module to a separate repository with its own Gradle build configuration. Our Android codebase now points to the latest .AAR file created by JitPack.

Obviously now adding to Thumbprint for Android involves a little more friction since it involves committing to our open source repository, creating a new release and then updating the version in our Android codebase. However, we firmly believe that being able to contribute to the open-source community is worth this small additional friction.

Contributing to Thumbprint

We hope our open-sourcing of our mobile design system will encourage other people to open-source their design systems as well! The more design systems out there, the more we can all learn from each other.

If you’re interested in contributing to Thumbprint for Web, Android or iOS, feel free to take a look at our contributor guidelines in the repositories.

Thumbprint for Web
Thumbprint for iOS
Thumbprint for Android

Interested in learning more about working at Thumbtack? Interested in a potential career at Thumbtack? We are always looking for more talented engineers and you can find our current opening or just learn more about working at Thumbtack here.

About Thumbtack

Thumbtack is a local services marketplace where customers find and hire skilled professionals. Our app intelligently matches customers to electricians, landscapers, photographers and more with the right expertise, availability, and pricing. Headquartered in San Francisco, Thumbtack has raised more than $400 million from Baillie Gifford, Capital G, Javelin Venture Partners, Sequoia Capital, and Tiger Global Management among others.




Stories from the Engineering team at Thumbtack

Recommended from Medium

How to Control Drones Using AWS Services

How to Create a Storage Space or Mirrored Volume in Windows 7, 8 or 10

How I Made The App That Turns YouTube Videos Into Podcasts

Microprocessor I: General Purpose Registers

FastPass: An answer to COVID-19

How to use Airtable

Easy Steps to Login to Linksys Velop Dashboard during the Bridge Mode | Linksys Velop Login

Here’s What to Expect in V2 of $SCC

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kevin Beaulieu

Kevin Beaulieu

iOS @ Kaia Health

More from Medium

The Anatomy of Asynchronous Code Testing in iOS

White thread in a needle splitting into multi-colored threads

Microsoft Teams — Designing for Emerging Markets —  Part 1 (Network Profile)

How we customize and deliver our mobile app templates with fastlane & Jenkins

Mock server inside native iOS tests