Brand Identity Inside Native Platforms

Two teams get this wrong in opposite directions. One ships a skinned web app where every control is custom, nothing behaves the way the OS taught the user, and the brand is loud and disliked. The other ships something so default it could be anyone's, and the brand exists only in the app icon.

The resolution is not a compromise between them. It is knowing which surfaces belong to the platform and which belong to you — and platform design has become explicit about where that line is.

The two layers

Apple's guidance for iOS 26 and later splits the interface into a UI layer and a content layer. Liquid Glass makes the split visible: the UI layer floats, refracts and adapts; the content layer sits beneath it and is yours.

That split is the whole answer:

UI layer — theirs. Navigation, toolbars, tab bars, sheets, alerts, system controls. Use standard components. This is the part users navigate by muscle memory, and a custom version costs recognition while gaining nothing.
Content layer — yours. Imagery, video, copy, illustration, motion, colour, the shape of your own domain objects. This is where a product becomes recognisable.

Android has the same division under different names: Material's navigation and app-bar components carry the platform, your content carries you.

The test: if a custom component expresses something only your product has — a lunar-cycle calendar, a workout ring, a recipe timeline — build it. If it is a differently-shaped tab bar, do not.

Colour

The instinct is to paint the toolbar. Resist it: on a platform where the UI layer is translucent and adaptive, a solid brand-coloured bar fights the material and dates immediately.

Move brand colour into the content. Then spend it deliberately, on:

hierarchy — what matters most,
grouping — what belongs together,
status — what state something is in,
feedback — what just happened,
interaction — what can be touched.

Colour used for all five at once communicates none of them. And dark mode is not optional: it is a comfort and accessibility requirement, not a variant you ship later. See color systems for building both themes from one brand colour, and modern css design primitives if the same brand also runs on the web.

Typography

A custom typeface is one of the strongest brand signals available and platforms permit it — with one hard condition: Dynamic Type must work. A brand font that ignores the user's text size is not a brand decision, it is an accessibility failure with a logo on it.

The system faces (SF Pro, SF Compact, SF Mono, New York) are not the boring option. They carry weight, width and optical-size axes, they are tuned for the platform's rendering, and they scale correctly for free. A restrained pairing — brand face for display, system face for body — usually beats a custom face everywhere, and always beats a custom face that breaks at accessibility sizes.

See typography and typography craft for the scale itself.

Iconography

Custom icons are encouraged, and they must still be recognisable. Two rules:

Respect the convention for the action, not the drawing. The share icon differs across iOS, Android and the web because each platform taught its users a different glyph. Draw it in your style; do not reassign its meaning.
Test at the smallest size you ship. An icon that reads at 48pt in a design file and is mud at 17pt in a tab bar has failed.

SF Symbols — 7,000+ symbols, weight- and scale-matched to the system text — is the fastest path to icons that sit correctly next to labels. Mixing a custom family with SF Symbols in the same surface is the most visible cheapness in a native app; pick one per surface. See iconography and suggest_icon_library.

Motion

Motion is brand, and it is the easiest place to overspend. A transition that expresses the product's character is worth having; one that delays a tap is not. Everything in animation craft applies — interruptibility above all — plus one platform-specific rule: never let a brand animation stand between a user and a completed action.

Checklist

Navigation, toolbars, tab bars and sheets are standard components.
Every custom component expresses something only this product has.
Brand colour lives in the content layer, not painted onto system chrome.
Colour is assigned to one job at a time — hierarchy, grouping, status, feedback or interaction.
Dark mode designed, not derived.
Dynamic Type verified at accessibility sizes, with a custom face if you ship one.
One icon family per surface; custom glyphs follow platform conventions for meaning.
Icons checked at their smallest shipped size.
No brand animation sits between a tap and its result.

Anti-patterns

Rebuilding the tab bar. The clearest example of spending recognition to gain nothing.
Painting the toolbar in brand colour. Fights a translucent, adaptive UI layer and looks dated within a release.
A logo in the navigation bar of every screen. The app icon already did that job; the space is worth more as content.
A custom typeface that ignores Dynamic Type. An accessibility failure wearing a brand.
Porting your Android look to iOS, or the reverse. Same intent, different expression — see compare_design_languages, which lists explicitly what not to port.
Brand as decoration rather than meaning. If removing an element loses nothing but colour, it was never brand.
Treating "native" as "default". Standard chrome plus an unremarkable content layer is not restraint, it is an absent product.

Brand Identity Inside Native Platforms — Where Yours Goes and Where Theirs Stays