Booking

Preview

Eleven screens follow one stay from search to a confirmed trip: Explore, Results, Filters, Listing, Dates, Guests, Review and pay and Confirmed, then Trips, Trips empty and Profile. Each screen is drawn in Light and in Dark.

Booking, 11 screens393 x 852 each, Light and Dark

What does a stays booking flow need from a component library?

A search that sits above a feed, cards that carry a photo and a price, controls for narrowing, picking dates and counting guests, and a short path to pay.

A stays app needs a search field, a card for one stay, chips to narrow the list, a calendar that selects a range, counters for guests and a row that shows a price. Here the search is Search, the card is Vertical Card, the calendar is Date Picker and the counters are Stepper, so a stays flow draws on the library as it ships. The price pins on the Results map are Chip instances, one per pin.

The tab bar floats over the content on its five screens, and a short fade behind it keeps scrolled content from showing next to the bar. Dates is the screen to open for the calendar: its range is the Range Start, Range Middle and Range End states of the Date Picker day cell (see Picker).

On iOS the minimum touch target is 44 pt. The frames pin Platform to ios-md, where platform/min-touch-target reads 44, so that is the size a tap target on these screens starts from. Android would read 48.

How do the Booking screens follow one stay?

Booking is drawn as a stays app, and its screens share one trip.

Explore opens on a capsule search with Stays and Experiences tabs and rows of cards, Results is a map with price pins and a sheet, and Trips leads with one large card for the next stay. The whole flow reads 12 to 17 February for 3 guests, from the Results header to the Review and pay total, so the screens agree with each other.

What are the Booking screens built from?

Every instance on the eleven light frames, counted once, by the component it comes from. The dark row holds the same instances, so each number is per row.

287 instances sit on the frames. 95 of them are placed directly as Appetite UI components from 22 component sets, and 7 are Lucide icons. Another 185 sit inside those. Placed counts an instance that is not inside another instance, nested counts one that is, and a component is counted by its set name, so every Button variant is a Button. An icon is any instance named in lowercase.

Of the nested instances, 76 are icons inside other components, 78 are helper parts of larger components, and 31 are Buttons, Badges, Toggles and Compact Buttons inside bars, steppers, cards and rows.

Not everything is an instance. 51 shapes are drawn by hand. Ten sit behind the tab bar on five screens, 27 are the bars of the price histogram behind the Range Slider on Filters, and the other 14 sit on Listing, Guests and Review and pay.

Counted on October 2, 2026 with a Plugin API script over the eleven light frames of the Booking page in the Appetite UI Figma file. Hidden layers count. No third party asset is placed on these screens.

Which tokens do the Booking screens use?

No solid fill or stroke on these frames is a raw color. Each one resolves through a variable, which makes the dark row a mode switch.

The eleven light frames hold 679 solid fills and strokes bound to 37 different variables, and none is unbound. Photographs and six gradients are the only paints that are not a solid color. Every frame sets its modes explicitly, Color Tokens = Light or Dark and Platform = ios-md, so a frame dropped into another file arrives in the theme it was drawn in. The dark frames bind the same variables and differ only in the Color Tokens mode they pin, so a rebrand at Color Tokens moves all eleven screens.