That's a pretty compelling list of benefits! Before we move on, though, let's think through what downsides\u2013if any\u2013might exist:<\/p>\n\n\n\n
- \n
- A centralized pipeline means that introducing a bug affects <\/strong>every<\/em><\/strong> image build pipeline<\/strong>.<\/li>\n\n\n\n
- Abstracting away the complexity of image build commands deprives engineers of the opportunity to learn the build commands<\/strong> and can inadvertently build knowledge silos. A motivated engineer can learn the image build commands but we won't be giving them a natural on-ramp to learn them.<\/li>\n\n\n\n
- The pipeline doesn't run locally<\/strong>, so if someone is trying to build the image locally, they will need to write their own build commands rather than leverage the work we put into the pipeline. This also further compounds the missed learning opportunities.<\/li>\n<\/ul>\n\n\n\n
As we think about these tradeoffs, the amount of flexibility and consistency we can achieve through centralized pipelines easily outweighs the downsides. In addition, if we write guides for engineers walking through the happy path of building a container on their local machine, we can help reduce some of the downsides.<\/p>\n\n\n\n
This seems like a great idea, so let's run with it!<\/p>\n\n\n\n
Writing a Pipeline Helper Using the Builder Pattern<\/h2>\n\n\n\n
One way to achieve a shared pipeline is to have a pipeline library which parses default values from a config struct. Below is an overly-simplified example:<\/p>\n\n\n\n
\/\/ jenkinsLibraries\/vars\/dockerReleasePipelineHardToTest.groovy\n\ndef call(Map config = [:]) {\n def target = (config.remove('target') ?: 'release') as String\n def owner = config.remove('owner') as String\n if (owner == null || owner.isEmpty()) {\n throw new Exception('owner must be defined')\n }\n\n pipeline {\n agent {\n label 'dockerce'\n }\n\n stages {\n stage('Build') {\n steps {\n sh \"\"\"\n aws ecr create-repository --region=us-west-2 --repository-name=example --tags 'Key=owner,Value=${owner}'\"\n docker buildx build --target='${target}' --tag example:latest .\n docker push example:latest\n \"\"\"\n }\n }\n }\n }\n}\n<\/code><\/pre>\n\n\n\nWhile it is possible to test Jenkinsfiles like this using JenkinsPipelineUnit<\/a>, as we add complexity the JenkinsPipelineUnit tests would quickly balloon in complexity.<\/p>\n\n\n\n
Instead, we can use the builder pattern to handle most of the work of our pipeline logic. We see several advantages of using a builder rather than putting all the logic in the pipeline:<\/p>\n\n\n\n
- \n
- It's easy to define default values<\/strong><\/li>\n\n\n\n
- Discoverability<\/strong> of available options is easy<\/li>\n\n\n\n
- We can use the class to generate commands <\/strong>for our pipeline<\/li>\n\n\n\n
- It's simple to test<\/strong> the class as well as the generated commands<\/li>\n<\/ul>\n\n\n\n
Here is the most basic example of the builder pattern in groovy:<\/p>\n\n\n\n
\/\/ jenkinsLibraries\/src\/com\/wealthfront\/jenkins\/DockerReleaseTarget.groovy\n\npackage com.wealthfront.jenkins\n\nclass DockerReleaseTarget {\n String target\n String owner\n\n private String region = 'us-west-2'\n private String awsAccount = '1234567890'\n\n DockerReleaseTarget() {\n this.target = 'release'\n this.name = ''\n }\n\n DockerReleaseTarget setName(String name) {\n this.name = name\n return this\n }\n\n DockerReleaseTarget withTarget(String s) {\n this.target = s\n return this\n }\n\n DockerReleaseTarget withOwner(String s) {\n def allowedOwners = [ 'devops', 'trading', 'etc....' ]\n if (!s) {\n throw new IllegalStateException('Owner must be non-empty.')\n }\n if (!allowedOwners.contains(s)) {\n throw new IllegalStateException(\"Invalid owner: '${s}'. Must be one of: ${allowedOwners.join(', ')}\")\n }\n this.owner = s\n return this\n }\n\n void runValidation() {\n if (!this.owner?.trim()) {\n throw new IllegalStateException(\"The 'owner' field must not be empty, use withOwner(owner).\")\n }\n if (!this.target.trim()) {\n throw new IllegalStateException('The target must not be empty, use withTarget(\"targetName\")')\n }\n if (!this.name.trim()) {\n throw new IllegalStateException('The name must not be empty, this is an issue with the dockerReleasePipeline.')\n }\n }\n\n String getEcrRepo() {\n return \"${this.awsAccount}.dkr.ecr.${this.region}.amazonaws.com\/${this.name}\"\n }\n\n String ecrRepoLoginScript() {\n return \"aws ecr get-login-password --region ${this.region} | docker login --username AWS --password-stdin ${this.getEcrRepo()}\"\n }\n\n String createEcrScript() {\n return \"aws ecr create-repository --region=${this.region} --repository-name=${this.name} --tags 'Key=owner,Value=${this.owner}'\"\n }\n\n String dockerBuildScript() {\n return \"docker buildx build --target='${this.target}' ${this.name} .\"\n }\n\n String dockerPushScript() {\n return \"docker push ${this.name}\"\n }\n\n}\n<\/code><\/pre>\n\n\n\nNotice how this allows us to set standard values for the AWS Account and Region. At the same time, we define a default value for the owner tag, but allow users to override the tag with a list of allowed options. Finally, we are generating the relevant docker commands in this class so we can test that the commands will work as expected.<\/p>\n\n\n\n
Of course, we have many more configuration options available so that engineers can pick target platforms, naming suffixes, dockerfile names, and more. This wide variety of options is important to let us support the scope of config the various teams using these pipelines require. <\/p>\n\n\n\n
addTag(String)\nwithShellTag(String)\nwithTags(String... tagList)\nwithPush(Boolean shouldPush = true)\nwithRepoSuffix(String s)\nwithTarget(String s)\nwithParallel(Boolean p)\nwithOwner(String s)\nwithBuildArg(String... args)\nwithRawBuildArg(String... args)\nwithArchitectures(String... archs)\nwithDockerfile(String dockerfile)\nwithArchitectureSpecificDockerfile(String arch, String dockerfile)\nwithLatestTag(Boolean tagLatest = true)\nasPrivateRepo(Boolean asPrivate = false)<\/code><\/pre>\n\n\n\nLooking at all these options, consider how important it is that we test how the options combine. With that in mind, let\u2019s look at how we can test this library.<\/p>\n\n\n\n
Testing<\/h2>\n\n\n\n
Wealthfront values testing, which is a topic we've written about many times before<\/a>. Our Jenkins libraries are no exceptions. Below is an example of how we can test the withOwner function to ensure it behaves as expected:<\/p>\n\n\n\n
\/\/ jenkinsLibraries\/srctest\/com\/wealthfront\/jenkins\/DockerReleaseTargetTest.groovy\n\npackage com.wealthfront.jenkins\n\nimport com.lesfurets.jenkins.unit.BasePipelineTest\nimport org.junit.Test\n\nclass DockerReleaseTargetTest extends BasePipelineTest {\n @Test\n void testDockerReleaseTarget_withOwner() {\n def script = loadScript('vars\/helper.groovy')\n def drt = script.newDockerReleaseTarget()\n .withOwner('devops')\n\n assert drt.createEcrScript().contains('Key=owner,Value=devops')\n }\n\n @Test\n void testDockerReleaseTarget_invalidOwnerShouldFail() {\n def script = loadScript('vars\/helper.groovy')\n try {\n def drt = script.newDockerReleaseTarget()\n .withOwner('invalid-owner-name')\n fail 'Expected exception was not thrown'\n } catch (IllegalStateException x) {\n }\n }\n}\n<\/code><\/pre>\n\n\n\nThis testing pattern allows us to confirm that validations work as expected and that the docker commands are generated as expected.<\/p>\n\n\n\n
These two example tests show that the owner value is propagated correctly to the createECRScript as well as ensuring that invalid owners will throw an exception. <\/p>\n\n\n\n
Implementation in a Pipeline<\/h2>\n\n\n\n
Because we're using our tested library for generating our commands, the final example pipeline becomes much simpler:<\/p>\n\n\n\n
\/\/ jenkinsLibraries\/vars\/dockerReleasePipeline.groovy\n\ndef call(Map config = [:]) {\n def drt = config.remove('releaseTarget')\n if (drt == null) {\n throw new Exception('releaseTarget must be defined')\n }\n\n drt\n .setName(env.JOB_NAME)\n .runValidation()\n\n pipeline {\n agent {\n label 'dockerce'\n }\n\n stages {\n stage('Build') {\n steps {\n withCredentials([\n usernamePassword(credentialsId: 'ecr-aws-creds',\n usernameVariable: 'AWS_ACCESS_KEY_ID',\n passwordVariable: 'AWS_SECRET_ACCESS_KEY'),\n ]) {\n sh drt.ecrRepoLoginScript()\n }\n sh drt.createEcrScript()\n sh drt.dockerBuildScript()\n sh drt.dockerPushScript()\n }\n }\n }\n }\n}\n<\/code><\/pre>\n\n\n\nNotice how we can force the repo name using the .setName(env.JOB_NAME) function in the final pipeline. In addition, we call .runValidation() as a final check of the config before we start executing on the runner.<\/p>\n\n\n\n
Because the validation occurs before we claim an agent, if there is a config error, the pipeline will fail right away. This gives immediate feedback to the engineer what parts they need to fix.<\/p>\n\n\n\n
When users want build a container image, they can now use the pipeline template and pass in a builder:<\/p>\n\n\n\n
@Library(\"JenkinsFiles\") _\n\ndockerImageBuildPipeline(\n releaseTarget: helper.newDockerReleaseTarget()\n .withOwner('devops')\n .withTarget('release-debug')\n)\n<\/code><\/pre>\n\n\n\nConclusion<\/h2>\n\n\n\n
And that's it! While this blog post has presented the most basic implementation of a shared container build pipeline, hopefully you can see how this lays a foundation that sets us up to achieve our original goals of centralizing configuration, abstracting away ECR auth, standardizing repo tags, and setting us up to add new features down the road.<\/p>\n\n\n\n
Overall this pattern of centralizing build pipelines, parameterizing them using the builder pattern, and testing the pipeline code leads to a pleasant engineering experience both when writing and using the pipeline. Discoverability of features is high and iteration cycles are tight because bad config pushes fail quickly.<\/p>\n\n\n\n
If you want to join us in driving the future of containers at Wealthfront\u2014prioritizing engineering experience, testing, and automation\u2014consider joining our engineering team<\/a>! <\/p>\n\n\n\n
\n\n\n\nDisclosures<\/h4>\n\n\n\n
The information contained in this communication is provided for general informational purposes only, and should not be construed as investment or tax advice. Nothing in this communication should be construed as a solicitation or offer, or recommendation, to buy or sell any security. Any links provided to other server sites are offered as a matter of convenience and are not intended to imply that Wealthfront Corporation or its affiliates endorses, sponsors, promotes and\/or is affiliated with the owners of or participants in those sites, or endorses any information contained on those sites, unless expressly stated otherwise.<\/p>\n\n\n\n
Investment advisory services are provided by Wealthfront Advisers LLC, an SEC-registered investment adviser. Brokerage services are provided by Wealthfront Brokerage LLC, Member FINRA<\/a>\/SIPC<\/a>. Financial planning tools are provided by Wealthfront Software LLC.<\/p>\n\n\n\n
All investing involves risk, including the possible loss of money you invest, and past performance does not guarantee success. Please see our Full Disclosure<\/a> for important details.<\/p>\n\n\n\n
Wealthfront Advisers LLC, Wealthfront Brokerage LLC, and Wealthfront Software LLC are wholly owned subsidiaries of Wealthfront Corporation.<\/p>\n\n\n\n
\u00a9 2025 Wealthfront Corporation. All rights reserved.<\/p>\n","excerpt":"The DevOps team at Wealthfront has been in the process of migrating services to run inside containers. As part of this process we need a way to build containers using our CI\/CD tool, Jenkins. While we could write a Jenkinsfile for each container image we wanted to build, we identified this was a good opportunity... Read more<\/a>","date":"2025-10-08 12:15:22","author":"Oliver Isaac","categories":["wealthfront engineering"],"tags":["automation","ci","continuous-integration","jenkins","testing"]},{"id":2772,"title":"Building Wealthfront’s multi-platform design system","permalink":"https:\/\/eng.wealthfront.com\/2022\/05\/10\/building-wealthfronts-multi-platform-design-system\/","content":"\n
Over the past two years at Wealthfront we\u2019ve been building a design system from the ground up across all our frontend platforms: Android, iOS, and web. If you\u2019re a Wealthfront client you may have noticed sweeping, iterative visual changes across our apps as we introduced new components and migrated features to adopt these components.<\/p>\n\n\n\n
At this point, the core design system components have been implemented on all platforms, so we wanted to share a bit about our journey building a multi-platform design system.<\/p>\n\n\n\n
Motivation<\/h2>\n\n\n\n
In the past, design patterns, reusable components, and other shared utilities grew organically on all platforms. If this was already happening, why create a design system in the first place?<\/p>\n\n\n\n
An organic, bottoms-up approach led by individual designers and engineers can work well for small, nimble teams but begins to break down as teams scale.<\/p>\n\n\n\n
First, there is no guarantee that components are always being built with reusability in mind, nor that they solve all the necessary product use cases. This can lead to code duplication and extra effort which can result in an overall lower development velocity and an inconsistent user experience.<\/p>\n\n\n\n
Furthermore, when reusable components are built, there is no guarantee that the equivalent components are built on other platforms. For example, if iOS builds a
Button<\/code> component but Android and web don\u2019t have this same component, it can introduce more confusion and inconsistency for engineers and designers.<\/p>\n\n\n\nIf these reusable components are built on all platforms, there is no guarantee that designers are aware, nor that an equivalent component exists in their design tool: Figma. This can lead to churn redesigning an existing component, which in turn can lead to further code duplication and a fractured user experience.<\/p>\n\n\n\n
Finally, even if all platforms have implemented a component and designers are aware of each platform\u2019s individual capabilities, there is still no guarantee that the components are implemented with the same look and feel on all platforms. This too can lead to confusion, asymmetrical effort spent on different platforms depending on the state of the component, and an inconsistent user experience across platforms.<\/p>\n\n\n\n
In the face of these growing challenges, we decided it was the right time to begin a concerted design system effort at Wealthfront.<\/p>\n\n\n\n
The design vision<\/h2>\n\n\n\n
Before immediately jumping into building the design system it was important to set the stage. The design team explored various future states and an overall design direction for the product. This initial exploration directly inspired many of the components that are currently being used in our design system and the current state of the product.<\/p>\n\n\n\n
![\"screenshot](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/Design-system-vision-1024x688.png\")
<\/figure>\n\n\n\nThe design vision solidified the north star for the initial phase of building the design system. It also helped gather support and excitement from engineers, designers, product, and leadership.<\/p>\n\n\n\n
Usually, coupling two large initiatives \u2013 the initial phase of the design system and a product-wide refresh \u2013 can be a recipe for disaster. However, in this scenario, it actually helped to showcase design system progress and encourage adoption of components. If the design system standardized on the existing product it would be hard to differentiate what is and is not using the design system. It also quickly demonstrated the benefits of a design system to iteratively uplevel the entire product instead of a single feature. <\/p>\n\n\n\n
With this design vision in mind, the next step was to define the design system team\u2019s mission to determine how to prioritize this and future work.<\/p>\n\n\n\n
The design system mission<\/h2>\n\n\n\n
The team vision has evolved since initially setting out, but the core tenets remain the same:<\/p>\n\n\n\n
\u201cThe Design System team\u2019s mission is to raise the quality bar of our products while improving consistency for our clients and productivity of both engineers & designers. We do this by building tools, frameworks, and processes that empower our product teams to deliver more cohesive experiences and make our products easier to maintain.\u201c<\/em><\/p>\n\n\n\n
This mission guides prioritization and decision making within the design system team. For example, which components to work on before others, which frameworks would be most beneficial, or how to improve processes. <\/p>\n\n\n\n
With a clear vision and mission, it was time to execute.<\/p>\n\n\n\n
Building a multi-platform design system<\/h2>\n\n\n\n
In the past, there were often significant visual or functional product feature differences between the platforms. In addition to unifying features across a platform, an initial motivation for the design system was to unify features across platforms. Providing the same fundamental building blocks \u2013 design system components \u2013 on all platforms makes this possible.<\/p>\n\n\n\n
Therefore, we aimed to build a multi-platform, cohesive design system<\/a>. When creating new components or frameworks we start from a single point, and then consider modifications that respect each platform\u2019s standards when appropriate. This helps ensure a unified experience across platforms, as opposed to starting from multiple points and working backwards. It provides a predictable experience for clients (even when switching between platforms), and allows designers to design once, instead of two or three times. While not entirely accurate, you might say this is a \u201cdesign once, build anywhere\u201d approach.<\/p>\n\n\n\n
For example, the
Dialog<\/code> on web floats in the center of the screen on desktop, but its counterpartBottomSheet<\/code> on mobile is attached to the sides and bottom of the screen.<\/p>\n\n\n\n![\"screenshot](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-dialog-1024x511.png\")
<\/figure>\n\n\n\nThey are still cohesive since they share the same design tokens<\/a>: padding, border radius, colors, and typography. However, the exact positioning respects each platform\u2019s existing standards to match user expectations.<\/p>\n\n\n\n
In the same way we aim to create cohesive components across platforms, we aim to do the same for each component\u2019s API across platforms.<\/p>\n\n\n\n
Multi-platform API design<\/h3>\n\n\n\n
One of the most important parts of a successful multi-platform design system component library is a cohesive API on all platforms, ideally identical. This has two primary motivations. <\/p>\n\n\n\n
First, it guarantees all components have similar options which means it can support the same functionalities and will likely have similar edge cases. The chances that something else is visually or functionally different increases if the API is different across platforms.<\/p>\n\n\n\n
A second but equally important motivation is to create a standardized vocabulary for all designers and engineers. For example, when a designer describes \u201ca callout card with a small heading, body text, and primary button with large spacing between<\/em>\u201d, other designers and engineers should be able to easily translate this into code on their respective platform. Below is an example of how this might be translated into design system components on web and how similar code would be rendered on each platform.<\/p>\n\n\n\n
<Card variant=\"callout\">\n <Stack spacing=\"large\">\n <Heading variant=\"small\" as=\"h2\">\n This is a Card\n <\/Heading>\n <Text>Cards are ways...<\/Text>\n <Button variant=\"primary\" as=\"button\">\n Got it\n <\/Button>\n <\/Stack>\n<\/Card><\/code><\/pre>\n\n\n\n![\"example](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-card-1024x687.png\")
<\/figure>\n\n\n\nAndroid and iOS have equivalent component counterparts that can be used to construct the same UI.<\/p>\n\n\n\n
The exact process we follow for drafting these APIs is shared further below. Before that, let\u2019s discuss the advantages and disadvantages of building a multi-platform design system. <\/p>\n\n\n\n
Advantages<\/h3>\n\n\n\n
Arguably the biggest benefit of multi-platform design systems is that it requires taking a step back from platform specifics and thinking through components from first principles. If building a web-only design system, it can be easy to never question web standards or specifications. However, in order to build an effective multi-platform design system, you must <\/em>do so.<\/p>\n\n\n\n
For example, a
Button<\/code> andLink<\/code> can be popular components on web that map to nativebutton<\/code> anda<\/code> (anchor) elements. From a design perspective these can often be treated as conceptually equivalent: a user clicks something and it does something. Implementing this only on web may result in two components with duplicated styling. However, when also considering Android and iOS which don\u2019t make this same distinction, it raises the question if two distinct components on web are necessary.<\/p>\n\n\n\nAs a result of taking a step back and considering all platforms, we instead have a single
Button<\/code> component on web that supports rendering as either an anchor or button element for the important semantic differentiation. This allows designers to conceptually think about one component, without needing to consider whether they are linking to another webpage or performing an action on web.<\/p>\n\n\n\nAnother benefit of building a multi-platform design system is sharing platform or framework patterns across platforms. For example, the flexibility and composition that React provides encourages a certain way of thinking about components that can inspire API patterns which impacts the component on all platforms. Longer term, we\u2019re excited about Jetpack Compose and SwiftUI which have more in common with React, potentially leading to even further component cohesion across all platforms.<\/p>\n\n\n\n
While the platform differences can provide plenty of advantages, they bring with them their own disadvantages.<\/p>\n\n\n\n
Disadvantages<\/h3>\n\n\n\n
Each platform has differences that can arise in various situations and impact visuals, functionality, or API design. Some of the more common differences include:<\/p>\n\n\n\n
- Differing standards<\/strong>:<\/em> for example, each platform has slightly different specifications and exceptions for tap area targets. When designing smaller components that get close to these minimum sizes we need to reconcile these differences. The simplest is to pick the largest minimum since this guarantees the others are met as well. Accessibility is only one aspect; every platform has varying standards across the spectrum.<\/li>
- Differing languages<\/strong>:<\/em> Kotlin on Android, Swift on iOS, and TypeScript on web. They each provide some level of type safety which is always a benefit when consuming or refactoring components in a design system. However, the differences in the type systems can introduce their own API design challenges. For example, on Android we avoid XML for complex APIs due to limited type safety. Instead, the API is written in Kotlin to take advantage of powerful language-level constructs like sealed types. On web with React and TypeScript, it\u2019s not possible to restrict child components to only certain types. As a result, the type definitions are more permissive than what is allowed in practice so some of these constraints are runtime checks which run only in development builds.<\/li>
- Differing frameworks and paradigms<\/strong>:<\/em> while having different frameworks or paradigms can be an advantage to provide multiple perspectives and provide inspiration, it also requires reconciling these differences. For example, React and TypeScript are less strict so it\u2019s easy to provide flexible APIs. This is convenient for APIs that need to be flexible, but becomes a challenge for APIs that need to be more restrictive.<\/li><\/ul>\n\n\n\n
At the end of the day, while building a multi-platform design system may require additional effort, it does result in an overall better design system.<\/p>\n\n\n\n
Component creation process<\/h2>\n\n\n\n
One of the first and most important processes to define early on was for component creation. We experimented with a few approaches, but settled on the process we\u2019re using today.<\/p>\n\n\n\n
The first decision is where something should live. Should it be a new design system component? Should it be added to an existing design system component? Should it be a feature-specific custom component?<\/p>\n\n\n\n
The following flow chart is a high-level summary of how we approach thinking about adding new components to the design system.<\/p>\n\n\n\n
![\"flowchart](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-flow-1024x681.png\")
<\/figure>\n\n\n\nOnce a decision has been made to add or update a design system component, the next step is a design-focused component sheet proposal.<\/p>\n\n\n\n
Design component sheet proposal<\/h3>\n\n\n\n
The component sheet proposal is a design-led exercise to explicitly list the specifications, or design tokens, to use for typography, spacing, and colors. It also includes an exhaustive exploration of use cases and the variants those different use cases introduce. <\/p>\n\n\n\n
![\"example](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-component-proposal.png\")
<\/figure>\n\n\n\n![\"exploration](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-component-example-1024x537.png\")
<\/figure>\n\n\n\nThe specifications expedite implementation and ensure all platforms are using the same design tokens, which results in a cohesive experience across platforms and across the design system. The variants define exactly which options will need to be supported which ties directly into the next step.<\/p>\n\n\n\n
Engineering component API proposal<\/h3>\n\n\n\n
This step is an engineering-led exercise to explicitly define the public API based on all the variants defined in the design component sheet. <\/p>\n\n\n\n
Naming is one of the critical parts of this step. We survey existing design systems, existing platform specifications, and anywhere else we can draw inspiration. There isn\u2019t a single rule, but we usually follow these guidelines:<\/p>\n\n\n\n
- If there is an existing, widely accepted component name that maps well on all platforms, it will be used. For example, a
Card<\/code> component. <\/li>- If there is not an existing name that maps well on all platforms, we intentionally avoid any existing platform-specific names to avoid confusion. For example, the
SummaryList<\/code> component is similar to the description list element on web<\/a>, so we chose not to use that name. This avoids confusion by overloading this meaning on web and by bringing web specifications to mobile platforms. Instead,SummaryList<\/code> provides a similar meaning without implying any existing definitions.<\/li>- If there are existing but unique names per platform that also align with the component and platform differences, they will be used. Some examples include the
Dialog<\/code> on web and theBottomSheet<\/code> on Android and iOS.<\/li><\/ul>\n\n\n\nThis naming strategy also applies to all the options and values for each component, although that\u2019s typically easier. Without this process, it wouldn\u2019t be possible to have the shared vocabulary mentioned earlier.<\/p>\n\n\n\n
The other critical part of this step is the actual API and options. Typically, we brainstorm several API proposals that approach the component from different perspectives. Some are more general, whereas others are more specific. Exploring multiple APIs and perspectives can uncover interesting insights such as additional use cases or unexpected connections to other components.<\/p>\n\n\n\n
There are a few principles we keep in mind when designing component APIs:<\/p>\n\n\n\n
- Consistency<\/strong>:<\/em> for example, when there is a generic slot for any component, we use the term \u201ccontent.\u201d This can show up in component options as
primaryContent<\/code>,secondaryContent<\/code>,helperContent<\/code>, ortrailingContent<\/code>. This cross-component consistency can help imply how a component\u2019s option should be used before reading any documentation or relying on types.<\/li>- Simplicity<\/strong>:<\/em> ideally, the API is simple. This means there are minimal options, impossible states are impossible<\/a>, and the API is self explanatory. Typically, this comes down to iteration. Simplicity takes time.<\/li>
- Flexible versus opinionated<\/strong>:<\/em> the design requirement should be reflected in the API. If the design has loose requirements or treats things as containers, a generic slot that accepts arbitrary content is a flexible pattern. It inverts the control<\/a> of what is rendered to the consumer of the component. On the other hand, if the design has strict requirements, the API should be restricted to only those options. While it may seem obvious, this is important to get right. Providing an API that is too flexible for something intended to be opinionated can result in unexpected uses, maintenance headaches, and frustration for engineers consuming the design system. The opposite is also true: providing an API that is too opinionated that was intended to be flexible leads to the same problems.<\/li>
- Accessibility<\/strong>:<\/em> it\u2019s important to intentionally consider accessibility while designing the API. This can surface in many ways, such as the actual naming of options, removing potentially inaccessible functionality, or adding new options specifically for accessibility. For example, on web, a single component can map to multiple HTML elements so we expose an
as<\/code> option to control which underlying element is rendered. We do this for both theButton<\/code> andText<\/code> components.<\/li>- Platform implications<\/strong>:<\/em> for example, avoiding reserved keywords on different platforms. With the
SummaryList<\/code>, we considered akey<\/code> option, but this isn\u2019t possible on web since that is one of only two special React props<\/a> that can\u2019t be used.<\/li><\/ul>\n\n\n\nThe exact design and engineering process and patterns are constantly evolving, but these are the core themes that are commonly considered or commonly arise.<\/p>\n\n\n\n
Component prototype<\/h3>\n\n\n\n
A component prototype is typically done on at least one platform with the proposed API. It can help uncover unexpected edge cases, challenges with the API, or challenges with the way the component was designed. It\u2019s also a good opportunity to test different interactions or animations that can be challenging in Figma.<\/p>\n\n\n\n
This step is usually done in parallel with the previous engineering API proposal step.<\/p>\n\n\n\n
Implementation<\/h3>\n\n\n\n
Once all of the previous steps have been completed and finalized with the team, the last step is implementation. <\/p>\n\n\n\n
The design component sheet proposal and engineering API proposal provide all of the visual, functional, and technical details to implement the component on all platforms. The implementation step also includes appropriate testing (unit tests, screenshot tests, screen reader tests), documentation (component galleries in the mobile apps, Storybook on web), and migration if necessary.<\/p>\n\n\n\n
There are commonly unknowns that arise during implementation, so we loop back to the appropriate previous step depending on the issue.<\/p>\n\n\n\n
We\u2019ve found this general process balances the overall effort with multi-platform cohesion. Skipping one of these steps can result in inconsistent components, behavior, or API on the different platforms.<\/p>\n\n\n\n
Current state of the design system<\/h2>\n\n\n\n
Since the inception of the design system, we\u2019ve built many of the core components needed across the app such as the
Button<\/code>,Card<\/code>, andTextField<\/code>. There are always new components to build, but we\u2019ve recently been spending more time outside of only building components.<\/p>\n\n\n\nThe blog post Creating Components For Mature Design Systems<\/em><\/a> provides the following categorization for different design system stages.<\/p>\n\n\n\n
![\"the](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-stages-1024x250.png\")
<\/figure>\n\n\n\nAccording to this framework, we\u2019re probably somewhere between an early stage system and a medium stage system. This means we spend less time building components and more time gathering context, (re)defining, and auditing. Recently, we have spent more of our time building the broader design system ecosystem, such as tooling and frameworks. <\/p>\n\n\n\n
Examples<\/h2>\n\n\n\n
That covers a lot of the history and processes, but doesn\u2019t provide any concrete examples. Below are a few examples of design system components and related projects.<\/p>\n\n\n\n
TextField component<\/h3>\n\n\n\n
The
TextField<\/code> is one of the most common types of input. It\u2019s fairly standard in that it\u2019s similar to many other text field components in other design systems. For example, it contains a label, optional placeholder, optional leading icon, optional trailing content, optional helper content, and optional error message.<\/p>\n\n\n\n![\"text](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-label.gif\")
<\/figure><\/div>\n\n\n\nBy default, the
TextField<\/code> allows any typed input. At Wealthfront, there are several types of inputs that are common across the product and can benefit from additional formatting to improve the client experience.<\/p>\n\n\n\n![\"text](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-text-field-1024x179.png\")
<\/figure><\/div>\n\n\n\nAs a result, there are also several formatted
TextField<\/code> components for telephone input, social security number input, and a dollar amount input. These are all extensions on top of theTextField<\/code> so additional formatted input types can be easily added as needed.<\/p>\n\n\n\nSummaryList component<\/h3>\n\n\n\n
A less common component seen in other design systems is the
SummaryList<\/code> component. It\u2019s used to display a summary of data in a list. This is commonly used to display metadata about an entity.<\/p>\n\n\n\n![\"summary](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-summary-list.png\")
<\/figure><\/div>\n\n\n\nOn smaller screens, each item\u2019s key and value are on the same row with the items stacked. However, on larger screens like desktop web this can result in a lot of wasted space. Therefore, this component contains a column option that only applies on larger screens to take advantage of this additional space by rendering the items in more than one column. This is an example of taking platform considerations into account to improve components on a given platform.<\/p>\n\n\n\n
Color system and theming<\/h3>\n\n\n\n
A recent non-component based example of a larger design system project was revamping our color system. Last year, the brand colors were revised and are now widely used on the marketing site. Before now, these colors hadn\u2019t made their way into the design system. <\/p>\n\n\n\n
The motivation of this project was to introduce these new brand colors as distinct themes. While mobile already supported light and dark mode theming, web did not. Before this project could even begin, we had to deprecate IE 11 support and adopt CSS Variables<\/a> which enable theming on web. Once all platforms supported theming, the next step was to update those themes.<\/p>\n\n\n\n
![\"color](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-light-theme-1024x472.png\")
<\/figure><\/div>\n\n\n\n![\"color](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2022\/05\/design-system-dark-theme-1024x472.png\")
<\/figure><\/div>\n\n\n\nDesign defined an algorithm that accepted a handful of our brand colors and generated a robust, accessible theme based on those inputs. The algorithm was converted to a script which allows us to generate arbitrary themes based on our brand colors. It includes contrast checking common background and foreground color pairings and output for all platforms: XML for Android, JSON for iOS, and a Stylesheet with CSS Variables for web.<\/p>\n\n\n\n
Another big benefit of this new color system is nested theming. With the way the color system was structured and designed, it\u2019s possible to theme subsections of pages or individual components. For example, a theme can be applied directly to the
Card<\/code> component to make it visually unique while still being accessible and visually aligned with the rest of the product.<\/p>\n\n\n\nConclusion<\/h2>\n\n\n\n
While a design system is constantly evolving, we are excited to share the progress we have made so far on this journey. It\u2019s helped improve the consistency throughout the product across platforms, provided a standardized vocabulary, and increased our velocity.<\/p>\n\n\n\n
If working on an evolving design system sounds interesting to you, or you want to help build a financial system that favors people, not institutions<\/a> in another way, check out our careers page<\/a> for current opportunities!<\/p>\n\n\n\n
\n\n\n\nDisclosures<\/h3>\n\n\n\n
The information contained in this communication is provided for general informational purposes only, and should not be construed as investment or tax advice. Nothing in this communication should be construed as a solicitation or offer, or recommendation, to buy or sell any security. Any links provided to other server sites are offered as a matter of convenience and are not intended to imply that Wealthfront Advisers or its affiliates endorses, sponsors, promotes and\/or is affiliated with the owners of or participants in those sites, or endorses any information contained on those sites, unless expressly stated otherwise.<\/p>\n\n\n\n
All investing involves risk, including the possible loss of money you invest, and past performance does not guarantee future performance. Please see our Full Disclosure for important details.<\/p>\n\n\n\n
Wealthfront offers a free software-based financial advice engine that delivers automated financial planning tools to help users achieve better outcomes. Investment management and advisory services are provided by Wealthfront Advisers LLC, an SEC registered investment adviser, and brokerage related products are provided by Wealthfront Brokerage LLC, a member of FINRA\/SIPC.\u2002\u2002 <\/p>\n\n\n\n
Wealthfront, Wealthfront Advisers and Wealthfront Brokerage are wholly owned subsidiaries of Wealthfront Corporation.<\/p>\n\n\n\n
\u00a9 2022 Wealthfront Corporation. All rights reserved.<\/p>\n","excerpt":"Over the past two years at Wealthfront we\u2019ve been building a design system from the ground up across all our frontend platforms: Android, iOS, and web. If you\u2019re a Wealthfront client you may have noticed sweeping, iterative visual changes across our apps as we introduced new components and migrated features to adopt these components. At... Read more<\/a>","date":"2022-05-10 11:57:07","author":"Spencer Miskoviak","categories":["wealthfront engineering"],"tags":["android","design-systems","ios","web"]},{"id":2629,"title":"Halving iOS Test Time with Partitioning in Jenkins Pipelines","permalink":"https:\/\/eng.wealthfront.com\/2021\/02\/05\/halving-ios-test-time-with-partitioning-in-jenkins-pipelines\/","content":"\n
At Wealthfront, testing is core to the culture of our engineering organization and business. In fact, on the iOS team, testing is woven into our development process. We host and manage our own continuous integration (CI) pipeline on Jenkins which runs our unit and UI test suites. As most iOS developers know, UI tests take an order of magnitude longer to run than unit tests since they simulate a user interacting with the app. Recently, our UI test suite reached an untenable size, with 90 tests taking over an hour and a half to execute. As we scale our codebase and team (FYI we\u2019re hiring<\/a>), the need to minimize this execution time becomes paramount. To mitigate the cost of these tests, we decided to parallelize our UI test job across our CI build machines with the help of Jenkins Pipelines. <\/p>\n\n\n\n
Our Jenkins architecture<\/strong><\/h2>\n\n\n\n
Our CI environment contained 16 Mac Minis serving as Jenkins agents. Each merge to the git main branch kicked off three jobs: UI tests with mock data, UI tests hitting an isolated backend instance, and a master build, which itself parallelized the execution of our three unit test suites (Release, Beta, and Dev). This meant if no other jobs were running, such as a side branch build or an App Store deployment, only five of our 16 agents would be in use. These unused agents presented an opportunity to distribute the workload of our tests.<\/p>\n\n\n\n
![\"A](\"https:\/\/eng.wealthfront.com\/wp-content\/uploads\/2021\/02\/iOS-CI-setup.svg_-2-1024x314.png\")
A diagram of our Jenkins setup<\/figcaption><\/figure><\/div>\n\n\n\n The plan to parallelize<\/strong><\/h2>\n\n\n\n
Parallelizing UI tests involved partitioning our UI test suite into a given number of divisions, running each division on an agent, and collecting the results once every division had finished. This seemed simple in theory but came with two big challenges during implementation: how do we construct the n-divisions of tests and how can we actually run each division in parallel?<\/p>\n\n\n\n
Dividing our tests<\/strong><\/h2>\n\n\n\n
Partitioning an array of tests is easy enough, but constructing the array in the first place posed a challenge. We knew our array should contain all test classes in our UI test scheme, since the testing tool we use in CI, Fastlane's scan<\/a>, can consume a list containing a subset of test cases to be run, of the form
Test Bundle[\/Test Suite[\/Test Case]], \u2026<\/code>\u00b9. This can be accomplished using theonly_testing<\/code> parameter, and in our case an example list might look like:[WealthfrontUITests\/CollegeGoalUITest, WealthfrontUITests\/AccountTransferInitiationUITest, \u2026]<\/code>\u00b2. <\/p>\n\n\n\n\n
desc \u201cRun UI Tests on iPhone 11 Pro\u201d\nlane :ui_tests\n tests_to_run = options[:only_testing]\n clear_derived_data(derived_data_path: derived_data_path)\n sh(\u201cxcrun simctl shutdown booted\u201d)\n sh(\u201cxcrun simctl erase all\u201d)\n sh(\u201cxcrun instruments -w \u2018iPhone 11 Pro (13.3) [\u2018 -t Blank\u201d)\n scan(workspace: \u201cWealthfront.xcworkspace\u201d,\n scheme: \u201cWealthfrontUITests\u201d,\n output_style: \u201cbasic\u201d,\n devices: [\u201ciPhone 11 Pro\u201d],\n clean: true,\n derived_data_path: derived_data_path,\n skip_build: true,\n only_testing: \"#{tests_to_run}\")\n sh(\u201cxcrun simctl shutdown booted\u201d)<\/code><\/pre>\n<\/p>\n\n\n\nA snippet of our Fastfile<\/p>\n\n\n\n
But how might we get the full list of test cases to partition? As it stands, neither
xcodebuild<\/code> nor Fastlane provides a way of querying the tests in a given test bundle, so there's no help there. Facebook\u2019sxctool<\/code> does enable this through the-listTestsOnly<\/code> argument torun-tests<\/code>, however incorporating another third party library and rolling it out to all of our agents seemed unnecessary for such a small task\u00b3. Since all of our UI test files were located in the same folder we decided it would be simpler to parse and collect the class name from each one at test time. This way, new test files would be implicitly included in the job, so long as each file was in the proper directory. Below is the function we developed to construct the full array:<\/p>\n\n\n\n\n
def getAllUITestClassNames() {\n def allSwiftFiles = sh(\n script: \u201cfind WealthfrontUITests -name \u2018*.swift\u2019\u201d,\n returnStdout: true\n ).trim().split(\u2018\\n\u2019) as String[]\n def directory = pwd()\n def allClassNames = []\n allSwiftFiles.each {\n def file = readFile \u201c${directory}\/${it}\u201d\n def matcher = (file =~ \/(?<=class ).*?(?=:)\/)\n if (matcher.count > 0) {\n allClassNames += matcher[0]\n }\n }\n def testClassNames = allClassNames.findResults { \n it.endsWith(\u201cUITest\u201d) || it.endsWith(\u201cIntegrationTest\u201d) ? it : null\n }\n return testClassNames\n}<\/code><\/pre>\n<\/p>\n\n\n\nWith the list of all test cases, we could then partition the list into n buckets of equal size (excluding the remainder if n did not divide the number of test cases), and move on to the execution of the tests.<\/p>\n\n\n\n
\n
def partitionTestClassNames(classNames, buckets) {\n def subArrays = []\n def bucketSize = classNames.size() \/ buckets\n for (int i = 0; i < buckets; i++) {\n def start = i * bucketSize\n def end = i == buckets - 1 ? classNames.size() : start + bucketSize\n subArrays += [classNames[start..<end]]\n }\n return subArrays\n}<\/code><\/pre>\n<\/p>\n\n\n\nRunning in parallel<\/strong><\/h2>\n\n\n\n
Our UI test job was configured through the Jenkins classic UI and consisted mainly of a Build shell script which executed our Fastlane Lane. We were limited in that our job could not take advantage of Jenkins\u2019 parallelization capabilities<\/a>. The only way to accomplish this was to move to a Jenkins Declarative Pipeline<\/a>, in which the building, testing, and deployment of our code all resided in a single
Jenkinsfile<\/code>. In addition to supporting parallel execution of stages, Declarative Pipelines have the added benefit of defining a job in Groovy code. Our Jenkins job was defined through the web interface which, though technically versioned, cannot be reviewed in the same manner as our source code. With Declarative pipelines, the process of building and testing our code lives side-by-side with our source code. <\/p>\n\n\n\nThe first iteration of our
Jenkinsfile<\/code> consisted of two stages, the first of which constructed a partition of test cases using the logic described previously, while the second farmed out the divisions of the partition to run on three agents and reported the results. The following is an abbreviated version of ourJenkinsfile<\/code>. <\/p>\n\n\n\n\n
partitioned_test_cases = []\n \npipeline {\n environment {\n TARGET_PARALLEL_AGENTS = 3\n }\n \n stages {\n stage(\u201cPartition UI tests\u201d) {\n steps {\n script {\n def testClassNames = getAllUITestClassNames()\n def testClassNamesWithSuite = testClassNames.collect { \u201cWealthfrontUITests\/${it}\u201d }\n def partition = partitionTestClassNames(testClassNamesWithSuite,\n env.TARGET_PARALLEL_AGENTS as Integer)\n partitioned_test_cases = partition \n }\n }\n }\n \n stage(\u2018Parallel Execution\u2019) {\n steps {\n runTestsInParallel()\n }\n }\n }\n}\n \ndef runTestsInParallel() {\n def numBranches = partitioned_test_cases.size()\n def branches = [:]\n for (int i = 0; i < numBranches; i++) {\n def branchName = \u201c${i + 1}\/${numBranches} branch\u201d\n def index = i\n branches[branchName] = {\n node (\u2018iOS\u2019) {\n sh(\u201cfastlane ui_tests only_testing:${testCases}\u201d)\n junit(allowEmptyResults: true, testResults: \u2018fastlane\/test_output\/*.junit\u2019)\n }\n }\n }\n \n parallel branches\n}\t<\/code><\/pre>\n<\/p>\n\n\n\nNote: As you can see in the
runTestsInParallel<\/code> method, we dynamically construct the branches, each of which corresponds to a parallel execution of tests. Alternatively, we could have defined a fixed number of stages in place of the \u2018Parallel Execution\u2019 stage, but instead we now have the flexibility to update the target number of parallel agents with a single line change of our environment variable.<\/p>\n\n\n\nMeasuring the results<\/strong><\/h2>\n\n\n\n
With our UI test job fully defined, we could now see the impact of our improvements. The old job regularly ran longer than 90 minutes, while the updated job ran for only 40 minutes on average\u2074. Using only two more of our available agents, we gained more than a 50% improvement. <\/p>\n\n\n\n
But is this the best we can do? You may have noticed that our partitioning logic simply slices our list of test cases, ordered by the output of
find<\/code> (which makes no ordering guarantee), into equal divisions weighted by number of test cases. Our divisions happened to be similar in execution time, but it\u2019s plausible that in the future, one arbitrary division might contain test cases with many long-running test methods. This would lead to a branch that would run much longer than the rest, extending the overall job and defeating the purpose of parallelization. Thus, if our goal was to minimize total execution time, we should aim to minimize the range of execution time between our branches.<\/p>\n\n\n\nOne last improvement<\/strong><\/h2>\n\n\n\n
Enter the Parallel Test Executor Plugin<\/a>. This helpful Jenkins plugin analyzes the previous run of the job and partitions the job\u2019s tests weighted by execution time, meaning we can delegate the work of balancing our tests. The only work on our end then becomes tacking on any newly added tests (as they weren\u2019t part of the previous run) and formatting the plugin\u2019s output for consumption by Fastlane. Below is the abbreviated, second iteration of our
Jenkinsfile<\/code>.<\/p>\n\n\n\n\n
partitioned_test_cases = []\n\npipeline {\n agent { label \u2018iOS\u2019 }\n\n environment {\n TARGET_PARALLEL_AGENTS = 3\n }\n\n stages {\n stage(\u2018Partition UI Tests\u2019) {\n steps {\n script {\n \/\/ Parallel Executor Plugin (PEP) returns one extra empty split if generateInclusions == true\n def parallelism = count((env.TARGET_PARALLEL_AGENTS as Integer) + 1)\n def splits = splitTests parallelism: parallelism, \n estimateTestsFromFiles: true,\n generateInclusions: true\n\n def includedSplitLists = splits.findAll { it.includes }.collect { it.list }\n \/\/ PEP adds Java extensions to test cases\n def formattedSplitLists = includedSplitLists.collect{ it.collect { it.minus(\u201c.class\u201d).minus(\u201c.java\u201d) }.unique() }\n\n if (formattedSplitLists.size() == 0) {\n \/\/ `splitTests` found nothing in the previous build\n (env.TARGET_PARALLEL_AGENTS as Integer).times {\n formattedSplitLists.push([])\n }\n }\n\n def allTestClassNames = getAllUITestClassNames()\n def testClassNamesWithScheme = allTestClassNames.collect { \u201cWealthfrontUITests\/${it}\u201d }\n\n def allTestClassNamesFromPreviousBuild = formattedSplitLists.flatten()\n def testClassNamesNotPreviouslyTested = testClassNamesWithScheme - allTestClassNamesFromPreviousBuild\n\n \/\/ Add residual tests not in previous build, or naively partition tests if plugin found no test results in previous build\n def index = 0\n for (int i = 0; i < testClassNamesNotPreviouslyTested.size(); i++) {\n formattedSplitLists[index % formattedSplitLists.size()] += testClassNamesNotPreviouslyTested[i]\n index++\n }\n\n partitioned_test_cases = formattedSplitLists\n }\n }\n }\n\n stage(\u2018Parallel Execution\u2019) {\n steps {\n runTestsInParallel()\n }\n }\n }\n}<\/code><\/pre>\n<\/p>\n\n\n\nWe actually observed little difference in total execution time with this new plugin, but we can be confident moving forward that our test job will automatically adjust and adapt as our test base scales.<\/p>\n\n\n\n
Learnings & Future Directions<\/strong><\/h2>\n\n\n\n
In summary, we found how to leverage CI infrastructure to lower the cost of expensive jobs and realized the benefits of describing jobs in code. In the future, we will likely add one more level of parallelization by running UI tests concurrently on a single agent, a process Apple made quite simple in Xcode 10<\/a>. <\/p>\n\n\n\n
If this work interests you or if you have thoughts on how we might make it even better, check out our careers page<\/a>!<\/p>\n\n\n\n
Resources<\/strong><\/h2>\n\n\n\n
- Faster Pipelines with the Parallel Test Executor Plugin<\/a><\/li>
- Pipeline Syntax<\/a><\/li>
- Pipeline as Code with Jenkins<\/a><\/li>
- Technical Note TN2339: Building from the Command Line with Xcode FAQ<\/a><\/li><\/ul>\n\n\n\n
Notes<\/strong><\/h2>\n\n\n\n
- A note on testing nomenclature: Apple uses the
Test Target > Test Class > Test Method<\/code> naming convention to refer to the structure of tests in Xcode, while Fastlane usesTest Bundle > Test Suite > Test Case<\/code> to refer to the same hierarchy. Hereafter, when we mention our UI test suite, we mean the collection of all UI test methods in our UI test bundle.<\/li>- We could have partitioned our tests at the granularity of test method, however it would introduce the overhead of calling the class methods
XCTestCase.setup()<\/code> andXCTestCase.tearDown()<\/code> once for each agent the test case was distributed on, instead of exactly once.<\/li>xctool<\/code> is also losing support as an CI build tool.<\/a><\/li>- Since there is a fixed overhead of building the application for testing on each agent that runs a subset of tests, we cannot expect the execution time to be cut by two-thirds to 30 minutes.<\/li><\/ol>\n\n\n\n
\n\n\n\nDisclosure<\/strong><\/h3>\n\n\n\n
- We could have partitioned our tests at the granularity of test method, however it would introduce the overhead of calling the class methods
- Pipeline Syntax<\/a><\/li>
- Simplicity<\/strong>:<\/em> ideally, the API is simple. This means there are minimal options, impossible states are impossible<\/a>, and the API is self explanatory. Typically, this comes down to iteration. Simplicity takes time.<\/li>
- If there is not an existing name that maps well on all platforms, we intentionally avoid any existing platform-specific names to avoid confusion. For example, the
- Differing languages<\/strong>:<\/em> Kotlin on Android, Swift on iOS, and TypeScript on web. They each provide some level of type safety which is always a benefit when consuming or refactoring components in a design system. However, the differences in the type systems can introduce their own API design challenges. For example, on Android we avoid XML for complex APIs due to limited type safety. Instead, the API is written in Kotlin to take advantage of powerful language-level constructs like sealed types. On web with React and TypeScript, it\u2019s not possible to restrict child components to only certain types. As a result, the type definitions are more permissive than what is allowed in practice so some of these constraints are runtime checks which run only in development builds.<\/li>
- Discoverability<\/strong> of available options is easy<\/li>\n\n\n\n
- Abstracting away the complexity of image build commands deprives engineers of the opportunity to learn the build commands<\/strong> and can inadvertently build knowledge silos. A motivated engineer can learn the image build commands but we won't be giving them a natural on-ramp to learn them.<\/li>\n\n\n\n