Why preparing iOS assets breaks app releases
A single design goes into development, and then manual work begins: for each graphic scale — @1x, @2x, @3x — the image is exported separately, renamed, and sorted into folders.
The designer handed over one set, the second was drawn from memory, the third was taken from a previous release — and no one can say anymore which file is current and which is left over from a previous iteration.
After a couple of releases, iOS asset preparation turns into archaeology: icons sit in three places — some in the image catalog, some next to the code, some in an old branch.
A one-slot error (a raster for a large screen substituted instead of the base one) is caught by neither review nor automated tests — it surfaces with the user: broken layout on screens, blurry icons, cropped banner edges. Symptoms come from different places, and the cause has to be searched for anew in every release.
The cost of this scheme accumulates quietly: no one cleans up the overgrown image catalog, duplicates drag from version to version, and the app's weight grows on data the user never sees.
Rollback also becomes more complicated — it's unclear which graphic set corresponds to the previous build.
This is solved by a single source of truth: graphics are stored in a master format, the required scales are generated automatically, and the correctness of the set is checked at the build stage. Below, we break down how to build such a pipeline and what it changes in the release process.
What a unified graphics pipeline in an app provides
Scattered graphics are a common source of a "floating" interface. The designer delivers images in several scales, some are redrawn after approval, some remain in only one size.
The result is predictable: on a tablet the logo is stretched, the icon in the list is blurry, and every edit goes through a developer and an unscheduled build.
A single graphics source removes this branch entirely. The vector source and a single name registry sit next to the code, derived scales and raster copies are generated automatically during build — not a single file is prepared manually.
We keep sources in Figma with shared component libraries: the asset name matches in the design and in the project, and a discrepancy is visible during design review, not during build testing.
The effect is noticeable in two metrics at once. The build step is reduced from minutes to seconds, because instead of manually adding files, generation and reuse of unchanged assets are at work.
The app's weight drops by a quarter or more — duplicates and scales that no screen requests do not make it into the build.
Separately, a class of failures — "graphics did not match the design" — goes away. There is nothing to check: there is one source, and what has been approved makes it into the build without manual transfers.
The speed of releasing updates increases: editing an icon or banner stops being a developer task — the designer changes the source, and the nearest release picks it up on its own.
Rollback also remains operational: the previous graphics set is restored from history in a single operation.
Three ways to assemble graphics for different screens
iOS asset preparation begins with a single problem: one image must look sharp on different screens, but take up different amounts of space. A compact screen is fine with the base scale, an enlarged one needs a dense one.
If you slice scales manually and then edit the source, it's easy to get a desync: on some devices the icon is blurry, and the build has gotten heavier by dozens of megabytes. We break down four approaches and their limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Manual scale slicing | Single images that rarely change | Editing the source requires re-slicing; desync is caught only on the device |
| Graphics generation script in the build system | A stream of same-type icons and illustrations, UI themes | Requires vector sources and a person to maintain the script; an error breaks all scales at once |
| Image catalog in the project with autogeneration | App screens and system UI elements | All scales go into the distribution — build weight grows with the number of images |
| External image delivery | Content graphics updated without releasing a new version | Network dependency: cache, offline fallback, and load-time control are needed |
In practice, approaches are combined: the interface is assembled via the catalog, a stream of same-type icons is handed to the script, and content images go to external delivery. Then editing the source does not trigger manual work, and the build weight remains predictable.
Stages of bringing order to app graphics
Bringing order to graphics is cheaper not by renaming files, but by inventory: first we record how many images are actually used, where duplicates are, and which sets are missing densities.
Such an audit provides a reference point — after the work, you can see exactly what changed, rather than "it became somehow cleaner."
- App graphics audit — we go through the screens and check which images are loaded and which are left over from deleted sections and sit as dead weight in the build.
- Image inventory — we bring what was found into a registry: purpose, screens of use, density set, owner. The registry immediately shows duplicates.
- Storage scheme and file naming rules — we arrange sources and derivatives into catalogs so that the name unambiguously describes the screen, element, and state. Manual "icon_final_2" leaves the process.
- Pipeline setup — scales and formats are generated from a single source, extra variants do not make it into the build: the installation package size stops growing with every release.
- Device testing — we look at densities on different screens, when switching theme and orientation: blurry edges and "jumping" sizes are caught here, not by users.
- Team handover — the regulation, name templates, and acceptance checklist remain in the repository so that the next design goes through the same route without disassembly.
After that, maintenance proceeds predictably: a new screen follows the same path and the same checks.
What remains in the project and documentation after the work
The work ends not with an assembled catalog, but with rules by which the next designer or developer will reproduce the result without us.
The project receives the catalog structure, regulations, and instructions — everything that describes where each @1x, @2x, and @3x comes from and what to do when adding new graphics.
- Catalog structure — folders by modules and screens, with icons, illustrations, and backgrounds separately. A new screen takes a known place, not "next to a similar one".
- Naming rules — Latin characters, lowercase, a meaningful name without dates and versions, scale only as a suffix. The file name immediately shows which screen it belongs to.
- Scale map — a table where for each set it is indicated which screen sizes it covers and what serves as the source. It is clear which file to redraw, not stretch.
- Image handling regulation — where the source is, who owns edits, at what point the catalog is rebuilt, and what counts as a completed change.
- Guide for designers — how to prepare a design for export: cropping to the pixel grid, transparency where needed, vector sources for scalable elements, layer names matching file names.
- Development regulation — how graphics are connected, what to do when a scale is missing, and why names cannot be changed manually.
- Graphics documentation — formats and their purpose plus a list of typical defects: stretched raster graphics, extra margins, opaque background instead of transparent.
- Acceptance checklist — completeness of sets, weight, matching contours at different scales; if desired, the check is embedded in the build and does not let an incomplete set through.
Artifacts reside in the project repository next to the code, so editing graphics goes the same way as editing code — with review and a clear history. After handover, the client's team adds new screens independently.
Case study: an app with an overgrown image set
An app for a retail chain with a product catalog and promo screens: graphics were updated every two weeks, and each release began with manual image export.
The designer handed over designs, the developer sorted images across three scales, names were invented on the fly, and some illustrations were duplicated under different names.
Graphics preparation consumed two or three days out of a two-week cycle, and the wrong scale periodically made it into the build — on large screens the image was blurry, and release deadlines shifted again.
What was changed
We assembled a unified image catalog in Xcode: one source per illustration, scales are assembled from it, names are set by a template, not by the author.
Promo banners were converted to vector — instead of three raster copies, one file remains in the repository, which is expanded into the required scales at build time.
On top, a check was added: an image without a complete set of scales or with a duplicate name stops the build before review, rather than going to the app store.
Metrics before and after
The set shrank from 620 files to 390 — duplicates were cleaned out and are no longer created. Graphics preparation time dropped from two or three days to three or four hours; the update release cycle — from two weeks to one week.
The "wrong scale" error class has disappeared from releases: over the last ten releases, not a single rollback due to graphics.
What to do if assets have already scattered across repositories?
The picture is familiar: icons and backgrounds sit in the app's main repository, some — in a separate design system repository, and another part — in branches of inherited modules that no one has touched for years.
The same icon exists in two or three copies, and their scale sets do not match: somewhere all three densities are present, somewhere only two, and somewhere the original has been replaced with a stretched one.
While one person edits graphics, this is tolerable. As soon as two people work on images, the copies diverge: in one set @3x is updated, in another the old @2x remains, the third has lost @1x entirely.
This is caught not by review, but by testing on a device with the required screen density — or by a user who sees blur and edge shifting.
We move to a unified scheme without stopping development. First, inventory: a script traverses repositories and branches, calculates the content hash of each file, and builds a map — where the original is, where the copy is, where the set is incomplete.
Then we choose the source of truth: as a rule, this is the design system's resource catalog, connected as a separate module that all app targets build.
Migration proceeds in portions — one screen or module per iteration. During the transition period, the old addresses remain functional: the build takes graphics from the new catalog, and old references are resolved through a thin compatibility layer.
A check is added to the build process: the set must contain all required scales, and a content hash match fails the build as a duplicate.
We connect the project's legacy to the common scheme last — when the main part of the app is already assembled from a single source.
After that, editing an icon is done in one place and propagates to all targets, and the question "where is the current version" stops arising.
Technical doubts: scales, weight, privacy
Three densities — @1x, @2x, @3x — cover almost the entire device fleet, but do not eliminate manual decisions. We deliver icons and logos as vector, and prepare raster sets only where vector is unavailable: photo content, textures, complex transparency effects. Otherwise, dozens of files settle in the build that no one checks on real screens.
Build weight grows nonlinearly: if you put a 3x raster under every image, the distribution gets heavier noticeably faster than the quality the user sees improves.
We configure the selection policy once in Sketch, then checks run automatically — duplicates, lost densities, and outdated versions are cut off before the build, not after release.
Are three densities enough for all screens?
For most — yes. We separately check non-standard aspect ratios, dark theme, and large system font. This is not a new scale, but additional sets of checks.
What about licenses for fonts and graphics?
A font inside an app is licensed separately from the desktop one; some typefaces cannot be embedded. We verify the terms with the rights holder before export and record in the asset registry what and in what form is allowed to be distributed.
How to handle closed materials?
We work with an export of the required layer, test data, and depersonalized designs. We grant access on a targeted basis and revoke it after handover — sources do not leave the client's perimeter.
Let's discuss the task: how we enter your project
We start the conversation not with a template list of services, but with an analysis of your task: what screens and scenarios are in the app, at what stage the codebase is, what is already done and what remains to be built.
This way the estimate relies on the real scope of work, not on average market figures. Then we fix the order of work and the form in which we will return with an implementation plan and timeline.
To prepare an estimate and work plan, we need from you:
- Understanding of the product — the app's purpose, platforms, expected load, and target audience.
- Interface materials — source designs, asset catalog, screen states, dark and light themes, if they are provided for.
- Accesses — repository, backend test environment, publishing account, and signing keys, if the app has already been released.
- Boundaries of responsibility — what we cover and what remains on your side: backend support, content, design of new screens.
- Constraints — date-bound deadlines, compatibility requirements with already working versions of the app.
- Acceptance point — who on your side accepts the result and by what criteria.
Based on the analysis, you receive a document with a breakdown into stages, dependencies between them, calendar deadlines, and readiness criteria for each block. Describe the task in free form — we will return with an estimate, a plan, and a proposal for the order of work.