Cross-platform distribution

[TrevorRice]

Hi all.

This probably falls outside the scope of StyleDictionary itself, but I would be curious to see if anyone is willing to share their experience with distributing cross-platform tokens. Thus far, I've been distributing CSS and JS token formats through Node packages, but I'm starting to investigate generating tokens for iOS and Android. Are folks distributing tokens/files via package managers like CocoaPods or Swift Package Manager? Or possibly through tools like JavaScriptCore?

Cheers

[jorenbroekema]

@tlouisse maybe you can summon your android/ios platform engineers and ask them how they're distributing their stuff for the mobile feature/app engineers? would be interesting to know about this

[tlouisse]

Hey,

Right now we have a fully functioning distribution flow for web. For iOS and Android we have a POC inside the repo that hosts the tokens, but full implementation for these platforms (including distribution) has yet to be planned. We have an idea on how to distribute tokens to these platforms, which I can describe here.

For reference, let's start with the explanation for how we currently implemented it (which is operational for web):
We have a central repo, let's call it ds-tokens. It contains:

• token sources (json files): these are directly synced from FIgma and are considered the single source of truth in code
• translation processes: these are opinionated style-dictionary builds per platform (web/ios/android)
• command line interface, let's call it ds-tokens-cli, that exposes the translate process and should be called by consumers (consumers are platform specific ui libs... let's call them ui-web, ui-android and ui-ios)

In ui-web, we have a package.json with:

"devDependencies": { 
 "ds-tokens": "^1.0.0",
},
"scripts": {
 "translate-tokens": "ds-tokens-cli translate-tokens-web --potential-params-for-output-location-etc"
}

Now the tokens (css files mostly) are generated for web, which are then published along with the release of web-ui (output folder has to be put in .gitiginore and exposed in npm package)

The plan for our android and ios repos, would be exactly the same. That means that developers working on android-ui and ios-ui repositories need to have node/npm installed and run npm install in order to consume the tokens

Other distribution strategies considered

Android and iOS ui repos usually have their own package managers already of course (in our case we should have released ds-tokens not only as npm package, but also as android library module and Swift package).
The problem: ds-tokens ships a full node application, so a node runtime is needed to execute this (other package manager won't install transitive dependencies etc.)

Can't we just ship the token translation output builds for all platforms instead?

What if ds-tokens did not ship the token jsons plus their build processes, but instead it ships the platform specific assets?
In this case it would be easier to use platform specific package managers (and publish ds-tokens in three different formats to three different registries).

This might be a working strategy depending on your organisation, but in ING we have a complex, federated landscape with so called "local design systems". (let's say we have web-ui--local) These local design systems might have their own themes and tokens or token overrides. By distributing the build processes we maintain the degree of flexibiity we need in our organisation.

[jorenbroekema]

Aaah that's really interesting, @lukasoppermann since we were just talking about consumers maybe needing flexibility and allowing them to override tokens themselves, ING's approach might be interesting to read about

[mikekamminga]

This is super insightful!

[nhoizey]

@tlouisse

When you says this:

For iOS and Android we have a POC inside the repo that hosts the tokens, but full implementation for these platforms (including distribution) has yet to be planned

Does it mean you already did the formats transformations at least? I'm wondering because I'm struggling with them for Android… 😅

• #1132

[tlouisse]

Yes, we did a poc with two components per platform. I will ping our android dev for that :)

[nhoizey]

@TrevorRice I started working on tokens for Android projects, and we will use Graddle packages distributed in the company's Azure DevOps Artifacts.

I don't know much more about it, unfortunately.