How to rebrand a mobile app in Figma with variables

To rebrand a mobile app in Figma with variables, repoint the variable the brand color lives in and let every layer bound to it follow. In the Appetite UI file that variable is brand/base: moving it from colors/blue/500 to colors/orange/500 recolors 1,110 layers across components, app screens and charts, in Light and in Dark. The rest of the brand ramp is separate variables, so a complete rebrand repoints ten more tokens, and anything not bound to a variable stays as drawn.

Appetite UI is a Figma UI kit for iOS and Android apps, built like a design system. One token source drives Apple and Material components in light and dark mode, and exports to SwiftUI, Jetpack Compose, Flutter and CSS. I build it, so the counts below come from its file, read with a script that changes nothing, and the tables say what each number counts.

Why can one variable recolor a whole app?

Because the color is written down once, and everything else holds a pointer to it. Figma calls the pointer an alias: "A variable can reference another variable. That is, you can apply a variable to another variable. Also called, 'aliasing,' this gives you the ability to implement design tokens." Appetite UI uses three levels of it.

The hex #155DFC exists in one place. Repoint brand/base and the semantic level moves, the platform slots that point at it move, and every layer bound to it moves, with each mode keeping its own target. How this two-mode setup is built is the subject of Dark mode with Figma variables, not duplicate frames; this article starts where that one ends, with the brand color already on a token.

To make the pointer in Figma, open the Variables modal, right-click a variable's value and select Create alias, as Figma's help describes.

What does brand/base reach in the Appetite UI file?

It reaches 1,110 layers. I counted every page of the Appetite UI file (release 2.5) on October 8, 2026, entering every node except the insides of instances, which take their colors from the component they come from, and reading which variable each fill, stroke and effect color is bound to.

Checked on October 8, 2026, against the Appetite UI file (release 2.5), read with a script that changes nothing.

The app screens hold 2,506 instances at their top level, and each takes its color from the component it comes from. That is why a screen needs no edit of its own: 260 layers on the screens are bound to brand/base themselves, and everything else on them arrives through components.

Three other variables point at brand/base, and a rebrand reaches their layers too:

845 plus 186 plus 79 is 1,110. The focus ring is among them: the Focused variants of Button, Chip and Input draw it as a 4 point shadow in brand/base, and the Neutral buttons do too, so a focus ring follows the brand even where the button fill does not. No token in Color Tokens is named for a link or an action. Components bind the brand color itself, which is the reason one variable is enough for them.

Which tokens change when you swap the whole ramp?

Eleven tokens, because the brand has more than one step. brand/base is the solid color. Beside it the file keeps a lighter, a light, a dark, a darker and a pressed step, three translucent tints that alias the blue alpha set, and two stronger translucent steps typed as raw values. Move only brand/base and 403 layers stay blue: hover and pressed states, soft tints, selected backgrounds. That is just over a quarter of the layers that use the brand family.

Checked on October 8, 2026, against the Appetite UI file (release 2.5), Foundations and Color Tokens.

Three things in that table are worth reading twice.

• Dark is its own column. brand/base points at blue/400 in Dark, so its orange equivalent is orange/400. Copying the Light step across is the first thing a rushed rebrand gets wrong, and the reasons for a separate Dark step are in the dark mode article.
• The last row is the one a ramp edit cannot find. brand/alpha-48 and brand/alpha-72 hold the color as a raw value instead of an alias, so retype them. The color docs mark roles like these as direct.
• Some steps have no layers. brand/darker binds nothing outside the documentation pages, so on screens it changes only through the Material roles that alias it.

How do you make the edit in Figma?

1. Duplicate the file, then open the Variables modal

   Work on a copy. Open the Variables modal and check that the ramp you are moving to exists in the primitive collection with the same steps, here colors/orange/50 to colors/orange/950.

2. Repoint the solid steps in Light

   In Color Tokens, right-click the Light value of each brand token and select Create alias, then choose the matching step of the new ramp, as in the table above. Figma's help describes the action as "Right-click a variable's value and select Create alias."

3. Repoint the same tokens in Dark

   Use the Dark column of the table, not the Light step. The Dark targets are lighter, so the brand keeps its contrast on a near-black ground.

4. Repoint the tints and retype the raw values

   Point brand/alpha-10, alpha-16 and alpha-24 at the new alpha set, then type the two stronger steps by hand.

5. Check both modes and both platforms

   Set a frame to Dark with Apply variable mode in the Appearance section of the right sidebar, and check one screen in Brand mode on each platform mirror.

6. Sweep for what did not move

   Select one layer that should have changed and still shows the old color. Figma's Edit menu lets you select all other layers with the same fill, stroke or effect; bind the selection to the right token with Apply styles and variables, as Figma's help describes, or redraw it.

7. Run the contrast check and export

   The next sections cover contrast and code. Then regenerate the outputs from the source.

What does not follow a variable?

