Open-sourcing Thumbprint native design system

What is Thumbprint?

Why we created a native version of Thumbprint

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

  • 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

  • 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 thumbprint.design.

Why we open-sourced Thumbprint Native

Open-sourcing Thumbprint iOS

  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

  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

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 Engineering

From the Engineering team at Thumbtack