App Icon Rejected by the App Store? Six Causes and Their Fixes

Symptom to cause

Why the container of the file matters more than the drawing

Both stores render your icon in the browser, on the device and inside their own listings, and they apply their own corner radius, shadow and background. If the file already carries any of those treatments, the platform ends up compositing a shaped asset into a shaped slot, which is the single most common source of a rejected submission.

That is why the acceptance rule reads as a list of file properties rather than design advice: opaque, square, unrounded, and large enough to downscale. Every item on that list is verifiable before you upload, which is cheaper than a review cycle.

Cause one: an alpha channel that survived the export

Design tools commonly export with transparency if a background layer was never flattened. A file like that opens correctly and looks fine, so the problem only appears at submission. The check that matters is whether any pixel has an alpha value below fully opaque, including a semi-transparent halo or a soft shadow drawn into the artwork.

The fix is to place the artwork on an opaque background and flatten, not to add a white rectangle behind it in the export dialog. Extending the background colour to the edges is usually cleaner than keeping a margin that was designed for a rounded shape.

Cause two: a canvas that is not square

A 1024 by 1000 file looks correct in a design canvas and fails validation, because the required ratio is 1:1. Non-square sources also produce uneven padding once the platform masks them, so the icon appears off centre even when it was centred in the original document.

Check the intrinsic pixel dimensions rather than the displayed size. A browser will happily draw a 16 pixel file at 400 pixels, which is exactly how an undersized or non-square asset reaches submission unnoticed.

Cause three: corners drawn into the artwork

Baking a rounded rectangle into the source produces a double radius after masking: yours inside the platform's. The visual result is a thin ring of background and visibly soft corners, and reviewers treat it as artwork that does not follow the specification.

Export a full-bleed square and treat the radius as a platform concern. The same reasoning applies to drop shadows, glossy bevels and outlined borders that assume a particular silhouette.

Cause four: a master that is too small

Every other size in the set is produced by downscaling from the master. If the master is below 1024 px, the store listing icon is upscaled instead, and the interpolation is visible at the largest size where the icon is displayed most prominently.

Rebuilding from a larger source is the only real fix. Sharpening a small file helps the thumbnail and makes the large size worse.

Cause five: placeholder or template artwork

Review rejects icons that still carry a template watermark, a stock illustration that appears in other apps, or an obvious placeholder. This is a content problem rather than a file problem, and it is the one cause on the list that a checker cannot detect for you.

Cause six: applying launcher rules to a listing asset

The Play listing icon is not a launcher icon. Google asks for a 512 px full square and applies its own radius and shadow, so an upload that is already rounded or already shadowed is shaped twice. Keeping the launcher exports and the listing export separate prevents that mix-up.

A pre-upload routine that takes a minute

Open the file you intend to submit and confirm four things in order: it is 1024 px square, every pixel is fully opaque, no corner radius or shadow is baked in, and the artwork is the final version rather than a template. Only the fourth requires judgement; the first three are measurements.

Once those pass, generate the rest of the set from the same master so the sizes cannot drift apart, and keep the master file so a future re-export does not start from a downscaled copy.