SVG preparation and cleanup for mobile applications

Exporting SVG for mobile apps: where quality is lost

A designer hands off an icon exported from the editor as is — and it stops matching the grid.

The cause is usually the artboard: the file carries a fixed width and height instead of a viewBox, path coordinates come with four decimal places, and the group itself is raised above the canvas.

When embedded, such an icon is clipped either on the right or at the bottom and lands in the layout half a pixel off from neighboring elements.

Loss of graphic quality is rarely related to the format itself.

Vector is broken by strokes that turn into a hairline when scaled; text left as a text block and requiring a font that is not on the device; raster inserts inside the file; masks, filters, and blurs that some platforms do not render. All of this surfaces at build time, not in the mockup, so it is found late.

Dark theme is a separate failure point. An icon with a hard-coded dark fill on a dark background becomes invisible, and a light patch inside it breaks the composition.

This is solved not by a second set of files, but by a fill that inherits the interface color and consistent stroke thickness.

The third cost item is app build weight. Files retain hidden layers, editor service metadata, unused crops; when several dozen icons are merged into one set, identifiers repeat, and some platforms silently render the wrong shape.

Therefore, icon preparation becomes a regular process: a unified grid, a neutral fill color, cleanup of extra contours, and automatic checks for discrepancies on every set update, rather than a one-off manual export.

Below we break down how to build this process so that the result does not depend on an individual designer's care.

What changes after clean preparation of vector graphics

Cleanup starts with an inventory: what actually goes into the build — editor metadata, hidden layers, duplicate groups, unused definitions, fractional coordinates.

An optimizer such as SVGO removes most of it automatically, but some edits remain manual — otherwise simplification eats away the icon's recognizability at small sizes.

After compression, the number of nodes in the path tree drops by a factor of 2-3, and the graphics set in the build by 40-60%.

The second effect is adaptive graphics. When an icon has no hard-coded dimensions and proportions are maintained by a unified grid, it renders equally sharply on a compact screen, on a tablet, and with system font scaling.

Raster copies for individual resolutions are not needed — the build does not grow with every new screen density.

The third layer is interface performance and rendering stability. Fewer paths — faster first screen render, more responsive transitions and animations, cold start gives graphics noticeably less time.

The share of rendering failures — a missing icon, a black square instead of an icon, a broken animation on a low-end device — goes to zero: the mockup no longer contains structures that platforms support differently.

The rule is simple: vector is checked before it gets into the mockup, not after a failure in release. Then the weight, speed, and predictability of graphics are visible in the build report, not in feelings.

SVG optimization: geometry, palette, and strokes

Export from a graphic editor almost always gives more than needed: nested groups, hidden layers, service metadata, and strokes of different thicknesses.

On the application side, this turns into extra build weight and into icons that look different in the same role — some contours are thinner, some are shifted by fractions of the grid, some do not recolor when the theme changes.

The difference between preparation options is not in the care of execution, but in how the set behaves when the product expands.

SVG optimization runs into limitations on the application side: strokes have to be converted to curves, otherwise rendering depends on the implementation and the icon "drifts" on different platforms, and the palette is reduced to a short set of colors — then the theme switches by replacing one variable, without a second set of files.

Therefore, contour cleanup and icon palette are done once as a rule, not as a one-off cleanup before release.

How we prepare graphics: stages of engineering work

The workflow is the same for a new app and for a project that has been evolving for years: first we record what is already in the repository, then we change it, and only after that we pass the rules to the team.

This way graphics can be edited without fear that the layout will fall apart or some icons will be lost.

1. Graphics audit. We count all vector files in the project, mark duplicates under different names, raster images embedded inside vector, icons without a unified style. The result is a map of the set with a list of issues for each screen.
2. Naming scheme. An icon gets a name based on its role in the interface, size group, and theme. This removes "by eye" edits and conflicts when merging branches.
3. File cleanup. We remove hidden layers, empty groups, embedded images, and styles, and crop the canvas to the actual artwork. The file shrinks severalfold, the appearance does not change.
4. Asset build pipeline. Optimization and unification are launched automatically when a file is added, not by hand. The output is ready variants for the dark theme and different screen densities.
5. Icon checking. Running through sets of screens and element states: fills, strokes, recoloring behavior, optical sizes. Errors surface before release, not from user complaints.
6. Handoff of the guidelines. Naming rules, source requirements, implementation order, and the build command are described briefly and unambiguously. A new icon goes through the same path without developer involvement.

Handoff kit: source files, rules, update guidelines

A handoff kit is not an archive of images, but a working set of rules: with it, your designer or an outside contractor can add an icon without breaking the layout or asking us again.

We assemble it so that any graphics edit is a predictable operation, and the source files in Figma remain in your account, not only in ours.