Anything that is not bound to one. A variable recolors fills, strokes and effects that reference it, and nothing else. These are the cases to look for, with the numbers I found in the Appetite UI file where the file has them.

The Information status stays blue on purpose. A brand that turns orange does not make an informational banner orange, and a rebrand that did would blur the status colors, a point Apple makes about color generally: "Avoid using the same color to mean different things." Decide that one deliberately, token by token.

Do the iOS tint color and Material primary follow?

Yes in Brand mode, and no in System mode, by design. The Platform Bridge names the Apple and Material slots and points each one at a token. Twelve slots end on the brand family; three of them point at brand/base itself.

Checked on October 8, 2026, against the Appetite UI file (release 2.5), Platform Bridge collection.

Seven more Material slots follow the same way through brand/lighter, brand/light, brand/dark and brand/darker: on-primary-container, secondary, secondary-container, on-secondary-container, tertiary-container, on-tertiary-container and inverse-primary. The slot names are the platforms' own, which is the point: Apple's tint and Material's primary are where each platform expects the brand to arrive, and the Platform Bridge docs list all 113 slots.

Both platforms document where a brand color goes. Apple documents the tintColor of a view as: "The first nondefault tint color value in the view's hierarchy, ascending from and starting with the view itself." Its color guidelines add that the system applies the app accent color to the background in prominent buttons. Google's Material 3 documentation says "Primary is the base color, used for main components like prominent buttons, active states, and the tint of elevated surfaces." One brand edit lands in both, because both slots end on brand/base.

What does the same edit look like in code?

One reference changes. In the token source, a semantic token holds a reference to a primitive, and the code docs print the smallest file that shows it. The orange edit swaps the primitive that brand.base points at:

{
  "colors": {
    "orange": {
      "500": { "$type": "color", "$value": "#FF6900" }
    }
  },
  "brand": {
    "base": { "$type": "color", "$value": "{colors.orange.500}" }
  }
}

The full source carries Light and Dark as two values on the same token, so the Dark value moves to colors.orange.400 in the same edit. The outputs are generated from the source, and the code docs say to change a value there and leave the outputs alone. Regenerate, and the CSS output, in the structure the docs print, carries the new values:

:root {
  --ap-brand-base: #FF6900;
}

[data-theme="dark"],
.dark {
  --ap-brand-base: #FF8904;
}

@media (prefers-color-scheme: dark) {
  :root:not([data-theme="light"]):not(.light) {
    --ap-brand-base: #FF8904;
  }
}

The names stay: var(--ap-brand-base) in CSS, Color.apBrandBase in SwiftUI, AppetiteTheme.colors.brandBase in Compose and apBrandBase in Flutter. A developer receives new values under names the code already uses, so a rebrand reaches the project as a regenerated file and needs no search through the code. The code output docs print all four outputs, and How one Figma token becomes SwiftUI, Compose, Flutter and CSS follows one token through them.

Will the new brand color pass contrast?

Not automatically, and an orange is the case that shows it. The label of a filled brand button is bound to static/static-white-0, which is white in Light and in Dark, and its fill to brand/base. White on the default blue measures 5.25:1; on colors/orange/500 it measures 2.89:1.

Checked on October 8, 2026, against hex values read from the Appetite UI file (release 2.5), ratios computed with the WCAG 2 formula.

WCAG 2.2 asks for "a contrast ratio of at least 4.5:1" for standard text and at least 3:1 for large-scale text, which is at least 18 point or 14 point bold. Apple's accessibility guidelines give the same pair of numbers for iOS: 4.5:1 for text up to 17 points in all weights, 3:1 at 18 points and for bold text. A white label at 2.89:1 fails both, and the default blue in Dark, at 3.76:1, meets the large text threshold only. The swap is therefore two decisions in one: pick the step, then check the label on it.

Three ways out. Point brand/base in Light at orange/700, a token edit, which gives white a ratio of 5.22:1 on a deeper orange. Keep orange/500 and rebind the label of the filled brand variants to a near-black color, which gives 6.68:1 but is an edit to the components, since the label is bound to the white primitive and not to the brand. Or keep the bright orange for large text and graphics, and use a darker step wherever a small label sits on it. The first choice moves every screen with one variable, which is the property that made the rebrand a one-variable job.

For the dark ground, the numbers go the other way: colors/orange/400 as text on #0E0E0F measures 8.11:1, a lighter and more legible brand there than the blue it replaces.

What to take from the file

A rebrand is as short as the file is wired. In this file the brand arrives at the layers through one semantic token, the platform slots alias that token, and the other steps of the brand are named and counted, so the work is eleven edits and a contrast decision instead of a sweep through 1,513 layers. Check any file the same way before you promise a client a one-day rebrand: open the Variables modal, follow the brand color to the layers, and list what is typed in by hand.

The color docs show every ramp and role in both modes, the tokens page switches the same chain on a phone screen, the platforms page shows the two mirrors side by side, the read-only preview opens the whole file, and pricing lists what each license includes.