Skip to content
Appetite UI Symbol
Appetite UI

Where it fits

The layer between the platform kits and your brand.

Every guide tells you to start from the Apple and Material kits and build your own system on top. Appetite UI is that layer for designing mobile apps, already built.

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.

Three things that stop being your problem.

Not features. These are the three moments where a design file usually starts costing you time, and where this one does not.

One brand colour change moving through every component

Brand change

One color change, every screen reopened

Without the layer the brand color sits inside every screen you drew, so one change becomes a manual pass and the screen you miss is the one that ships. Here it is one edit against 403 variables.

The same component in the iOS and Material mirrors

Second platform

The second platform drifts first

Without shared tokens the Android file is a copy of the iOS one, so every change costs two edits and the copy drifts the first time somebody makes only one. Here both conventions read the same tokens.

The token package installed in a developer project

Code

Reach the code

One W3C DTCG source generates SwiftUI, Compose, Flutter and CSS. Your developer reads the values you designed with rather than a document.

One system.

Every ship path.

Most mobile systems assume one workflow: Figma frames for handoff, or a component library for one framework, or prompts for a model. This one sits underneath all four. The file is the source of truth and how you hand it off is your business.

One Figma file, 403 variables, one W3C DTCG source

Tokens arriving as SwiftUI color and type extensions

Native iOS

Token names map straight to Swift extensions, with Dynamic Type anchors rather than fixed sizes. Drawn to follow the publicly documented Apple conventions, not to fight them.

Tokens arriving as a Compose theme and typography object

Native Android

The same tokens as Kotlin constants and a ready Material 3 typography object. Material patterns where they fit, custom where they do not.

The DTCG token file feeding a cross platform build

Cross platform

DTCG token JSON drops into Flutter, React Native or any Style Dictionary pipeline. One source of truth on every platform, no manual sync and no naming drift.

An agent reading the Core Skill instruction file

AI tools

The free Core Skill tells an agent which token and pattern to use. Drop it into Claude, Cursor or v0 and the output matches your system on the first prompt rather than the fifth.

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

Four situations where the architecture pays for itself, and three where it does not. Both lists are worth reading before you spend anything.

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.

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.

Jacob Engelbreth

Digital Concept Developer

The outputs I get from our designer are more understandable for development. I recommend it.

Brano Stupak

App developer

I now design systems and apps much faster and more efficiently. A great investment and a foundation for good app designs.

Bara Liskova

UI Designer

Appetite UI has helped us develop mobile apps much faster and more efficiently.

Jan Doan

UX Designer

Your next rebrand is one edit.

One-time payment  |  Lifetime updates  |  Works on the free Figma plan