Inconsistent icons in a mobile app: where the interface breaks
Mobile app icons rarely make it into the release plan as a separate task — they are prepared in the final week, between the build and submission for review.
The designer hands over the icons as one set, the developer inserts them as is, and graphic inconsistency appears in the app: some icons are cropped at the edges, some are designed for the light theme and disappear on the dark one, and some are stretched to the proportions of another platform.
Then interface divergence between platforms comes into play. The same icon on iOS and Android is rendered using different masks: on one system it is inscribed in a circle, on the other — in a rounded square.
If the set was prepared for one platform and simply transferred to the second, half the icons lose margins at the edges, and small details blur into a smudge on a real screen.
The cost of such divergence is a build being returned from review.
The design rules in Apple Human Interface Guidelines and Material Design describe margins, grid, and icon behavior in the dark theme; if the set does not comply with them, the build is returned, and fixing it runs into a new build and another moderation queue. When releasing to both systems, the cycle is completed twice.
A separate pain is icon edits after release. You cannot replace a single icon in the store: it is hardcoded into the build, so the fix waits for the next release and again goes through the full review cycle. A graphic error visible on the first screen has to be tolerated for weeks.
We examine how this is solved: how correct sets for both platforms, light and dark themes, are assembled from a single source, and why edits then stop being emergencies.
What a unified graphics set provides: faster assembly and fewer edits
A single source of graphics instead of manual version reconciliation
Icons live as a component library in Figma: one master per glyph, vector rendering, pixel-grid alignment.
A screen is assembled from references to the master, not from file copies, so an icon edit propagates across all layouts at once — manual version reconciliation between screens and platforms leaves the process.
A single source of graphics saves time not at the moment of drawing, but on every subsequent screen: a new layout is assembled from ready-made symbols rather than drawn from scratch.
The share of layouts returned for revision due to discrepancies between screens drops — edits become pinpoint rather than cascading.
A shared symbol system removes an entire class of errors
Screen densities and icon sizes are exported from a single master, so there are no "shifted" stroke thicknesses or different optical weights between platforms.
States — active, inactive, pressed — are described by component variants rather than separate file sets: the developer does not assemble the icon piece by piece or guess spacing during layout.
The speed of producing screens increases due to predictable sizes and anchor points that layout relies on.
Graphic consistency stops depending on who exactly drew a particular screen — a new person on the team joins a ready-made system rather than reconstructing it from scattered files.
Options for delivering the set: separate kits or a single source
An icon set can be delivered in different ways, and the choice determines how edits reach release.
Separate kits for iOS and Android live independently, a single source is assembled into the formats of both platforms from the same sources, and between them there is a hybrid path with manual refinement.
Separate kits for iOS and Android
Each platform receives its own set of raster and vector files, with the master file stored alongside. This is done when platform requirements differ in the shape of the sign and the shared artwork would have to be desynchronized anyway.
The limitation is predictable: an edit is repeated in each kit, discrepancies accumulate and surface during review before publication.
A single source and platform-specific assembly
Vector sources are stored as one set, from which the build distributes sizes, densities, and formats for each platform. An edit in the source propagates across the entire set at once, and the change history remains in the version control system.
Platform adaptation of graphics here is done by build parameters rather than manually — this is the main limitation of the option.
A hybrid path with manual refinement
The shared source is responsible for the base shape and color, while individual signs are refined for the platform manually and saved as overrides. It suits cases where most of the set is shared, but several icons require individual optics.
| Graphics delivery option | When it fits | Limitations |
|---|---|---|
| Separate kits | Platform requirements differ in the shape of the sign | Edits are duplicated, versions diverge from each other |
| Single source with assembly | Most signs are shared, releases are frequent | Platform refinement is limited by build parameters |
| Hybrid with manual refinement | Shared base plus individual signs for the platform | Overrides need order, otherwise desynchronization |
How we assemble and implement icons: work stages
An icon set breaks not at the drawing stage but at implementation: files arrive with different names, some formats are not picked up by the build, and on a real screen the icon fails by contrast in the dark theme.
We run this work as an engineering process with fixed control points — from graphics inventory to set acceptance.
How the icon set implementation stages are structured
- Graphics inventory. We review current resource catalogs and materials in app stores: we find duplicates, outdated versions, and graphics drawn for a specific screen. The output is an icon registry indicating where each one is used.
- File naming scheme. Before assembly, we fix the directory structure and naming rules: the name reflects purpose, size, and theme, not the author. This removes manual renaming in the next release.
- Kit assembly. We prepare vector sources and derived raster sets for the required display modes, separately — variants for the dark theme, selected state, and store listings.
- Testing on real screens. We run the set on live devices and emulators: we check readability on small and large diagonals, behavior in the dark theme, and grid alignment.
- Set acceptance. We check the result against the registry: everything is in place, names match, and there are no extra files. Discrepancies are closed before handover.
- Handover and training. We provide sources, the resource catalog, the registry, and naming rules, and show the client's team how to add a new icon without breaking the structure.
What remains on the client's side
The kit is connected to the project without manual name editing, and the registry and naming rules then work as an internal standard. A new icon is added in one step — without unraveling someone else's layers and rebuilding the entire set.
What we hand over: sources, design rules, and regulations
Assembling an icon is half the work. The other half is making sure that six months later a new section in the app does not require redrawing the entire set, and that assembly for each platform does not depend on someone's memory of the required sizes.
That is why we hand over the set not as output images but as a working kit: sources, rules, and regulations by which it can be expanded without us.
What is included in the kit
- Working sources — vector files with organized layers, individual symbols, and master pages: an edit to one shape propagates across the entire set, not across ten copies.
- Assembled platform kits — ready-made sets in the required formats and sizes, with correct transparency and without manual refinement on the development side.
- Graphic design rules — grid and spacing, line thicknesses, radii, behavior of small details at minimum sizes.
- Naming rules — a unified scheme for file and symbol names, so an element can be found by search rather than by browsing folders.
- Set documentation — a short reference: where it is located, how to assemble it, what to do when versions diverge.
Rules and workflow
- Description of access rights to the graphics repository — owner, editors, viewers, and the procedure for granting rights to a new person.
- Set update regulations — how a new symbol is added, who approves it, in what time frame, and how the version is recorded.
Such a kit covers the typical scenario: the set lives and expands within your team, and we remain on standby — for example, when there are so many symbols that the entire system needs a redesign.
Case study: a single graphics source removed discrepancies between platforms
Situation before
The client supplied graphics as an export from layouts: each symbol in three sizes, some as raster, some as outline, with stroke thickness and corner radii set manually and separately for each platform.
A new symbol was drawn twice, files were connected by names, and by the end of the release cycle 8-12 edits had accumulated — the grid, optical size, and active state color diverged.
What we changed and what the result was
We assembled a master set in Figma as a single source: grid, key lines, stroke thickness, and sizes were moved into variables, and export to vector formats is done with one command.
The icon became a component with state variants, so a new symbol is assembled from ready-made parts rather than drawn from scratch.
The share of discrepancies between platforms fell from a third of the set to zero — mismatches are caught by automated validation during assembly, not by the client at acceptance.
The time to add a new symbol decreased from several hours to 20-30 minutes, including export and connection to both projects. The number of edits per release cycle went from 8-12 to one or two, and those concern the meaning of the icon, not its geometry.
Client feedback: "we stopped arguing about which file is current" — the icon set is updated from one place, and both platforms get the same result.
How does graphics adaptation for iOS differ from Android?
The difference begins with who owns the shape. In iOS, the system itself applies the rounded mask, so the designer provides a full square, and the corners are cut on the device — there should be no transparency in the source, and the background is part of the icon.
In Android, a two-layer scheme is used: the background and symbol lie separately, the device shell defines the shape and can change it from circular to rounded square, adding tilt when the screen rotates.
The key discrepancy is in safe zones. In Android, the symbol must fit within an inner circle that is noticeably smaller than the canvas: the remaining ring goes under the mask and parallax.
In iOS, the mask cuts away much less, so the same artwork, tightly fitted into the Android zone, looks small and lost on iOS. This is where a separate platform-specific version comes from — a matter not of taste but of geometry.
The second layer is the optical weight of the symbol. On iOS, the icon more often sits on a solid-color backing, and thin lines lose contrast on it; on Android, the symbol slides over a moving background, and the same lines fall apart when tilted.
Standard thicknesses have to be differentiated: on one platform we make the stroke denser, on the other we lighten it, and we compress the composition toward the center.
One shared file works where the sign is simple, centered, with margin at the edges, on a calm background without gradients and without elements at the boundary of the safe zone.
A separate version is needed if the silhouette depends on the shape of the corners, there are small details, a complex background, or support for the dark theme and monochrome mode is required — there the mask and recoloring break the original intent.
Before handover, we overlay the layouts onto the real platform masks, test contrast on light and dark backgrounds, and view the icon at a small size, where the weight discrepancy becomes apparent. This is the check against platform graphics requirements — before the app goes to publication.
Common technical concerns: scaling, background, updating
Graphics is the part of a release where post-launch edits are most expensive, so it is better to resolve questions about it in advance.
Below are the most common: updating the set in an already published product, partial redrawing, kits diverging during synchronization, lost sources, and remote work with the client's team.
The app is already released, but the icon set is outdated. Can only the graphics be updated?
Yes. We assemble a new kit for the current design, agree on reference sizes, and deliver it as a separate package — the rest of the release code is not affected. It is only important to compare the silhouette with the already published version so that recognizability is not lost.
One icon in the set needs to be redrawn — will everything have to be redone?
No. If the master files with layers are preserved, only the required sign is edited, and the rest remain untouched. We synchronize it with the shared grid and the optical weight of its neighbors; otherwise one element starts to "fall out" of the row.
What should be done if kits for different platforms diverge during an update?
We maintain a single master file from which both sets are generated, so divergence is excluded by design. Scaling and backing rules are set separately: how the sign behaves on light and dark backgrounds and what falls within system sizes.
The sources are lost. Can the set be restored?
Yes. We redraw the sign as a vector based on the raster reference and rebuild the layered structure, checking the result against reference sizes. As a result, the client receives editable files, not just ready-made images.
Our team works remotely. How does approval work?
We approve using check sheets: we show the same sign in several sizes and on different backings, so decisions are made based on the actual result, not on zoom. Edits are recorded in a shared archive, so both sides always have the current version.
Let's discuss the task and come back with a plan: scope, timeline, workflow
To make the conversation substantive, it is enough to gather a minimum of inputs for the first meeting: we review the current set, check it against app store requirements, and come back with an estimate and a graphics work plan.
Below is what to prepare so the task can be discussed right away and iterations are not wasted on clarifications.
- Platforms and scope: iOS, Android, tablets, watches, and wearable versions — this determines the number of sizes, the set of rounding masks, and the delivery scope.
- Current sources: vector master files, layers, fonts, palette. If there is no master file, we plan to restore the geometry from raster.
- Examples of problematic screens: where the icon gets lost in the dark theme, blends with the dock panel, or is cropped in a circular mask.
- Review requirements: opaque background, safe margins, correct rounding — store automation rejects the build if the set does not pass validation.
- Approval points: who makes the decision on graphics, who approves the final set, and on what dates this happens.
- Set handover procedure: repository or archive, master file and export formats, usage rights, how to make edits after release.
- Build release dates: the graphics work plan and approval timeline are calculated from them.
If some points have not yet been gathered, this does not block the conversation: based on the product description, we will help determine what to request from the designer or contractor who made the set earlier. Describe the task — we will come back with an estimate, delivery scope, and workflow.