Choosing your app's colors and type, once

Most store apps are over-designed in the wrong places. Somebody picks a brand colour, applies it to everything, and ends up with a screen where the buttons, the badges, the headings and the sale tags are all competing in the same hue — while the product photos, which are the actual content, fight for attention against it.

Here is a method that takes about an hour and produces something that still looks right in a year.

Start from your photography, not your logo

Your app is 90% product photography by area. The palette’s job is to sit underneath it without arguing.

Pull up twelve of your product images together. Are they light and airy, or dark and saturated? Warm or cool? Shot on white, or in context?

• Light, airy photography → a near-white background, and let the products be the colour.
• Dark, moody photography → a deep neutral background can look excellent, and will make your photos glow.
• Mixed and inconsistent → a neutral background is your only safe choice, and fixing the photography is a better investment than any palette decision.

Your logo colour comes in later, as an accent. It is not the background.

The five roles a palette needs

Not twelve colours. Five roles:

1. Background. Near-white or near-black. Not pure #FFFFFF or #000000 — a hint of warmth or coolness reads as intentional.
2. Surface. Cards and sheets, one step from the background. This is what creates depth without shadows everywhere.
3. Text. One strong colour for primary text and one muted for secondary. Not grey-on-grey; the muted one still has to pass contrast.
4. Accent. One colour, for the primary action. Add to cart. Checkout. This is where your brand colour goes, and it should appear rarely enough to mean something.
5. Semantic. Success, warning, error, and a sale/discount colour. These are functional and should not be your brand colour — a sale badge in your accent colour makes every accent look like a discount.

That is it. StoreToNative’s design studio ships 12-colour palettes precisely so this is a selection rather than a design project, but the reasoning applies whatever tool you use.

The accent-colour discipline

One rule, and it is the difference between a designed app and a coloured one:

The accent colour appears on the single most important action on each screen, and nowhere else.

On a product page that is add-to-cart. On the cart it is checkout. On the home screen it is possibly nothing at all.

When everything is accent-coloured, nothing is, and your conversion path stops being visually obvious.

Typography: two decisions

Decision 1: one typeface or two. One is safer and looks more coherent. If you use two, the split is display type for headings and product names, and a highly legible face for everything else — never the reverse.

Decision 2: the scale. Four sizes is plenty:

• Large for product names and screen titles
• Body for descriptions — this is the one that matters most
• Small for metadata, secondary information
• Caption for badges and labels

Body text on a phone wants to be around 15–16 points. Fourteen looks tidy in a mockup and is tiring to read on a bus.

The rules that are not aesthetic choices

Three things are accessibility requirements, not preferences, and they are also the things that get flagged in reviews:

Contrast. Body text needs a contrast ratio of at least 4.5:1 against its background; large text at least 3:1. Light grey placeholder text on white fails this constantly, and it is the most common accessibility problem in commerce design. Check every text-on-colour pair with a contrast checker, including white text on your accent colour.

Touch targets: at least 44×44 points. Everything tappable. Variation swatches are the usual offender — a row of pretty 30 px colour dots is a mis-tap generator, and a mis-tap on a size selector is a return.

Do not encode meaning in colour alone. An out-of-stock swatch shown only by being greyer is invisible to a colour-blind customer. Add a strikethrough, an X, or a label.

Dark mode: decide, don’t drift

Two legitimate answers.

Support it properly. Every colour needs a dark counterpart, and product photography shot on white needs checking — white-background cutouts on a dark surface look like floating rectangles.

Commit to light. Declare it, and make sure nothing inherits the system theme half-way. A light app with one dark sheet because a component defaulted is worse than either.

What you must not do is ship “mostly light with some accidental dark,” which is what happens when nobody decides.

Right-to-left, if you need it

If you serve Arabic-speaking customers, layout direction is not a colour decision but it belongs in the same hour of planning: mirrored layouts, reversed tab order and direction-aware icons. It is a rendering-level property rather than a stylesheet toggle — Arabic-first commerce covers what first-class actually means.

The hour, step by step

1. Ten minutes: look at twelve product photos and pick light or dark.
2. Ten minutes: choose background, surface and two text colours.
3. Five minutes: choose the accent. Your brand colour, unless it fails contrast against your background — in which case choose a darker or lighter variant of it.
4. Five minutes: semantic colours, deliberately different from the accent.
5. Ten minutes: typeface and four sizes.
6. Ten minutes: check every text pair with a contrast checker.
7. Ten minutes: look at it on a real phone, outdoors if you can. Screens lie indoors.

Then stop. And because theme, colours and typography are over-the-air configuration rather than code, changing your mind later costs a publish, not a rebuild and a store review — which is a good reason to ship a decision rather than perfect one.

Related reading

• Designing an app home screen that actually sells
• Bottom tabs or a side menu? App navigation for stores
• Over-the-air updates, explained
• Arabic-first commerce

Palettes, typography and layout all live next to a live phone preview in the design studio.