A transparent app icon fails at upload, and Apple never writes the rule on the page you would check.
An alpha channel in your iOS app icon stops the build while App Store Connect is processing it, which is hours before App Review sees anything. So this is not a rejection in the sense people mean when they say the word. It is a failed upload, you fix it with a re-export, and you can reuse the same build number on the next try. The confusing part is the paperwork. The page in App Store Connect Help about adding an app icon says nothing about transparency, and the Human Interface Guidelines page about app icons tells you to vary opacity inside your artwork. Every figure below was read from Apple's and Google's own pages on 21 October 2026. For how often this sort of thing happens, we keep a note on app store rejection rates.
What follows is what Apple actually requires, which of Apple's pages carry the alpha channel ban and which do not, what Google Play wants instead, and which transparent pixels are the ones that break a build. Google asks for a 32-bit PNG with alpha. Apple wants the square filled in. Both are right, for different slots.
Start hereThe short version
Fill the square for Apple. Send an alpha PNG to Google.
The iOS icon that ships inside your app has to be a square with nothing see-through behind it. Apple's own words, in the Human Interface Guidelines page on app icons, are that an imported background layer should be full-bleed and opaque. Round corners, padding and a soft drop shadow in your export all leave pixels with an alpha value, and that is what the upload check picks up.
Google Play wants the opposite file. Play Console Help lists the store listing icon as a 32-bit PNG with alpha, 512 by 512 pixels, under 1024KB. The format has an alpha channel by definition, and Google then asks you not to lean on it, because a transparent asset shows the Play interface background colour underneath. Two stores, two files, one square of artwork. Getting that straight is most of the work.
Does Apple actually forbid transparency in an app icon?
Not as a blanket rule, and the version of the rule that circulates is close enough to be useful and wrong enough to waste your evening. Apple's App icons page in the Human Interface Guidelines, read on 21 October 2026, carries a revision note dating its current guidance to 8 June 2026, when it was refined for Liquid Glass. The line about opacity is this: if you do import a background layer, make sure it is full-bleed and opaque. That is a requirement about the background, not about the file.
Two sentences later the same page tells you to vary opacity in foreground layers to increase the sense of depth, and gives the Photos icon as the example, because its centrepiece is split into layers with translucent pieces in them. The visionOS paragraph goes further and says the system uses the alpha channel of the upper layers to create an embossed appearance. Apple is not shy about transparency. It is specific about where the transparency belongs.
The other half of the page explains why a flat square is what you hand over. In iOS, iPadOS and macOS the icon is square and the system applies masking to produce rounded corners that match the curvature of the device bezel. In visionOS and watchOS the masking is circular. Apple asks you to produce unmasked layers, says the system masks all layer edges to produce the final shape, and warns that layers with masking already in them make the edges look jagged and spoil the specular highlights. Same answer on shadows: the system applies the effects, so there is no need to include drop shadows, bevelled edges, blurs or glows yourself.
The sizes on that page are worth copying down, because they are the ones people get a year behind on. As of 21 October 2026 the layout size is 1024 by 1024 pixels for iOS, iPadOS, macOS and visionOS, 1088 by 1088 pixels for watchOS, and 800 by 480 pixels for tvOS, which is the only rectangular one. Supported colour spaces are sRGB, Gray Gamma 2.2 for grayscale, and Display P3 for wide gamut on every platform except visionOS. Apple prefers vector artwork, SVG or PDF, and asks for PNG when the artwork is raster or a mesh gradient because PNG is lossless. There is one more line that catches people: avoid a black background, and lighten it so the icon does not blend into the display.
Apple, Human Interface Guidelines, App icons, read 21 October 2026
Check yours
Which slot the file is going into
Pick the slot you are exporting for. The sizes and the verdict on transparency are the ones each platform publishes for that slot, not a single rule applied to all of them.
Nothing picked. If you only ever export one file, export the iOS default icon: a flat opaque square with nothing clever at the edges.
What does App Store Connect tell you when the icon is wrong?
Less than you would expect, and Apple does not print the message anywhere in its documentation. Here is what Apple does document, on the Build upload statuses page in App Store Connect Help, read on 21 October 2026. An upload sits at Processing. When processing finishes you get an email notification and the status in the table under Build Uploads changes. Failed means the upload finished processing but hit an issue, and you select the build to see the errors, warnings and information behind it. There is a useful detail in the note under that status: if a build upload fails, you can reuse the same build number for your next upload.
Now the part that explains why nobody can find the rule. I read the App Store Connect Help page called Add an app icon on 21 October 2026. It describes where the icon shows up, points at the Human Interface Guidelines for design, tells you to use Icon Composer or an asset catalog in Xcode, and gives the required role as Account Holder, Admin, App Manager or Developer. It also notes that changing your icon after publishing means creating and uploading a new version and submitting it for review. It does not mention transparency or an alpha channel once.
The pages in App Store Connect Help that do forbid alpha channels are Screenshot specifications and Creative assets specifications. Both carry the same sentence, that images cannot include alpha channels or transparencies. Both are about screenshots and about the product page header and search result artwork. Neither is about the icon. So if you went looking for the icon rule in App Store Connect Help and came back with a screenshot rule, that is the documentation doing it to you and not you misreading it.
The numbered error identifiers people trade on forums are not in Apple's documentation either. They appear in Apple's developer forums, which are posts by other developers, so the wording to trust is the one sitting in your own account under the failed build. One thing you do not need here is a reply to a reviewer, because nobody has reviewed anything yet. Keep your app store review notes for the problems a human raises, and save appeal app store rejection for a decision you actually disagree with.
What does Google Play require instead?
A file with an alpha channel in it, as the stated format. Play Console Help, on the page about adding preview assets to showcase your app, read 21 October 2026, gives four requirements for the store listing icon: a 32-bit PNG with alpha, dimensions of 512 by 512 pixels, a maximum file size of 1024KB, and compliance with Google Play's icon design specifications. Google is also clear that this icon is a separate thing from the launcher icon inside your app. It does not replace it. It is a higher resolution version for the store.
The design specifications page prints its own last updated date, 20 October 2026, which makes it the freshest page quoted anywhere here. It asks for sRGB, a full square shape, and no shadow, and it says why in both cases: Google Play handles the masking itself, at a radius equal to 30% of the icon size, and adds the drop shadow itself after upload. It tells you not to round the edges of your final asset. It tells you not to force a logo to full bleed if the shape matters, and to place it on the keyline grid instead.
Then the line that makes Google's position on transparency clear. Pick a background colour for your asset that suits your brand and does not include any transparency, because transparent assets will display the background colour of the Google Play interface. So the format accepts alpha, nothing fails on upload because of it, and the result is an icon that changes appearance depending on what Google paints behind it. That is a worse outcome than a build failure, because nobody tells you about it.
The launcher icon on the phone is a third file again, and here empty space is the whole design. Google's adaptive icons page, last updated 22 September 2026, asks for two layers for the colour version, foreground and background, each sized 108 by 108 dp, plus an optional monochrome layer if you want your icon themed from the user's wallpaper. The logo should be at least 48 by 48 dp and no more than 66 by 66 dp, because the inner 66 dp is the part that survives every manufacturer's mask, and the outer 18 dp on each side is reserved for masking and for effects such as parallax. The layers must not carry masks or background shadows around the outline. Themed icons arrived in Android 13, and from Android 16 QPR 2 the system themes icons for apps that supply no monochrome layer of their own.
Google Play icon design specifications, page last updated 20 October 2026, read 21 October 2026
Which transparent pixels are the ones that break a build?
Rounded corners, almost every time. A designer hands over an icon that already looks like an app icon, with the corners curved the way they appear on a phone. Outside that curve are four small wedges of nothing, and nothing is an alpha value. The icon looks perfect in every preview, passes every eyeball check, and fails the upload. Apple's instruction covers this without naming it: produce unmasked square layers and let the system apply the corners.
Second most common is padding. Artwork that does not fill the square leaves a clear border, which is both an alpha channel and a visibly shrunken icon next to everyone else's. Third is a soft drop shadow baked into the export, which fades to transparent at its edge. Fourth is an export preset: plenty of tools write a 32-bit PNG with a fully opaque alpha channel by default, so the image has no visible transparency at all and still carries the channel. If the file information in Finder reports an alpha channel, the channel is there whatever your eyes say.
The fix is a flatten, not a redesign. Place the artwork on an opaque background layer the size of the full square, leave the corners square, remove any shadow you added, and re-export without alpha. If you build icons in Icon Composer instead, Apple's guidance is to import fully opaque layers and set the transparency inside the tool, so you can see how your translucency and the system effects interact before you ship. Keep your primary content centred as well, because the system crops and masks the edges.
One exception, and it is the reason the blanket rule confuses people. Apple's Xcode documentation on configuring your app icon using an asset catalog, read 21 October 2026, tells you to provide your dark app icon with a transparent background so the system-provided background can show through, and to provide your tinted icon as a grayscale image. The clear background is required in that one image well and fatal in the main one. Like the location permission always rejection, it is a rule with a second half, and the second half is where the time goes.
One square of artwork, judged three different ways
| The question | iOS app icon | Play store listing icon | Android launcher icon |
|---|---|---|---|
| Size the documentation states | 1024 x 1024 px | 512 x 512 px | 108 x 108 dp per layer |
| Format the documentation states | Vector preferred, PNG for raster | 32-bit PNG, sRGB | Vector preferred, bitmap allowed |
| Transparent background allowed | No on the default icon, yes on the dark one | Allowed, and advised against | Yes |
| Round the corners yourself | No | No | No |
| Add the drop shadow yourself | No | No | No |
| Where a bad file is caught | Processing the upload in App Store Connect | Listed as a mandatory store listing requirement | Not at upload, it shows up on the device |
Where this lands if a builder generated your app
Nothing about the icon changes because an AI wrote the code. The file still has to be a flat square, and you are still the one pressing upload. In a React Native and Expo project the icon is a config field rather than a set of image wells. Expo's own documentation on splash screens and app icons, last modified 26 June 2026, asks for a PNG at 1024 by 1024, says the image must be exactly square, and spells out the trap in one sentence: make sure the icon fills the whole square, with no rounded corners or other transparent pixels, because the operating system masks it when appropriate. EAS Build generates the smaller sizes from that one file.
The Android side of that config is the one to look at twice. Expo exposes the adaptive icon as a foreground image, an optional monochrome image, and either a background colour or a background image of matching dimensions. The default background colour is white, so an app that never sets it ships a white tile. Since SDK 54, the iOS field also accepts an Icon Composer directory, which takes the dark and tinted appearances off your plate.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own, with two way GitHub sync, at $25 a month and no free tier. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and builds a standalone Android APK. It does not submit to the App Store for you, because Apple requires the owner of the content to submit. That matters here in a small, practical way: the upload that validates your icon is an upload you can run as often as you like, so an icon problem is a loop you own rather than a queue you wait in.
Questions people ask about app icon transparency
Not in those words, and the difference matters. Apple's Human Interface Guidelines page on app icons, read 21 October 2026, tells you that if you import a background layer you should make it full-bleed and opaque. The same page tells you to vary opacity in foreground layers to increase the sense of depth, and for visionOS it says the system uses the alpha channel of the upper layers to create an embossed appearance. So transparency inside the artwork is expected. What is not wanted is a see-through background on the default icon, and what fails at upload is an App Store icon that carries an alpha channel.
Export the square, then upload it
Flatten the icon onto an opaque background, keep the corners square, and let each system apply its own mask. The upload check then stops being the thing that holds up your release.
Start building