iOS icon: why an app is rejected during review
The iOS icon is the first element the store's automation checks when a build is uploaded, and the first at which it halts the release.
The icon requirements look trivial: a single master file in the app's asset catalog, no alpha channel, no baked-in rounded corners, shadows, or frames — the system applies the shape and mask itself. The problem is almost never in the design as such, but in how the file gets into the build.
It breaks at the junction of design and the build pipeline.
The designer hands over a finished image with transparency and already rounded corners, the developer swaps the file directly in the asset catalog, and automatic generation of derived sizes remains untouched — the set of variants diverges from what the current toolchain branch requires.
Light and dark themes also surface separately, as does the tinted desktop icon variant, which people forget to add when updating the visual style. Graphics validation at upload sees such discrepancies immediately and rejects the build with a list of missing variants.
The cost of the mistake is unpleasant because the build rejection comes at the very end: the code is checked, changes are frozen, the release is agreed with the client.
Then you have to fix assets, rebuild the app, go through graphics validation again, and return to the store review queue. With regular updates, the defect repeats from release to release because the cause lies in configuration and process, not in a particular mockup.
This area is closed not by “designer's carefulness” but by moving icon requirements into the build pipeline: the master file is stored in the repository, derived sizes and themes are generated automatically, and the set is validated before submission, not after. We'll look at how to set up an app's store visuals so the icon stops being a point of failure.
What a unified graphics system provides and how to measure it
A unified graphics system is one master file and the rules for expanding it: layers, grid, safe area, and predictable scaling logic. All sizes and states are assembled from it, including the dark theme and a monochrome variant for system hints.
Apple's requirements for the set of sizes rarely change, so the system defines them once and thereafter only reproduces them.
Edits stop multiplying across files
Changing the logo used to mean manually editing every export: one size took 20-40 minutes, and the full set — almost a designer's working day. Now the change is made in the master, and the remaining sizes are rebuilt from it. Updating takes less than an hour, and no size lags behind the others.
Manual slicing leaves the release process
Icons are assembled automatically: the required sizes and formats are produced from the master file, including a multilayer variant. 4-6 manual operations disappear from the update release, and with them the risk of mixing up a size or forgetting one of the sets.
Display failures are closed before release
The main class of problems is “the icon looks different from the mockup”: cropped edges, blur after scaling, loss of contrast on a dark background. Testing on test devices in both themes catches this in advance, so the app looks equally polished on any screen.
Stable display between updates
The rules are documented: the next designer or contractor opens the system description and reproduces the result without re-approvals. This removes discrepancies between versions and saves hours on edits and approvals with each update.
Comparison of visual design approaches: what and when it fits
An icon in a build exists in several modes: a single static file, a full set of interface states, or adaptive graphics from a vector source.
The difference shows where a product lives long — when the palette changes, the design system is updated, or a dark theme appears, the set has to be redrawn step by step.
| Variant | When it fits | Limitations |
|---|---|---|
| Static file, one raster | Prototype, internal tool, fast release | The system builds the remaining sizes itself: small details lose sharpness, every brand edit is a manual update |
| Full set of states | Product in an app store, regular releases, light and dark theme | More files in the asset catalog: without synchronization discipline, divergence between variants is visible on the home screen |
| Adaptive graphics from vector | Several sizes at once, frequent shape edits | Clean contours are required without raster inserts and effects — some of the decor simply isn't reproduced |
How to choose the mode
Light and dark theme are not a separate variant but a parameter: the palette for a dark background is selected manually, otherwise contrast on system wallpapers drops and the icon blends in.
We determine the mode by the number of states and the frequency of brand updates, not by the “beauty” of the mockup: a prototype is fine with a static file, while a production version needs a full set from one source, so a shape edit doesn't turn into redrawing four variants and doesn't diverge across platforms.
How the work proceeds: from mockup audit to handoff
An iOS icon is not a picture but a set of files with strict platform requirements: an extra alpha channel, an uneven edge, or a missing size — and validation will reject the build when uploading to the store.
So this doesn't surface at release, we follow a fixed sequence where each step is validated before moving to the next.
- Mockup audit. We analyze the source: vector or raster, whether there is transparency and rounded corners, how the icon reads on light and dark themes. The output is design edits and a set scheme for all sizes and display modes.
- Source catalog setup. We assemble images into a catalog that the build picks up: file names, mapping to sizes and display variants. An error in the structure — and the system icon will be substituted, so we validate the catalog separately.
- Layers and masks. We remove the alpha channel, align margins, and ensure the system mask doesn't eat the composition. Edges and center remain readable both in settings and in the store listing.
- Test build. We install on real devices with different screens and themes: app list, home screen, notifications, search. We separately check the cache — after an update, the system may show the old version.
- Handoff to the client. We deliver the source catalog, mockup, naming rules, and replacement instructions so the team can update the icon on its own. Plus a memo on what to check before release.
After that, the set lives together with the project: when branding changes or themes are added, iOS icons are rebuilt using the same scheme.
Set of sources, rules, and update regulations
We hand over not a set of pictures but a working kit: sources, catalog structure, and rules by which the visuals can be changed without us.
The client gets the ability to release a seasonal variant, update the palette for a redesign, or prepare a separate icon for an internal build — with a team that already knows the project, without a repeated brief and repeated drawing.
- Vector master file with separate layers: background, mark, accent elements. Layers are not merged or rasterized — an edit is made in one layer, the rest stays in place.
- Exports for all scales and display modes: regular, dark theme, tinted, and monochrome variant. For each — a file name according to our scheme, so substitution is predictable.
- Catalog structure with a slot map: which file covers which size and where exactly it lives. The set is transferred into an empty project by copying, without manual renaming.
- Visual rules: safe area, corner radius, mark density, minimum readable size, allowed backgrounds. These are the boundaries that no new variant goes beyond.
- Visual update process: who approves, at what stage the designer joins, what is checked before the build, and in what order the result is published.
- Graphics documentation: palette with codes, allowed gradients, line weights, source resolution requirements.
- Acceptance checklist: check on light and dark desktop backgrounds, at small size in the app list and in system search.
The kit closes the main risk — visuals that live only in someone else's project. A year later, a new designer opens the documentation, checks against the rules, and releases a variant without breaking either the composition or the recognizability.
Case study: how rebuilding the iOS icon accelerated update releases
The client is a delivery service with an iOS app and two releases per month.
The icon listing in App Store was updated almost every release, and each time it ran into manual graphics preparation: the designer handed over the source, the developer laid it out by size, and discrepancies surfaced already at build time.
What it was like
The kit was assembled in a graphics editor: 40+ exports for different sizes and modes, each with its own name, some with an alpha channel, some without.
Preparation took 2-3 weeks of calendar time and ran in parallel with code, so design edits broke the already assembled release branch.
Out of ten builds, four went for rework because of visuals: transparency where it shouldn't be, mismatched corner geometry, extra fields in metadata.
What was changed
We reduced everything to one source: a high-resolution source file and a configuration from which the script generates the remaining sizes and modes.
Names and folder structure are described by a scheme; automatic validation for alpha channel, proportions, and required fields was added — it runs in the shared build and fails it before upload, not after review.
What became
Kit preparation was reduced from 2-3 weeks to 2 days, and design edits stopped blocking the release: rebuilding takes minutes.
Across 14 releases — not a single rejection due to icon visuals, the update release cycle was nearly halved, and the icon itself stopped being a separate approval between design and development.
What to do if the visuals are already published with errors?
There is no need to unpublish the app: the icon set is part of the visuals, and visuals are changed with a regular update in App Store.
Until the user installs the new build, the previous icon remains on the home screen; after the update, the system replaces it without losing installs, reviews, or search positions.
The fix goes through review together with the other metadata — there is no separate procedure for the icon.
It is important to replace the entire set, not just one conspicuous slot: the kit is assembled from one source in all required sizes, otherwise some devices will show a stretched or cropped image.
The correction plan is built from the audit: we compare the published set with the source, check edges, transparency, and corner radii, assemble the full kit, run it on a test build, and ship it in the nearest release. After rollout, we check how the icon displays on different screens and in search.
The risks of unpublishing are higher than they seem: removing from sale resets accumulated rating and reviews, loses positions for queries, and installed copies stop updating.
Returning the app to its previous positions is harder than fixing the visuals, so unpublishing is justified only if review explicitly requires it.
We start with an audit of the current visuals, assemble a correct set, and plan its release together with a regular update — users see only the corrected icon. Describe the situation, and we'll come back with a correction plan and timelines.
Technical questions asked before kickoff
Before kickoff, the same technical topics come up: whether the existing logo is enough, how the mark will behave on different devices, and what can really be changed without releasing a new build. Below are short answers to them.
We only have a logo in a raster file — will that be enough?
It is enough as a basis, but not as a source: on dense screens, a stretched raster gives blurry edges. You need a vector or a mark in curves — from the master file we generate the entire size grid through the asset catalog, without manual touch-ups.
How will the mark look on different devices and in dark theme?
We check across the entire size grid, in light and dark theme, and in the tinted home screen mode. For the dark theme we prepare separate layers: without them, the system recolors the icon itself and the mark loses contrast. The system applies the corner radius itself — we don't build it into the mockup.
Can the icon be updated without releasing a new version?
The icon lives inside the build, so replacing it means a new build and re-review in the store. Without a release, only an alternative variant can be switched — if it was built in advance and is invoked from the app settings.
What do you need from us as input?
A vector mockup or a mark in curves, the palette, margin rules, and the minimum allowed logo size. If there is no mockup, we'll assemble the master file ourselves and show control renders before the file goes into the build.
Let's discuss the task: we'll come back with an estimate and work plan
The icon is the first thing a user sees in the catalog, and one of the points where publishing most often stumbles.
Describe the current situation: which platform you're preparing the release for, whether there is a design guide and source mockups, what state the icon set is in now, whether dark theme and alternative variants are needed. This is enough for us to come back with an estimate and work plan, not general words.
- Scope of work — from auditing the current set to final upload, broken down by stages and with points where your approval is needed.
- Mockup requirements: sizes, grid, margins, corner radii, source formats — as a list that designers apply without corresponding with us.
- A ready icon set for all required sizes and modes, including dark theme and variants for different system surfaces.
- A work plan with stage timelines and a clear interaction scheme: who approves, who hands over sources, and in what form.
- A list of checks before submission for moderation — so the icon passes on the first try instead of coming back with a note about transparency or rounded corners.
- Instructions for updating the icon in future releases: how to change the set without breaking already published versions.
- Support during publishing: if comments come back, we analyze the cause and fix it.
To discuss the task, write what you already have and what you need to get. We'll come back with a work estimate, scope, and plan — without general promises.