Brand style in a mobile app: icons and splash screens
Logo and icon: why these are different design tasks
A logo solves the task of brand recognition in static conditions—on packaging, in a website header, in an email signature. An icon solves the task of navigation in dynamics: the user searches for it with their eyes among many similar squares and must find it within 1-2 seconds. These are different user scenarios, and transferring the solution from one to the other literally is an error.
A practical rule for adaptation: take the brand mark and remove everything that does not read at a scale of 29×29 px (the minimum size on iOS). If a readable silhouette remains—this is a candidate for an icon. If an unreadable blob remains—then a separate symbol is needed, built on the same color and geometry as the main brand mark, but without details: no inscribed text, no thin lines, no semi-transparent layers.
iOS and Android: two different technical languages of one icon
This is where the real complexities of the brand style in the application begin — the platforms physically process graphics differently, and one layout cannot be mechanically stretched across both.
| Parameter | iOS | Android |
|---|---|---|
| Source format | 1024×1024 PNG, without transparency, solid background | Adaptive icon: two layers — foreground 108×108dp and background |
| Shape | Square — mask, rounding, and shadow are added automatically by the system | The system itself forms the shape (circle, drop, square) depending on the phone's shell |
| Size in the store | 1024×1024 px in App Store | 512×512 px in Google Play |
| Response to theme | Fixed view | With Android 13 system can adapt icon colors to user wallpapers (Material You) |
The main mistake at this stage is manually adding rounded corners or shadow under the iOS icon. Apple does this automatically at the system level, and duplication results in a visual artifact: double shadow, uneven edge. On Android, the reverse problem occurs: if the foreground layer does not leave sufficient margins (safe zone 66×66 dp, approximately 61% of the 108×108 dp area), the logo will be cropped at the edges when the mask shape changes on some shells.
How to reconcile both requirements without losing brand style
A working approach is not to draw a separate 'iOS icon' and 'Android icon', but to create one master symbol on a transparent background with sufficient margins, then build two tech packages for it: fill for square for iOS and foreground/background separation for Android. The background color in both cases should be brand-specific — this is the only element that remains visually stable regardless of the mask.
Splash screen: brand splash or interface screenshot
There is a widespread misconception that should be addressed separately: a splash screen is not a place for a flashy logo animation. Apple explicitly states the requirement: the launch screen should look like the first screen of the app, not as a separate brand splash. The goal is to create an illusion of instant launch: while the app is loading, the user sees a static snapshot of the interface (header, background color, sometimes a simplified skeleton of content), rather than a spinning logo on a white background.
This does not mean that the brand style disappears from the splash screen — on the contrary, it manifests through the background color, the shape of the header, the typography of the title, which match what the user will see a second later. The difference in approaches:
| Approach | What the user sees | Risk |
|---|---|---|
| Branded splash screen with logo animation | Static or animated logo for 2-3 seconds | Feeling of long loading, a gap between the splash and the actual interface |
| Screenshot of the first screen (Apple recommendation) | A simplified copy of the real UI with brand colors and shapes | Requires synchronization of the splash mockup with the actual layout at every redesign |
Design system: how to document icons and splash screens for developers
Most brandbooks stop at colors and typography, leaving icons and splash screens to developers' discretion. This creates a gap between design and implementation — a typical reason why brand identity becomes scattered in an app after the first major update.
The developer guideline should include system rules, not images:
- A vector master file of the symbol with designated safe zones for iOS and Android separately;
- A size correspondence table: from 1024×1024 (stories) to 20×20 (notifications, iOS);
- A rule for constructing foreground/background layers for an adaptive Android icon, with specified allowable shift when mask changes;
- A splash screen layout tied to the actual layout of the first screen, with versioning — when the main screen design changes, the splash screen is updated synchronously;
- Color tokens for the icon and splash background that match the brand's main palette, not picked 'by eye' for a specific release.
Errors that cause an app to be rejected or lose downloads
Some errors are purely technical and lead to rejection during moderation, while others are stylistic and simply reduce conversion to installation.
- Text badges on the icon (e.g., 'Top', 'Sale', star-rated numeric rating) are a direct reason for rejection in Google Play and App Store;
- Brand name in small text inside the icon — when scaled to 29-40 px, it becomes an unreadable blob;
- Manually adding shadow and rounding to an iOS icon — conflicts with the system's automatic mask;
- Insufficient margins on the foreground layer on Android — the logo gets cropped when the mask shape changes across different shells;
- An animated brand intro instead of a screenshot of the interface on the iOS splash screen is not formally prohibited, but gives the impression of slow startup and does not comply with Apple's guidelines;
- Different visual style of the icon and the internal UI — the user will not recognize the brand after installation that they just interacted with in the store.
Hypothesis testing: A/B testing of the icon in the stores
A brand style icon does not have to be intuitively recognizable — both platforms provide tools for testing. In Google Play, this is Store Listing Experiments, and in the App Store, it is Product Page Optimization. Practice shows that platform audiences react differently: an icon variant that increases conversion in the App Store may decline in Google Play, and vice versa. Therefore, a unified brand mark is the foundation, but the final decision on background contrast, color saturation, or the angle of the symbol should be tested separately for each platform, rather than automatically transferring the winning variant.
A practical rule for adaptation: take the brand mark and remove everything that does not read at a scale of 29×29 px (the minimum size on iOS). If a readable silhouette remains—this is a candidate for an icon. If an unreadable blob remains—then a separate symbol is needed, built on the same color and geometry as the main brand mark, but without details: no inscribed text, no thin lines, no semi-transparent layers.
iOS and Android: two different technical languages of one icon
This is where the real complexities of the brand style in the application begin — the platforms physically process graphics differently, and one layout cannot be mechanically stretched across both.
| Parameter | iOS | Android |
|---|---|---|
| Source format | 1024×1024 PNG, without transparency, solid background | Adaptive icon: two layers — foreground 108×108dp and background |
| Shape | Square — mask, rounding, and shadow are added automatically by the system | The system itself forms the shape (circle, drop, square) depending on the phone's shell |
| Size in the store | 1024×1024 px in App Store | 512×512 px in Google Play |
| Response to theme | Fixed view | With Android 13 system can adapt icon colors to user wallpapers (Material You) |
The main mistake at this stage is manually adding rounded corners or shadow under the iOS icon. Apple does this automatically at the system level, and duplication results in a visual artifact: double shadow, uneven edge. On Android, the reverse problem occurs: if the foreground layer does not leave sufficient margins (safe zone 66×66 dp, approximately 61% of the 108×108 dp area), the logo will be cropped at the edges when the mask shape changes on some shells.
How to reconcile both requirements without losing brand style
A working approach is not to draw a separate 'iOS icon' and 'Android icon', but to create one master symbol on a transparent background with sufficient margins, then build two tech packages for it: fill for square for iOS and foreground/background separation for Android. The background color in both cases should be brand-specific — this is the only element that remains visually stable regardless of the mask.
Splash screen: brand splash or interface screenshot
There is a widespread misconception that should be addressed separately: a splash screen is not a place for a flashy logo animation. Apple explicitly states the requirement: the launch screen should look like the first screen of the app, not as a separate brand splash. The goal is to create an illusion of instant launch: while the app is loading, the user sees a static snapshot of the interface (header, background color, sometimes a simplified skeleton of content), rather than a spinning logo on a white background.
This does not mean that the brand style disappears from the splash screen — on the contrary, it manifests through the background color, the shape of the header, the typography of the title, which match what the user will see a second later. The difference in approaches:
| Approach | What the user sees | Risk |
|---|---|---|
| Branded splash screen with logo animation | Static or animated logo for 2-3 seconds | Feeling of long loading, a gap between the splash and the actual interface |
| Screenshot of the first screen (Apple recommendation) | A simplified copy of the real UI with brand colors and shapes | Requires synchronization of the splash mockup with the actual layout at every redesign |
Design system: how to document icons and splash screens for developers
Most brandbooks stop at colors and typography, leaving icons and splash screens to developers' discretion. This creates a gap between design and implementation — a typical reason why brand identity becomes scattered in an app after the first major update.
The developer guideline should include system rules, not images:
- A vector master file of the symbol with designated safe zones for iOS and Android separately;
- A size correspondence table: from 1024×1024 (stories) to 20×20 (notifications, iOS);
- A rule for constructing foreground/background layers for an adaptive Android icon, with specified allowable shift when mask changes;
- A splash screen layout tied to the actual layout of the first screen, with versioning — when the main screen design changes, the splash screen is updated synchronously;
- Color tokens for the icon and splash background that match the brand's main palette, not picked 'by eye' for a specific release.
Errors that cause an app to be rejected or lose downloads
Some errors are purely technical and lead to rejection during moderation, while others are stylistic and simply reduce conversion to installation.
- Text badges on the icon (e.g., 'Top', 'Sale', star-rated numeric rating) are a direct reason for rejection in Google Play and App Store;
- Brand name in small text inside the icon — when scaled to 29-40 px, it becomes an unreadable blob;
- Manually adding shadow and rounding to an iOS icon — conflicts with the system's automatic mask;
- Insufficient margins on the foreground layer on Android — the logo gets cropped when the mask shape changes across different shells;
- An animated brand intro instead of a screenshot of the interface on the iOS splash screen is not formally prohibited, but gives the impression of slow startup and does not comply with Apple's guidelines;
- Different visual style of the icon and the internal UI — the user will not recognize the brand after installation that they just interacted with in the store.
Hypothesis testing: A/B testing of the icon in the stores
A brand style icon does not have to be intuitively recognizable — both platforms provide tools for testing. In Google Play, this is Store Listing Experiments, and in the App Store, it is Product Page Optimization. Practice shows that platform audiences react differently: an icon variant that increases conversion in the App Store may decline in Google Play, and vice versa. Therefore, a unified brand mark is the foundation, but the final decision on background contrast, color saturation, or the angle of the symbol should be tested separately for each platform, rather than automatically transferring the winning variant.
Recent articles
MegaFon, BMW, VTB and more 240+ companies. See how it looks in the showcase reel:
Our branding agency is approached to order:
Branding agency services
