Skip to content

Where it fits

The layer between the platform kits and your brand.

Apple's and Google's kits each cover one platform, and neither carries your brand. Appetite UI is that layer: a Figma UI kit for iOS and Android, built like a design system.

Three dark mode app screens, a social feed, a wallet balance and fitness analytics
Token name labels floating over the screens: brand/base, static-white, state/success, navbar

The problem

Mobile design is harder than it looks.

Then it gets harder. None of this shows up on the first screen. It shows up on the fortieth, when the file has been through two people and one brand change.

Mobile is the hardest surface.

Touch targets, safe areas, gestures, iOS against Android conventions, dark mode, accessibility. Desktop kits do not solve any of this. Universal kits compromise on all of it.

Consistency does not survive speed.

Without a system every new screen drifts a little further from the brand. Six weeks in, your app looks like five different apps stitched together.

What stops being your problem.

Three moments where a design file starts costing you time.

Before

colors/blue/500becomescolors/purple/500brand/base, one edit

After

Brand change

One color change, every screen reopened

Without the layer, a new brand color means reopening every screen you drew. Here it is one edit against 589 variables.
iOS conventions in dark mode: a filled Play button, a notification row, an action sheet, a calendar and the iOS keyboard
The Material 3 mirror in dark mode: a filled Label button, a dialog, a snackbar, the Material date picker and the Gboard keyboard

Second platform

The second platform drifts first

Without shared tokens, the Android file is a copy that drifts with every edit. Here both platforms read the same tokens.
appetite.css, the kit's CSS output: --ap-brand-base #155DFC, the background, text and border colors, --ap-radius-2xl and --ap-space-4, with the dark theme block under them setting --ap-brand-base to #2B7FFF

Code

Reach the code

Your developer gets the values you designed with, in SwiftUI, Compose, Flutter or CSS, not a document.

One system. Every ship path.

One file sits under every way you ship: native, cross platform or through an agent.

One Figma file, 589 variables, one W3C DTCG source
AppetiteTokens.swift with the SwiftUI mark: a Balance text with the Color.apTextStrong950 foreground style, set in AppetiteFont.lgEmphasized

Native iOS

Tokens become Swift extensions, and type follows Dynamic Type.
AppetiteTokens.kt with the Jetpack Compose mark: a Balance text styled with AppetiteTheme.textStyles.lgEmphasized and colored AppetiteTheme.colors.textStrong950

Native Android

The same tokens as Kotlin constants and a Material 3 type scale.
tokens.json beside a JSON file icon: the DTCG token brand.base with its $type set to color and its $value the alias {colors.blue.500}

Cross platform

One DTCG JSON source for Flutter, React Native or any token pipeline.
SKILL.md open at its Color rule, semantic tokens only such as brand/base and never a raw hex, with Claude and Cursor pointers

AI tools

The Core Skill in the file tells Claude, Cursor or Figma Make which token to use.

Buy this when the file has to outlive the first version of it.

When the architecture pays for itself, and when it does not.

You are building for a phone.

iOS, Android or both. Everything in the file was drawn for a phone rather than adapted to one.

The brand will change.

It always does. Two token levels mean the change is one edit rather than a sweep across every screen.

A developer wants values, not a document.

Tokens arrive as SwiftUI, Compose, Flutter and CSS, so nobody retypes a hex into a stylesheet.

Dark mode is not optional.

Every component carries both modes through the same semantic tokens, not a duplicated theme.

Skip it when

You are building for the web. A web system will serve you better and cost you less time.

You want a pile of screens to copy from rather than a system to build on.

Your team already runs a mature design system of its own.

Who uses it

Designers and developers who already shipped with it.

I now design systems and apps much faster and more efficiently. A great investment and a foundation for good app designs.
Bára LiškováUI Designer
Appetite UI has helped us develop mobile apps much faster and more efficiently.
Jan DoanUX Designer
The outputs I get from our designer are more understandable for development. I recommend it.
Braňo StupákApp developer
Built with Figma Variables, linking primitives and semantic tokens the way a real design system should. Lean by design, with only the tokens you actually need.
Jakub EngelbrethDigital Concept Developer

Your next rebrand is one edit.

One-time payment, Lifetime updates, Unlimited client projects