A Foray into Relay
In the first session of Android Dev Summit 2022, we heard about the newly rebranded and spruced up Material Design To Code, now known as Relay. Relay provides instant handoff of Android UI components between designers and developers, taking packaged components from Figma, and generating Android Compose code for use in your apps!
Design to developer handoff has been a hotly talked about topic in recent years, and this announcement stirred up a bunch of questions online. Everything from implementation details like “how does this work with X?”, to architectural concerns like “does this introduce coupling woes?” and “what about iOS?”, all boiling down to the question of “Who is this for?”. I teamed up with Ben Wright, a designer at Sharesies, to experiment with Relay and come up with some answers!
Relay consists of a Figma Plugin for designers, and an Android Studio Plugin, plus a Gradle Plugin for developers. Once set up, the workflow for handing off UI from designers to developers is pretty simple:
- Package up a component in Figma, specifying parameters
- Import the UI package in Android Studio, using a link to the Figma file
- Build your project, and start using the generated code
These three steps seem pretty simple, and in our experience it did exactly what it said on the tin. Let’s look at an example!
Note, we’re going to skip the set up bit and just straight to using it, but for easy reference, here’s how to get set up.
Implementing a simple component with Relay
In the Sharesies app, we have a banner component in our design system which we use for surfacing important, succinct and actionable messages to users. An example of this lives in our notifications setting screen, we show a banner if notifications are disabled at a system level.
This component already existed in our design system and is relatively simple while allowing us to exercise all the capabilities of Relay, so it felt like a great option to try out.
We started in Figma, packaging the component up into light and dark mode variants, and assigning parameters to the things we want developers to be able to control. We found that a lot of parameters were already half-way filled out, with field-types in Figma being used to divine which types the parameters should be. Neat!
From here we were done in Figma, and could move over to Android Studio.
Dropping in our Relay Banner
We then moved on to importing the component into our project as a UI package. This was also pretty easy to sort out by following the basic tutorial for importing designs as code. We followed the steps, hit build, and found a bunch of generated code. Great success!
This generated code was a touch verbose when reading through it, but the developer API it produced was nice and succinct, matching the packaged component nicely.
Banner(
title = “Title”,
body = “Body body. The quick brown log jumped over the lazy fox”,
action = “Action”,
onAction = {}
)We then dropped the generated banner into a @Preview, and checked it out alongside our hand-rolled implementation.
There’s a few discrepancies here, which makes a bunch of sense! We’re using a completely custom theme implementation in the Sharesies app, with typefaces not found on Google Fonts. This largely follows the same structure as MaterialTheme, but it’s not a material theme and so our styling doesn’t flow down to composables within the banner automatically.
Theme mapping
To resolve our theme issue, we looked to an experimental feature of Relay, Mapping Styles to a Compose Theme. This feature allows us to map named styles in Figma, to tokens, and then from tokens to Compose theme properties. We’re able to override the type and package of the theme the generated code points to, which allowed us to point Figma styles directly to their Compose equivalents!
Mappings are defined in json, and provided to Relay when importing components. A mapping file looks a little like this:
{
"figma": {
"colors": {
"Label/Light/Primary": "sh.sys.color.label-primary",
...
},
"typography": {
"symbols": {
"android/label": "sh.sys.typescale.label",
},
"subproperties": {
// Omitted for brevity
}
}
},
"compose": {
"colors": {
"sh.sys.color.label-primary": "Theme.color.label",
...
},
"typography": {
"symbols": {
"sh.sys.typescale.label": "Theme.text.label",
},
"subproperties": {
// Omitted for brevity
}
},
"options": {
"packages": {
"Theme": "nz.sharesies.core.ui.theme"
}
}
}
}As you can see, there’s two different mappings going on here. We first convert from Figma-defined styles, to generic tokens in the `figma` object. We then map from tokens to Compose theme references in the `compose` object, specifying some additional options to allow the Relay compiler to import and reference the right class. Note, we’ve omitted some typography subproperty mapping here for brevity. For a fully featured example, check out the mapping files used for the Material Design Kit.
Re-importing our component and building the app shows no change to our code, but our preview now looks like we expect!
With theme mapping working, our component now has a source of truth in our Figma-based design system. From here, updating our component when the system changes is as simple as clicking a button in Android Studio.
A review of Relay: Questions answered
All in all, using Relay was very seamless. Libraries and tooling in Android can be hit-or-miss when in alpha, but given Relays history as Material Design to Code a lot of the tooling feels stable and functional.
Overall Relay feels like a well thought out tool. It allows you to use your versioned design system components in Figma as the source of truth, which is great from a design system perspective. This requires a pretty rigorous process on designers working with the system, which can be pretty easily manageable depending on your context.
Using Relay is definitely faster than building components by hand, however, you do miss out on some of the benefits of hand rolling, like being very deliberate with interaction & accessibility handling. It did require more communication between design and development to settle on things like naming of parameters, but the time-saving afforded from not having to write code outweighed it.
What about iOS?
Relay doesn’t support iOS. However, if we look at how platform-agnostic the theme mapping system appears to be, it’s not crazy to imagine there being Swift UI support in some version of the future. Even without iOS support, packaging up components for Relay in Figma is easy enough that it’s feasible to do it for just the one platform. If your circumstances allow it, it’s shouldn’t be a deal breaker that there’s no iOS support.
Coupling and lock-in
Some huge downsides of this approach is coupling and lock-in. Moving a source-of-truth to a system outside of your codebase has a bunch of inherent risk associated with it, especially around compatibility, which is where the coupling downside comes in. For example, if Figma changes and breaks the Relay plugin you’ll be unable to update components until Relay is updated. Equally, if you let your codebase get out of date, there’s a good chance you’re going to need to do work to bring it back to compatibility with the Relay Figma plugin.
Lock-in is another obvious disadvantage of this approach. Relay relies on Figma as your designers tool of choice for designing and maintaining a design system. If this was to change in a couple of years time due to the release of newer, better tooling elsewhere, you’d either:
- Have to run two separate suites of design tools, or
- Reimplement your Android UI components manually, or
- Hope that Relay is maintained, and supports the new suite of design tooling
These downsides can be mitigated if you’ve got dedicated time to spend on design system work, and a design system comprehensive enough to warrant this kind of treatment, however this is going to be quite subjective. This leads us into the next and final question: Who is this for?
Who is this for?
So — Relay is Android only, fairly robust and well thought out, and requires a Figma-based, well-versioned design system. Not every company is in the right stage of scaling to make this solution worth-while — let’s look at some examples.
Small teams or solo devs
At Sharesies, we’re a pretty small mobile team. Overall we consist of eight people, four of which are developers — two each for Android and iOS. We’re building out native functionality as fast as possible, while spending a bit of time an effort ensuring what we’re building is setting Sharesies up for the future. Part of this includes a design system, which has largely been owned within the team for the time being.
Given we’re a small team, moving fast and changing things frequently, our design system is pretty fluid. We change components and stylings as we develop more of an understanding of how the apps fit into the Sharesies brand, which can be quite frequent. Minimizing the amount of process we wrap around our work enables us to work quickly, instead leaning on good communication within the team to keep things aligned.
For smaller teams like ours, or for solo developers, Relay feels like more effort than it’s worth. Sure it writes the code for you, but Compose makes it so easy to write that code yourself that the additional workflow required to use it can actually make things slower.
A medium-to-large organisation
The story changes with larger organisations, where good process and well-defined communication pathways make things easier at scale. If you’re building a design system in a company with more that a couple of mobile teams, chances are you’re already following a process that fits the Relay way of working. In this case, Relay is almost a no-brainer — it saves developer time with little additional design effort, while also moving the systems source-of-truth to somewhere more canonical.
As you get to the larger end of the scale, Relay might begin to offer less benefits again. With some of the larger mobile development companies in the world, you’ll find teams dedicated to providing a well-refined, fully accessible design system for other teams. These teams will already have well-ingrained processes for design-to-developer handoff, and likely spend additional time fine-tuning their UI components to offer the best user and developer experience out there. Relay’s mapping components to existing code functionality may offer a little bit of additional value to these organisations, but otherwise I could see it being a hard sell.
Conclusions and reckons
To wrap up, here’s my reckons. Relay is a nifty tool which has the potential to save developers working with Compose and Design Systems a bunch of time. Limitations definitely exist, mostly due to it being pretty early days, however what’s there already could be beneficial depending on the size and shape of your mobile teams. If you’re too small or too big Relay probably isn’t the tool for you, but if you fit somewhere between “team of one” and “thousands of mobile developers” you’ll find something worthwhile in it.
If I had to speculate about where Relay is going, I see one of two paths. One path exists where Relay continues to do what it does, and does it really well — including functionality to model advanced interactive bits and pieces, and accessibility behaviour defined in Figma. Along this path we might see iOS support too. The other path is towards generalisation — allow Relay to produce entire screens rather than components, and use it for everything. The latter path scares me a little in that generalisation in software stretches polish thin, mostly leading to edge-cases upon edge-cases and missing features. I hope, and expect, that Relay takes the first path.
Relay is a fun solution — don’t just take my word for it, try it out! If you liked this post and want to see more, follow me on Medium. Alternatively, I’ll be cross posting to my own personal blog, and I occasionally tweet.
Portions of this page are reproduced from work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.
