Mobile App Branding Checklist for Small Businesses
A working list of the assets, sizes and rules that decide whether an app looks like one brand across the launcher, the store and the website.
A store rejection is rarely about code. The most common last-week scramble is brand assets: a 1024 x 1024 icon exported with an alpha channel that App Store Connect refuses, screenshots showing a palette from two revisions ago, and a splash that flashes white for a third of a second before a dark-themed app loads. None of it is hard. It is just work nobody put on the schedule.
The icon has the most fixed requirements, so settle it first
Each platform rejects a different mistake.
| Asset | Size and format | What trips people up |
|---|---|---|
| iOS app icon | 1024 x 1024 PNG, RGB, no alpha channel | Transparency is rejected. Do not pre-round corners; the system masks square art. |
| iOS dark and tinted variants | Appearance-specific versions of the mark | Skip them and the system derives a desaturated version that often looks muddy. |
| Android adaptive icon | Foreground and background layers, 108 x 108 dp | Only the inner 72 x 72 dp survives every OEM mask (circle, squircle, teardrop). |
| Android themed icon | Monochrome layer | Without it your icon ignores wallpaper theming on Android 13 and later. |
| Play Store listing icon | 512 x 512, 32-bit PNG, under 1 MB | Square, unrounded, separate from the launcher asset. |
Keep anything that must stay legible inside a 66 dp circle centered in the adaptive icon, then judge the result at 48 px rather than on a design canvas. A wordmark that reads well at 512 px turns into a smudge at launcher size, which is why durable app icons are usually one letter or one simple mark rather than a full logo lockup.
In Flutter, flutter_launcher_icons generates every density from one source file, but check the output. It flattens transparency without warning, and will not build the monochrome layer unless you supply that image.
Decide what the splash screen is actually for
Android 12 changed this and many apps still ship the old behavior. The system now draws its own splash from your theme using windowSplashScreenBackground and a centered icon. If a legacy launch_background drawable is still in place, users get the system splash and then yours: two flashes before the first real frame. Configure the Android 12 block in flutter_native_splash and delete the legacy path. The system also masks that icon to a circle in a small window, so a wide horizontal logo gets clipped.
On iOS the launch screen is a storyboard rendered before any Dart code runs. It cannot animate, fetch anything, or read app state. It responds to light and dark appearance only if you provide both images in the asset catalog, and a dark-themed app with a white launch screen flashes on every cold start.
The rule: a splash covers process start only. Slow first-screen data is a skeleton screen.
Express color as tokens, not hex codes sprinkled through widgets
Keep two layers. The brand palette holds your literal colors. The semantic layer holds surface, surfaceContainer, onSurface, outline, primary, onPrimary, and error. Widgets reference the semantic layer only, so a brand refresh changes one file instead of 90.
Material 3 generates a full tonal palette from a seed color, which is a good start and a poor finish: the derived primary is frequently several steps off the brand guide. Override primary, onPrimary, secondary, and surface explicitly, then let the generator fill in the rest.
Dark mode is not an inversion. Pure white on pure black causes visible halation on OLED, so aim for something near #E6E0E9 on #141218, and remember that raised surfaces get lighter in dark mode, not darker. One trap worth naming: if your brand red is both the primary call to action and the error color, users cannot tell a normal button from a destructive one. Reserve a hue for destructive actions and keep it out of everything else.
Hold the type scale to five or six sizes
Most business apps do fine with 32 / 24 / 20 / 16 / 14 / 12 px, line heights from 1.2 on headings to 1.5 on body, one family, two weights. Each extra weight adds 100 to 300 KB of bundled font, and a designer given nine text styles will use all nine inconsistently.
Then test at scale. iOS accessibility sizes reach roughly 310% of default, and Android 14 allows 200% with non-linear scaling that grows small text more than large. Read the factor with MediaQuery.textScalerOf instead of hardcoding sizes, and stop wrapping text in fixed-height containers, the most common source of overflow stripes at 1.3x. Clamping with TextScaler.clamp on one dense data screen is defensible; clamping globally is opting out of accessibility.
One detail that surprises people: the google_fonts package fetches fonts at runtime and falls back to a system font on a cold offline start, so your typeface quietly disappears for some users. Bundle the .ttf.
Check contrast before the palette is signed off
WCAG 2.2 AA asks for 4.5:1 on normal text, 3:1 on text at 24 px regular or 18.66 px bold, and 3:1 on icons and control boundaries. Mid-tone brand colors fail constantly. A warm amber such as #F5A623 sits at roughly 2:1 against white: fine as a fill behind dark text, unusable as text on a white card. The fix is a darker variant of the brand color reserved for text and icons.
Three places slip through almost every time: placeholder text in inputs, disabled button labels, and text over a photograph. For the last one add a scrim, flat black at 40 to 60 percent, and measure against the lightest pixel the text can land on, not the average.
Treat store creative as a deliverable with its own spec
The App Store needs a 6.9-inch portrait screenshot set at 1290 x 2796 or 1320 x 2868, a 13-inch iPad set if you ship for iPad, a 30-character name, a 30-character subtitle, and a 100-character keyword field. Google Play needs the 512 x 512 icon, a 1024 x 500 feature graphic, two to eight phone screenshots with no side over 3840 px and an aspect ratio no wider than 2:1, a 30-character title, an 80-character short description, and up to 4000 characters of description.
The first two screenshots carry most of the weight, since they appear in search results before anyone taps through. Caption them with the benefit rather than the screen name, and generate them from a test that drives the real app, so reshooting after a UI change costs ten minutes instead of an afternoon.
Make the app and the website agree
Line these up in one sitting, because mismatches read as careless to the exact customer who was already hesitating:
- The store title matches the name in your site header, character for character, including capitalization.
- The hex values in the app theme match the site stylesheet. Not close. The same.
- The app icon is the favicon.
- Support email is on your own domain, and the privacy policy URL resolves, because App Review checks it.
- Website screenshots come from the same generated set as the listing, so they age together.
If you rebrand later, this list doubles as the change order. Knowing there are eleven files to touch, rather than "the app, somewhere", turns a two-week job into a two-hour one.
White-label Flutter apps, delivered in 30-60 days, from $2,500 - full source code included.
Get started