Why sharing the same SVG doesn't guarantee identical icons across iOS and Android.
An SVG icon looks perfect in the browser. You export it for Android and iOS, integrate it into both applications, and expect the same result.
But the icons don't quite match.
One looks slightly heavier. Another appears smaller. A color behaves differently. And the two platforms don't even use the same asset format.
The problem isn't necessarily the SVG. It's what happens to the SVG after export.
For cross-platform applications, SVG can serve as the single source of truth without being the format that actually gets rendered at runtime.
That distinction matters more than it might seem.
1. One source, different rendering pipelines
SVG is an excellent format for maintaining a shared icon library.
It provides resolution-independent geometry, supports reusable vector artwork, and makes it possible to manage icons independently of the platforms that consume them.
A typical workflow might look like this:
Shared SVG source → Platform-specific assets → Native rendering
The original artwork stays the same, but the delivery format changes.
For example:
| Platform | Possible asset format | Rendering |
|---|---|---|
| Web | SVG | Browser SVG renderer |
| Android | VectorDrawable XML | Android graphics system |
| iOS | PDF vector asset | Native image rendering |
| iOS | Custom SF Symbol | Apple's symbol rendering system |
These aren't interchangeable formats.
They have different capabilities, restrictions, and rendering behaviors.
Sharing the source doesn't mean sharing the renderer.
2. Android: SVG becomes VectorDrawable
Android Studio includes Vector Asset Studio, which can import compatible SVG files and convert them into Android's VectorDrawable format.
Instead of loading the original SVG directly, an application can reference the generated XML drawable.
Consider a simple SVG circle:
<circle cx="12" cy="12" r="8" fill="#2563EB"/>
During conversion, that geometry can become a path inside an Android vector drawable.
The generated resource contains elements such as vector, path, fillColor, and pathData.
A simplified example:
<path android:fillColor="#2563EB" android:pathData="M20,12A8,8 0,1 1,4 12A8,8 0,1 1,20 12Z"/>
The appearance may remain very similar, but the representation is no longer SVG.
And conversion has limitations.
Android's SVG importer doesn't support every SVG feature. Effects such as blur filters, pattern fills, and certain other advanced features may need to be simplified or removed.
Even supported geometry deserves visual inspection after conversion.
A successful import doesn't necessarily mean the icon looks exactly as intended.
Reference: Android Vector Asset Studio documentation.
3. iOS: Native vector assets and SF Symbols aren't the same thing
On iOS, the workflow depends on how the icon will be used.
For a conventional image asset, one approach is to export the artwork from SVG to vector PDF and include it in an Xcode asset catalog.
This lets developers maintain SVG as the original design source while delivering an asset through Apple's native image system.
Custom SF Symbols follow a different process.
Apple provides a template-based workflow for creating custom symbols. Developers can modify the exported SVG template, preserve its required structure, and validate it using the SF Symbols application or Xcode.
This allows custom symbols to participate in features such as different symbol weights, scales, and rendering modes.
However, an arbitrary SVG file is not automatically a valid custom SF Symbol.
A conventional vector image and a custom symbol have different requirements.
Choosing between them depends on whether the icon simply needs to appear as artwork or integrate more deeply with Apple's symbol system.
Reference: Apple — Creating custom symbols.
4. Three things conversion doesn't guarantee
Even when the source artwork is correct, three areas deserve particular attention.
Visual weight
Two icons can share identical geometry and still feel different in their interfaces.
Why?
Because perceived weight depends on more than path coordinates.
Stroke thickness, scaling, optical alignment, available space, and neighboring UI elements all influence how an icon appears.
A 24×24 SVG may look balanced in a web toolbar but slightly too heavy next to native iOS controls.
The solution isn't necessarily to modify the original icon.
Sometimes a platform-specific size or optical adjustment produces a more consistent result.
Consistency is about perceived appearance, not just matching coordinates.
Color layers
Color is another potential source of differences.
An SVG may define multiple fills, transparency, gradients, or other graphical features.
But native asset formats don't always interpret or support those features in the same way.
Android VectorDrawable supports several common vector features, but not the full SVG specification.
On iOS, rendering behavior also depends on the asset type and whether the image is displayed as an original image, a template image, or a symbol with a specific rendering mode.
An icon intended to inherit a UI color might accidentally retain its original fill.
A multicolor symbol may require additional configuration.
These differences become especially noticeable when supporting light and dark appearances.
Naming
Visual consistency is only part of the problem.
Naming consistency matters too.
Imagine that the same icon exists under three identifiers:
- SVG source:
settings-outline.svg - Android resource:
ic_settings_outline - iOS asset:
SettingsOutline
Different naming conventions aren't inherently wrong. Each platform has its own conventions.
The problem starts when the relationship between those identifiers becomes unclear.
A stable naming or mapping strategy helps teams track which assets come from the same source.
That becomes particularly important when updating hundreds of icons or automating asset generation.
5. A practical example: one settings icon, two platforms
Imagine a project that uses a shared 24×24 settings icon.
The source file is:
icons/settings-outline.svg
It contains the icon's geometry, viewBox, and color definitions.
For Android, the SVG is imported into Vector Asset Studio and converted to a drawable resource:
res/drawable/ic_settings_outline.xml
For iOS, the same source artwork can be exported to a PDF vector asset:
Assets.xcassets/SettingsOutline.imageset/
The application now has two native resources derived from one source.
But before shipping, the team should compare them in context.
Does the Android icon appear heavier?
Does the iOS version have the same apparent size?
Are both icons aligned correctly inside their buttons?
Do their colors behave as intended in light and dark appearances?
The important point is that both assets can be technically valid without being visually equivalent.
A reliable workflow includes a visual review after conversion, not just a successful export.
And if the artwork changes, both native assets should be regenerated from the same updated SVG source.
6. A small validation checklist
Before shipping icons across native platforms:
- [ ] Keep the original SVG as the reference artwork.
- [ ] Check which SVG features each conversion tool supports.
- [ ] Verify viewport dimensions and scaling.
- [ ] Compare stroke weight and apparent icon size.
- [ ] Validate fills, transparency, and color behavior.
- [ ] Test light and dark appearances where applicable.
- [ ] Maintain consistent asset identifiers or mappings.
- [ ] Preview icons inside actual UI components.
- [ ] Regenerate platform assets whenever the source changes.
For larger icon libraries, these checks can become part of an automated asset pipeline.
Automated conversion and validation can detect unsupported features or missing files. Visual regression tests can help identify unexpected appearance changes.
Human review still matters when evaluating optical balance.
7. Source consistency isn't rendering consistency
Using a shared SVG library is a strong foundation for cross-platform development.
It reduces duplication, makes artwork easier to maintain, and provides a clear reference for designers and developers.
Sites such as SVGicons.com can help developers discover reusable open-source SVG artwork to use as a starting point.
But selecting or exporting the SVG is only the beginning of the asset pipeline.
Native platforms have their own rendering systems, asset formats, and interface conventions.
Trying to force every platform to use exactly the same runtime representation isn't always necessary — or desirable.
The better goal is to maintain a common source while validating each platform's output.
One source. Multiple outputs. Consistent visual intent.
The SVG is the starting point. The rendering pipeline determines what users actually see.
Further reading
How do you manage SVG-to-native icon conversion in your projects? Do you automate the exports, or maintain separate assets for each platform?
Top comments (0)