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.


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.

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.

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.

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

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.

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.

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.

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