App store submissions typically require your app icon at a specific list of pixel sizes — different sizes for different device types, different display densities, and store listing thumbnails, often a dozen or more distinct sizes for a single icon design. Generating each one accurately, rather than guessing or resizing down repeatedly from an already-resized copy, keeps every size sharp.
Starting from the right source
If your icon design exists as an SVG or another genuine vector file, that is the ideal starting point, since it can be exported at any pixel size with no loss of sharpness. If you only have a raster file (a PNG or JPG), use the largest, highest-resolution version available as your source for every export, rather than a smaller version that has already been resized down once.
Steps from an SVG source
- Check the exact list of pixel sizes your target app store requires (these are published in each platform's developer documentation and do change over time, so check current requirements rather than an old saved list).
- Export each required size individually and directly from the SVG using SVG to PNG, rather than resizing one large export down repeatedly.
- Name each exported file clearly, ideally including the pixel size in the filename, so you can match each one to its required slot during submission.
Why exporting each size directly, rather than downscaling repeatedly, matters
Resizing a PNG down from one size to a smaller one and then down again to an even smaller size compounds a small amount of softening at each step, and the smallest sizes in the sequence end up noticeably less crisp than if they had been exported directly from the vector source at their actual target size. Exporting each required size independently from the original SVG avoids this entirely, since every export is equally sharp regardless of size.
If you only have a raster source, not a vector one
Working from a large raster source, resize down to each required size individually from that same large original, rather than resizing the largest export down to the next size and so on in sequence. This single-step-down approach from one consistent source, even without a true vector file, still gives a noticeably cleaner result than repeated sequential downscaling.
Checking the smallest required sizes carefully
The smallest icon sizes in a typical requirement list — often used for notification badges or small UI elements — are the most likely to reveal a design that does not simplify well at tiny sizes. A detailed icon with fine internal elements can become an illegible blob at the smallest required size, even when correctly exported. If this happens, it may be worth designing a simplified version of the icon specifically for the smallest sizes, rather than relying on the same detailed design scaled all the way down.
Keeping backgrounds and transparency correct per platform
Different app stores and platforms have different rules about whether an icon should have a transparent background or must be a fully opaque square — some platforms apply their own rounded-corner or shape mask automatically and expect a full square image underneath, while a transparent background in the wrong context can display incorrectly. Check your specific target platform's icon guidelines for this detail rather than assuming your existing format is correct for every store.
Organising the finished set of exports
Once every required size is generated, keep them organised in a dedicated folder, clearly named by their exact pixel dimensions, separate from your general image library. App store submission processes often require uploading specific sizes to specific fields, and a well-organised, clearly labelled set makes this considerably faster and less error-prone than hunting through a mixed folder of differently sized exports.
Preparing for a future update, not just the first submission
An app icon is rarely a one-time export — future updates, a rebrand, or a new platform your app expands to will all need the same set of sizes regenerated again. Keeping your original SVG or high-resolution source file safely archived, alongside notes on exactly which sizes and settings you used, saves you from having to rediscover the full requirement list and regenerate everything from a lower-quality source the next time an update is needed.
Frequently asked questions
Do all app stores require the same set of icon sizes?
No, different platforms have their own specific lists; always check your target platform's current developer documentation rather than assuming one list applies everywhere.
Is it worth designing a simplified icon just for the smallest sizes?
If your detailed design does not hold up at the smallest required size, yes — a simplified version designed specifically for tiny display is usually a better outcome than a shrunk, illegible version of the detailed design.
Can I use the same icon export across different app stores?
Only if the specific size and format requirements happen to match; check each platform's list independently rather than assuming.
Does PNG or JPG matter for app icon submissions?
Most app stores specifically expect PNG for icon submissions; check your target platform's requirements to confirm.
What if my icon design is not currently a vector file?
Work from the largest, highest-resolution raster version you have, resizing down to each required size individually from that same source.
Should the icon include padding, or fill the entire square?
This varies by platform guideline; some expect the design to fill most of the square, others expect some safe margin for automatic shape masking. Check your specific platform's icon design guidelines.
Is the tool free and private?
Yes. No sign-up, no watermark, and files are removed from the server automatically about an hour after processing.