Exporting PDF assets for iOS: where rendering breaks
A raster icon is stored in a fixed pixel grid, while screens differ in density. The same file stretched to another scale is blurred by interpolation: edges lose sharpness, thin strokes merge, and on some devices you get blurry icons on different screens. That is why preparing graphics for iOS starts not with slicing, but with choosing a storage format.
Manual size slicing only masks this. The designer delivers several scale factors for each icon, multipliers are recalculated manually, and adding one icon repeats the entire cycle.
If line thickness changes in the layout, the grid is rebuilt from scratch, and the discrepancy between scale factors is caught on a live device.
The app build weight with this approach grows linearly with the number of scale factors. The same symbol sits in the distribution several times, the asset catalog grows, and no new screens appear.
Exporting PDF assets removes both limitations: the vector contour is stored once and rendered for the required screen density on the spot. The icon remains sharp on both a compact and a large display, and the project contains one source image instead of a set of files.
Below we look at exactly where rendering breaks when moving a vector into the catalog, how the rendering rule is configured, and which flaws in the source contour surface after the build.
What changes after switching to vector graphics sets
Previously, each icon lived in the project as a set of raster slices for different screen densities: separately for compact devices, separately for large ones.
Replacing one detail meant re-exporting the whole set, the risk of forgetting a size, and desynchronization between the layout and the app.
With vector graphics sets, the single source for an icon is a PDF in the asset catalog, and the system builds the required scales itself during rendering.
This yields stable interface rendering: the vector does not get blurry or clipped at fractional scales and looks the same on current and future devices.
At the same time, a whole class of layout defects goes away — shifted spacing after a layout edit, different versions of the same element on adjacent screens, and lost sharpness in small pictograms.
Reducing build size is a consequence of the same order. Instead of four or five raster files per element, one compact vector remains, and in a large icon library this is a noticeable share of the artifact, while the source storage stops growing with copies for each size.
We maintain a separation rule: vector for icons, pictograms, and line graphics; raster for photos and complex effects with shadows and blend modes, which are transferred unpredictably in PDF.
Designers deliver sources from Figma already in the required format, and the build checks the catalog for broken and extra elements — discrepancies are visible before release, not in the finished app.
Ways to prepare graphics: comparison of working options
When a layout is built from icons and simple shapes, the way graphics are stored determines how much the build weighs and how much manual work each change will take.
Vector, a set of raster sizes, and code-based rendering produce the same result on screen, but differ in maintenance: one option survives a change of densities without new files, another does not.
What is chosen in practice
| Option | When it fits | Limitations |
|---|---|---|
| Vector in the asset catalog | Icons, logos, line graphics, elements that scale to any density | Does not handle photorealism, soft shadows, raster textures, and complex gradients — it is rasterized during the build, not at launch |
| Set of raster sizes | Photos, screenshots, illustrations with noise and translucency | Each new density means a separate file and a separate export; build size grows in proportion to the number of variants |
| Code-based rendering | Simple shapes, indicators, elements that change color and size by state | Limited by rendering capabilities; duplicating a complex shape in code is more expensive than exporting the source once |
The difference shows up during edits: with the vector option, one source changes; raster requires rebuilding the entire size range; and code requires manually synchronizing the shape with the layout.
That is why a mixed set is the norm: vector for icons, raster for content, code for dynamic elements.
Implementation stages: from source audit to handover
The workflow is structured so that graphics defects are found in the early steps, where a fix takes hours rather than turning into a rebuild of the release. First we record the current state of the catalog, then set the rules, and only after that do we launch batch conversion.
Order of work
- Asset catalog audit. We inventory the sources, mark duplicates, outdated button states, and elements without a transparent background. The output is a map: what goes to vector, what remains raster, and why.
- Graphics naming scheme. We set a unified name format by element role, size, and state so that designer and developer refer to the same resource. This removes manual searching and desynchronization between layout and code.
- Conversion to vector. We convert suitable elements to PDF while preserving layers and transparency, and remove extra margins. The catalog stops storing several raster copies for different screen sizes.
- Device testing. We run key screens on real devices of different generations: we check sharpness when zoomed in, color accuracy, and behavior in dark theme.
- Graphics update policy. We describe how to add elements, who is responsible for conversion, and what checks are performed before release.
- Handover. We provide the project, naming scheme, and a short instruction so the team can continue working with graphics without us.
What we hand over: catalog, schemes, and policies
Graphics handover is not a folder with images, but a set by which the team reproduces the build without verbal agreements. Below is what exactly goes to the client along with the app and which documents the graphics then live by.
- Assembled asset catalog. Vector PDF sources arranged into sets with correct scales and rendering modes; the build takes graphics directly from it, without intermediate exports or manual file substitution.
- Catalog structure. A folder tree by module and purpose, separating shared and screen resources: you can see what can be changed without affecting other screens.
- Naming rules. A unified scheme of the form "purpose_state_scale", no spaces or mixed case, protection against duplicates — names match those in layouts, and finding a resource takes seconds.
- Scheme of screen-to-graphics relationships. A map showing which resource is used on which screens — before editing, the radius of changes is immediately visible.
- Graphics documentation. Palette, grids and spacing, sizes of active areas, states of buttons and fields, dark theme rules: the developer does not reconstruct this from the layout.
- Guide for designers. How to export vector, which layers to merge, how to check contours and fills, what to verify before handing over to the build.
- Policy for adding icons. Who initiates, through which branch the edit goes, who checks, how the asset catalog is updated, and how to return to the previous version of the graphics.
The set covers a typical risk: design is outsourced or the contractor changes, and the graphics continue to be assembled according to the document, not according to one person's memory.
Case study: removed blurry icons and sped up the build
Before
The client was a delivery service with an iOS app. The resource set contained about 60 icons and illustrations, each exported in five sizes for different screen densities — more than 280 files linked to code manually.
Editing one icon meant re-exporting the whole set, and on new displays some images looked blurry: the stretched raster produced uneven edges and blurred rounded corners.
What we changed
We converted the graphics to vector: one PDF file per element, the system selects the final size itself during rendering. In the set settings, we enabled preservation of vector data and a mode in which the icon remains sharp at any density.
Designers deliver one file instead of five — Xcode assembles them into a single catalog without manually assigning each size.
Metrics before and after
- Files in the set: 280+ → 60, one source of truth per icon.
- App build time on the build server: reduced by about a third — hundreds of extra resource copies were removed from processing.
- Rendering defect reports: from 10–12 per month to 1–2, and those are not about graphics.
- Icon edit: one file replacement instead of five exports and manual relationship checks.
A month after the switch, the client's team removed the separate graphics export stage from the release process. The freed-up time went to functionality rather than sorting out artifacts and repeated device checks.
How does a PDF contour differ from a raster set when scaling?
A PDF contour stores geometry: lines, curves, fills, and their stacking order. It has no fixed point grid, so when scaling, the system recalculates the shape to the required size and only then renders it.
The icon lands on the target number of points — rather than being produced by stretching a neighboring variant.
A raster size set is structured differently: these are pre-sliced images for each screen density scale factor. As long as the requested density matches a prepared asset, the icons' sharpness is perfect.
But in an intermediate mode — increased system scale, non-standard interface size — there is no matching file, so the nearest one is taken. Interpolation blurs the edges, and thin outlines and small details merge.
Weight is a consequence of the same nature of the data. The contour serves all densities with one file: a new screen does not increase the bundle.
The raster set grows linearly, each scale factor is stored as a separate copy, and cutting out extra variants is a compromise between weight and sharpness on specific devices.
The contour also has a cost: it is rendered on the device, and soft shadows, gradients, and translucency behave unpredictably during vectorization — and often they are still converted to raster.
Hence the mixed practice: simple geometry, logos, and interface icons benefit from the contour, while photorealistic illustrations are more stable in a raster set. Testing should be done at all densities the app supports.
Technical concerns: answering common questions
Thin lines, icons, and dark theme are where the conversion of graphics to vector PDF most often stumbles. Below are questions asked before work starts, and our answers to each.
Why do artifacts appear on thin lines?
Lines thinner than a screen pixel are rasterized during rendering. We define outlines in vector units and check the result at different scales — the contours remain even.
We already have raster sets — do we need to redo everything?
No. The catalog is expanded in stages: first we convert the icons where scaling is most noticeable, the remaining sets work alongside and are retired as they become ready.
How does graphics behave in a dark theme?
Separate variants are needed: automatic inversion breaks multicolor icons. We assemble both versions in one set, and the system substitutes the required one without code involvement.
Will multicolor icons survive scaling?
Yes, if each color is set up as a separate layer rather than mixed into a single contour. Then the shades do not "float" at large sizes — a common reason for returns for rework.
Whose sources are needed to replace graphics in the catalog?
We work with both sources from the client and layouts in curves. If only raster files are available, our engineers redraw the contours — this is a separate estimation stage.
Let's discuss the task: we'll come back with an estimate and work plan
To make the scope estimate concrete rather than approximate, to start we just need access to the repository or project archive, the set of asset sources, and the list of supported devices and system versions.
If the export is already configured — show us the current path: how a vector layout turns into a PDF and gets into the asset catalog.
Next we will clarify the details: at which build step assets are generated, who owns the sources, what the requirements are for scaling to different screens, and how the release cycle is structured.
We will separately discuss rollback — what happens to icons and images if the build is returned to a previous version.
- an estimate of the scope of work by stage: asset inventory, export setup, testing on target devices;
- an implementation plan with the order of steps and points where your team's feedback is needed;
- a scope of work with responsibility boundaries: what we cover and what remains with your developers;
- an asset catalog scheme and naming rules so that new layouts fall into it without manual editing;
- a list of checks: how to make sure PDF assets build and display correctly in all configurations;
- an option for a phased launch if the release cannot be stopped during the restructuring;
- a timeline for each stage and requirements for access needed at the start.
Describe the task in free form — with a link to the project or an example of a problematic asset. We will come back with an estimate and work plan, and we will discuss contentious points on a call with the engineer who will lead the project.