• Cleaned source files: every file has had the unnecessary removed — hidden layers, editor metadata, nested masks, duplicate strokes. What remains is a contour that renders the same in markup and in the platform's vector engine.
• Project folder structure: assets are arranged by modules and screen densities, folder names match screen names in the mockups — a new file lands in an obvious place.
• Asset naming rules: the "module_function_state" scheme, lowercase only, no spaces or transliteration; the file name immediately shows where it is used.
• Mapping table: a table "source → asset in the app → screen" that lets you find the needed edit in a minute, not an hour of searching through code.
• Graphics update guidelines: it describes who, when, and in what form sends new icons, how replacement is approved, and what happens to old sets.
• Build checks: validation of markup, size, and duplicates — a broken or bloated asset fails at build time, not in release.
• Set versioning: the previous icon kit can be restored without rebuilding mockups; rollback does not become a separate task.

The update guidelines are the most underrated item: without them, in six months the project will have three different styles of the same icon side by side, and every new edit costs more and more. The kit closes this in advance — graphics stop being a bottleneck when handing off tasks.

Case study: how vector cleanup reduced build weight

Before: how weight accumulated

We received an application with a large catalog: the set of icons and small illustrations had been assembled over years, and every release added fresh exports from mockups in Figma.

The files dragged along nested groups, hidden layers, strokes, clipped masks, and embedded raster — on some screens this caused visible artifacts and extra rendering work.

Measurements before the work: the graphics set weighed more than all the rest of the application's graphics combined, the catalog section opened noticeably longer than neighboring ones, and the share of support requests about rendering issues — cropped edges, blurry contours, shifted geometry — held at one in four.

After: what changed in the build

The analysis showed that the cause was not the vector itself, but how it gets into the build.

We fixed a single export rule: one icon — one group without nesting, curves in a common container, strokes converted to fills, extra nodes trimmed, raster inserts either vectorized or moved into a separate asset.

On top of that, we put in a check that does not let through a file with hidden layers, nested masks, or a name outside the template.

Asset weight decreased by a factor of about six, the catalog opens on par with other sections, and rendering-related requests dropped to isolated cases.

The side effect turned out to be more important than the numbers themselves: a new icon is added with a single export without manual editing, and the build size stopped growing from release to release.

What to do if graphics have already spread across builds

If the icon set has already spread across builds, you cannot rewrite it in one go: users' devices have previous versions of the app, and they continue to request old asset names.

The task splits into two independent ones — clean up the source files and do not break the already released app.

The working scheme is gradual replacement: we add new icons under new names, and keep the old ones as references to them. We remove the compatibility layer when the share of installs on versions without the update falls below an agreed threshold — usually two to three releases.

The limitation here is not in the files themselves, but in cache and build weight: while both sets are alive, the app is heavier, and screenshot checks have to be run on both interface branches.

We check compatibility on the matrix of versions users still have — then cleanup does not turn into a regression on live installs.

We choose the workflow based on device data: first we look at which versions are still active, then we fix the schedule for removing old names. This way the set spreads across builds in a controlled manner, rather than remaining "as is" for years.

Technical doubts: formats, compatibility, timelines

Objections about graphics come down to three points: whether vector will survive old system versions, how to deliver a raster fallback, and what will happen to icons in the released app. We break down how each is closed at the level of the build and asset delivery rules.

We do not translate the visual layer blindly. Photos, textures, and complex effects remain raster; interface icons, indicators, the logo, and diagrams go into contours. The output is two asset sets and a rule for choosing by system version and screen density.

How long does it take to replace an icon set in a live app?

Usually one or two release cycles, without freezing the rest of the work. Assets are changed in a targeted way: inventory and source cleanup, export, connection, interface run-through, and build size check. Screens do not need to be rewritten if the set structure is preserved.

Will we lose quality when changing the graphics format?

Vector does not lose sharpness — contours, gradients, and masks do not depend on screen density. What needs to be removed are embedded raster inserts: they add weight and artifacts when scaling.

That is why before handoff to the project there is cleanup — extra groups, hidden layers, unused definitions.

Let's discuss the task: send us an icon set and mockup

To discuss the task specifically and give an estimate of the work, rather than a "from and to" range, we need an input set.

The more complete the source files, the fewer assumptions in the estimate and the fewer edits at the stage when the app is already being built and graphics are going into release.

• Icons and illustrations in vector source files — a Figma, Illustrator, or Sketch file, not an SVG export with flattened shapes where figures have lost names and relationships.
• A list of screens and places where graphics occur: bottom navigation, statuses, empty states, onboarding, dark theme.
• The states of each icon — normal, active, inactive, pressed — if they differ visually.
• The naming rules and folder structure adopted in the project, or permission to propose our own so that names match the code.
• How graphics get into the build now: manually, through a shared repository, or a component library.
• Constraints: where animation is needed, where an icon must match on both platforms, where differences are acceptable.
• The contact of a designer or developer who will answer clarifications about layers, masks, and groups.

The review takes little time: our engineers look at where hidden layers, extra strokes, and masks remain in the source files, how fills are structured, and what of this will end up in the app's weight.

Based on the results, we return an estimate of the work, a graphics preparation plan with the order of steps — name normalization, cleanup, optimization, checking on the assembled build — team composition, and the project start date.