Mobile application identity: icon and UI-kit
The app icon and the logo are two different design objects
The logo solves the task of brand recognition in any context: on the website, in advertising, on packaging. The app icon solves a narrow task — to be a clickable point on the home screen among dozens of other icons, often the size of a fingernail. Trying to cram the full logo with text or a complex composition into an icon is a common mistake. When scaled to 40×40 pixels, details turn into a mess, and letters become illegible.
The working approach is to take only the mark or its fragment from the logo, simplify the form, and adapt it to a square or rounded square. Apple and Google in their guidelines explicitly recommend avoiding text in app icons, except in cases where the letter is the mark itself (as with one letter in well-known services). The icon should be readable by silhouette, not by details.
App Store and Google Play requirements: difference in approach, not just pixels
Technically, the difference between the platforms does not reduce to file size. Apple requires a single static square 1024×1024 px without transparency and rounded corners — the system itself applies a mask. Google, starting with Android 8, is more complex: in addition to a static icon 512×512 px for the Play Store storefront, the developer must provide an adaptive icon consisting of two layers.
| Parameter | App Store (iOS) | Google Play (Android) |
|---|---|---|
| Main size | 1024×1024 px, single file | 512×512 px for storefront + adaptive icon |
| Shape | Square, mask applied by the system | The shape of the mask depends on the launcher (circle, square, drop) |
| Layers | One flat layer | Foreground + background, separate PNG/Vector |
| Transparency | Not allowed | Allowed in the foreground layer |
| Dark theme | Supported by a separate set from iOS 18 (tinted/dark icon) | Themed icon via Material You, monochrome layer |
The main takeaway from this table: designing 'one icon for all' is a path to redesigns. Two production files with different build logic must be planned from the start.
Adaptive icons on Android: what lies behind the word 'foreground'
An adaptive Android icon is not one image, but a constructor made of two layers of 108×108 dp each. The background layer is usually solid or with a light gradient, while the foreground carries the main symbol. The problem is that the system crops these layers with different masks depending on the device manufacturer and launcher — sometimes it's a circle, sometimes a drop, sometimes a square with rounded corners.
The guaranteed visible area is only the central 66×66 dp. The remaining 18 dp on each side are reserved for a safe margin and parallax effect during phone rotation. If the symbol touches the edges of this zone, it will be clipped under an aggressive mask (e.g., a circular one). Practical conclusion: the symbol should be drawn with a margin inside the safe zone, not stretched across the entire 108×108 canvas — this is a typical mistake that causes icons to appear cropped on some devices after publication.
Light and dark themes are not cosmetics, but separate design contours
Dark mode has long ceased to be an optional feature, and icons with UI components that are not adapted for it look like forgotten debts. Here, two different requirements apply — to the app icon itself and to interface elements inside the app.
- For the application icon — avoid thin lines and small details that disappear on a dark launcher background; use solid, high-contrast shapes.
- For UI elements — ensure a contrast ratio of at least 3:1 per WCAG AA/AAA if the icon is used separately, without accompanying text.
- Do not mechanically invert colors — dark theme requires separate calibration of saturation, otherwise bright accent colors 'shout' on a dark background.
- Test components on real devices with OLED screens, where black is the absence of backlight, not just dark gray.
Here is where the idea of design tokens is born: instead of manually painting each button for the dark theme, semantic variables are set—such as 'background surface color', 'accent text color'—and their values change automatically when switching themes. The developer uses a token rather than hardcoding a hex code, and the entire system switches synchronously.
What a full UI-kit consists of—comparison of minimal and system sets
Often, UI-kits are confused with a set of buttons and a palette of five colors. In practice, a full system for a mobile application is structured differently, and the difference between a 'starter set' and a mature design system becomes noticeable after just two or three releases.
| Component | Minimal set | System UI-kit |
|---|---|---|
| Color | Flat palette (5-8 colors) | Semantic tokens (surface, accent, error) with versions for dark theme |
| Typography | 2-3 text styles | Full style grid with line-height, letter-spacing, platform adaptation |
| Icons | One style, different sizes S/M/L/XL | 2 fixed sizes, 2px line thickness, 3-5 styled variants |
| Components | Buttons, input fields | + cards, modals, tabs, loading/error/empty states, transition animations |
| Grid and spacing | Arbitrary values | Unified spacing scale (4/8/12/16...), grid system for different screens |
| Documentation | File in Figma | Component library synchronized with the codebase (design tokens in JSON) |
The Alpha-Bank experience shows that reducing the number of icon sizes to two and fixing the line thickness at 2px does not impoverish the system, but on the contrary — removes unnecessary decisions from designers and makes the interface visually more homogeneous. The fewer arbitrary parameters in the system, the fewer discrepancies between screens of the same application.
Application identity as a system, not a set of files
The mistake of many teams is to create the application icon separately from the UI-kit, as if these were two different projects. In reality, the icon is the entry point into the system, which should use the same palette, the same logic of forms and the same line thickness as the components inside the application. If the icon on the home screen is rounded and soft, and the buttons inside are sharp and geometric — the brand feels fragmented, even if the user cannot explain what exactly is wrong.
A systemic approach means that the palette, typography, grid spacing, and iconography style are described as unified tokens, not as individual solutions for each screen. According to the case study of the company «Zvuk», implementing such a design system reduced the time needed to develop layouts by 30-50%, and the assembly of finished screens — by 3-4 times. This is not an abstract saving: the team no longer has to come up with which shade of gray to use for a disabled button, because the answer is already fixed in the token.
Version control works here just like in code development: changes to basic tokens — color, size, corner radius — are automatically applied to all components and screens where they are used. Cross-platform compatibility is achieved not by copying pixels between iOS and Android, but by synchronizing at the logic level: the same color and shape semantics, with different technical implementations tailored to each platform's requirements. This is exactly how an icon ceases to be a 'store image' and becomes part of a cohesive brand experience.
The app icon and the logo are two different design objects
The logo solves the task of brand recognition in any context: on the website, in advertising, on packaging. The app icon solves a narrow task — to be a clickable point on the home screen among dozens of other icons, often the size of a fingernail. Trying to cram the full logo with text or a complex composition into an icon is a common mistake. When scaled to 40×40 pixels, details turn into a mess, and letters become illegible.
The working approach is to take only the mark or its fragment from the logo, simplify the form, and adapt it to a square or rounded square. Apple and Google in their guidelines explicitly recommend avoiding text in app icons, except in cases where the letter is the mark itself (as with one letter in well-known services). The icon should be readable by silhouette, not by details.
App Store and Google Play requirements: difference in approach, not just pixels
Technically, the difference between the platforms does not reduce to file size. Apple requires a single static square 1024×1024 px without transparency and rounded corners — the system itself applies a mask. Google, starting with Android 8, is more complex: in addition to a static icon 512×512 px for the Play Store storefront, the developer must provide an adaptive icon consisting of two layers.
| Parameter | App Store (iOS) | Google Play (Android) |
|---|---|---|
| Main size | 1024×1024 px, single file | 512×512 px for storefront + adaptive icon |
| Shape | Square, mask applied by the system | The shape of the mask depends on the launcher (circle, square, drop) |
| Layers | One flat layer | Foreground + background, separate PNG/Vector |
| Transparency | Not allowed | Allowed in the foreground layer |
| Dark theme | Supported by a separate set from iOS 18 (tinted/dark icon) | Themed icon via Material You, monochrome layer |
The main takeaway from this table: designing 'one icon for all' is a path to redesigns. Two production files with different build logic must be planned from the start.
Adaptive icons on Android: what lies behind the word 'foreground'
An adaptive Android icon is not one image, but a constructor made of two layers of 108×108 dp each. The background layer is usually solid or with a light gradient, while the foreground carries the main symbol. The problem is that the system crops these layers with different masks depending on the device manufacturer and launcher — sometimes it's a circle, sometimes a drop, sometimes a square with rounded corners.
The guaranteed visible area is only the central 66×66 dp. The remaining 18 dp on each side are reserved for a safe margin and parallax effect during phone rotation. If the symbol touches the edges of this zone, it will be clipped under an aggressive mask (e.g., a circular one). Practical conclusion: the symbol should be drawn with a margin inside the safe zone, not stretched across the entire 108×108 canvas — this is a typical mistake that causes icons to appear cropped on some devices after publication.
Light and dark themes are not cosmetics, but separate design contours
Dark mode has long ceased to be an optional feature, and icons with UI components that are not adapted for it look like forgotten debts. Here, two different requirements apply — to the app icon itself and to interface elements inside the app.
- For the application icon — avoid thin lines and small details that disappear on a dark launcher background; use solid, high-contrast shapes.
- For UI elements — ensure a contrast ratio of at least 3:1 per WCAG AA/AAA if the icon is used separately, without accompanying text.
- Do not mechanically invert colors — dark theme requires separate calibration of saturation, otherwise bright accent colors 'shout' on a dark background.
- Test components on real devices with OLED screens, where black is the absence of backlight, not just dark gray.
Here is where the idea of design tokens is born: instead of manually painting each button for the dark theme, semantic variables are set—such as 'background surface color', 'accent text color'—and their values change automatically when switching themes. The developer uses a token rather than hardcoding a hex code, and the entire system switches synchronously.
What a full UI-kit consists of—comparison of minimal and system sets
Often, UI-kits are confused with a set of buttons and a palette of five colors. In practice, a full system for a mobile application is structured differently, and the difference between a 'starter set' and a mature design system becomes noticeable after just two or three releases.
| Component | Minimal set | System UI-kit |
|---|---|---|
| Color | Flat palette (5-8 colors) | Semantic tokens (surface, accent, error) with versions for dark theme |
| Typography | 2-3 text styles | Full style grid with line-height, letter-spacing, platform adaptation |
| Icons | One style, different sizes S/M/L/XL | 2 fixed sizes, 2px line thickness, 3-5 styled variants |
| Components | Buttons, input fields | + cards, modals, tabs, loading/error/empty states, transition animations |
| Grid and spacing | Arbitrary values | Unified spacing scale (4/8/12/16...), grid system for different screens |
| Documentation | File in Figma | Component library synchronized with the codebase (design tokens in JSON) |
The Alpha-Bank experience shows that reducing the number of icon sizes to two and fixing the line thickness at 2px does not impoverish the system, but on the contrary — removes unnecessary decisions from designers and makes the interface visually more homogeneous. The fewer arbitrary parameters in the system, the fewer discrepancies between screens of the same application.
Application identity as a system, not a set of files
The mistake of many teams is to create the application icon separately from the UI-kit, as if these were two different projects. In reality, the icon is the entry point into the system, which should use the same palette, the same logic of forms and the same line thickness as the components inside the application. If the icon on the home screen is rounded and soft, and the buttons inside are sharp and geometric — the brand feels fragmented, even if the user cannot explain what exactly is wrong.
A systemic approach means that the palette, typography, grid spacing, and iconography style are described as unified tokens, not as individual solutions for each screen. According to the case study of the company «Zvuk», implementing such a design system reduced the time needed to develop layouts by 30-50%, and the assembly of finished screens — by 3-4 times. This is not an abstract saving: the team no longer has to come up with which shade of gray to use for a disabled button, because the answer is already fixed in the token.
Version control works here just like in code development: changes to basic tokens — color, size, corner radius — are automatically applied to all components and screens where they are used. Cross-platform compatibility is achieved not by copying pixels between iOS and Android, but by synchronizing at the logic level: the same color and shape semantics, with different technical implementations tailored to each platform's requirements. This is exactly how an icon ceases to be a 'store image' and becomes part of a cohesive brand experience.
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
