React Native App Icon Size: Complete 2026 Guide
Master React Native app icon size requirements for iOS and Android. Includes adaptive icon specs, mipmap densities, app.json config, and store submission tips.
You've probably had the same moment most React Native teams hit eventually. The build looks fine locally, the icon looks sharp in Figma, and then a store submission comes back with a complaint about the icon, or worse, the app shows up clipped, blurry, or inconsistent across devices. That problem usually isn't one icon file, it's a broken react native app icon size pipeline.
The fix is simpler than the pain makes it feel. Start with one 1024×1024 master asset, let the platform tools generate the variants they're designed to generate, and treat iOS and Android as two different packaging systems that happen to share the same source artwork. Expo explicitly says 1024x1024 is a good size for the master app icon, and EAS Build can generate the other sizes automatically for new Expo projects, with the largest generated size also being 1024×1024 (Expo app icon docs). On Android, the store-facing submission asset is usually 512×512 px in 32-bit PNG, with a maximum file size of 1024 KB (Android app icon guidance).
The practical goal is to stop thinking about “the icon” as one image. It's a bundle, a master file, a set of generated outputs, and a few platform rules that punish artwork sitting too close to the edge. If that mental model is right, the rest of the workflow gets a lot less chaotic.
Table of Contents
- Why App Icon Size Trips Up Most React Native Teams
- The 1024x1024 Master Asset and Why Every Pipeline Starts Here
- iOS Icon Outputs, Asset Catalog Slots, and HIG Rules
- Android Mipmap Densities and the 512x512 Play Store Asset
- Android Adaptive Icons and the 18 dp Safe Zone
- Configuring Icons in app.json and the Android Manifest
- Manual Generation vs Automated Asset Tools
- Compression, File Size, and Pre-Submission Verification
Why App Icon Size Trips Up Most React Native Teams
The first failure usually shows up in the most boring place possible, the store checklist. A developer exports one PNG, drops it into the project, and assumes both stores will handle the rest. That breaks as soon as Apple wants an asset catalog entry, Google Play wants a square listing image, and Android launchers want density-specific icons that do not all come from the same file in the same way.
One icon is really a family of assets
React Native makes it easy to assume one image can cover every surface, because the app code itself is cross-platform. The packaging is not. iOS icons move through the asset catalog, Android icons get split across launcher densities, and the store listing uses its own submission image. Expo reduces the manual work if the source asset is correct, but it cannot rescue artwork that was drawn too tightly or exported in the wrong shape.
Practical rule: treat the icon as a release artifact, not a design afterthought. If the master file is wrong, every derived size inherits the mistake.
That is why a lot of teams end up doing icon work twice. They fix the obvious store rejection, then discover launcher cropping, then discover the small iOS slot that looks fine at full size but fails when compressed into a tiny surface. The cost is not just time, it is release friction. Every review cycle becomes a chance to re-learn the same lesson.
Why the pipeline mindset saves releases
Teams that ship cleanly usually standardize the icon pipeline early. One design file becomes the master, the build system fans it out, and reviewers get the formats they expect. That is a much better model than designing six sizes by hand and hoping they stay consistent.
A strong react native app icon size workflow also makes collaboration easier. Designers know where the safe center lives, engineers know which file the build reads, and release managers can verify the outputs without opening a graphics editor. That sounds small until a production launch depends on one icon pass not being the thing that delays the app.
The 1024x1024 Master Asset and Why Every Pipeline Starts Here
A launch can go sideways fast when the icon master is drawn for one surface instead of the whole pipeline. A logo that hugs the corner may look sharp in Figma, then get masked into invisibility at 20 px once the platform trims it. Expo's app icon flow starts with a 1024×1024 master because that square gives the build system enough detail to generate the smaller outputs cleanly (Expo app icon docs).
Build the source file for downstream generation
The master file has to survive masking, scaling, and store rendering, so the source artwork should be prepared for that work from the start. Apple's Human Interface Guidelines expect the icon artwork to sit inside the shape rules the system applies later, which is why a square, unmasked source is the right starting point (Expo app icon docs). If you bake in rounded corners or crop the art too tightly, the generated outputs inherit that decision everywhere.
A solid master file usually respects a few practical rules:
- Square canvas first: keep the art on a 1:1 ratio so both platforms can derive their own outputs.
- Centered content: primary shapes should stay centered so platform masking does not clip important details.
- No accidental transparency at the edges: the visible artwork should read cleanly when the system trims or masks around it.
- High-contrast shapes: the icon has to stay recognizable from store listing size down to a tiny launcher tile.
A logo pushed into the corner is the classic failure case. It can pass a quick desktop check, then vanish once the system masks the edges and the remaining visible area shrinks. That is why the master asset is not just a source image, it is the control point for the whole icon pipeline.
Why automation beats hand-sizing every variant
Expo-managed projects do not need a separate design pass for every iOS and Android size. The build pipeline is meant to derive those variants from the master source, and that is the part teams should protect. One clean file carries the brand, the legibility, and the safe margins into every generated output.
That also makes review faster. You can inspect one PNG, verify that the subject sits well inside the safe area, and trust the generated sizes to stay consistent if the original is correct. When the master is sloppy, every output repeats the same composition problem in a different scale.
iOS Icon Outputs, Asset Catalog Slots, and HIG Rules
On iOS, app icon sizing is not a single file problem. It is a chain of asset catalog slots that feed different system surfaces, from notifications and settings to the app icon itself and the App Store listing. Expo's documented iOS sizes include 20, 29, 40, 58, 60, 76, 80, 87, 120, 152, 167, 180, and 1024 px, and the build tooling derives the smaller outputs from the master asset when the source file is clean (Expo app icon docs). The exact slot list matters less than the pipeline. iOS still expects the right asset in the right place, and a good source image keeps the generated bundle predictable.
What the sizes are for
The smaller icon slots map to specific system uses, including notifications, settings, Spotlight, and the app itself. The larger values support higher-resolution displays and marketing surfaces. In Expo-managed projects, you usually do not hand-craft each file, but you still need to know what each slot represents so you can catch a bad crop or a weak composition before it reaches review.
| Size (px) | Scale factor | Use Case |
|---|---|---|
| 20 | 1x, 2x, 3x depending on slot | Small system surfaces such as notifications and compact UI |
| 29 | 1x, 2x, 3x depending on slot | Settings and similar system contexts |
| 40 | 1x, 2x, 3x depending on slot | Older iOS icon surfaces |
| 58 | 2x, 3x depending on slot | Larger small-slot system UI variants |
| 60 | 2x, 3x depending on slot | Standard app icon slot |
| 76 | 1x, 2x depending on slot | iPad-specific placement |
| 80 | 2x depending on slot | Higher-resolution device asset use |
| 87 | 3x depending on slot | High-density device-specific icon variant |
| 120 | 2x, 3x depending on slot | Retina app use |
| 152 | 2x depending on slot | iPad Retina bundle use |
| 167 | 2x depending on slot | iPad Pro surface |
| 180 | 3x depending on slot | Prominent app icon usage |
| 1024 | Master and store asset | Source file and App Store imagery |
If you are wiring this through Expo or EAS, the practical rule is simpler than the table. Keep one strong 1024×1024 master, and let the pipeline derive the rest instead of trying to maintain separate art for every slot by hand.
Where Apple's masking rules bite
Apple's HIG is strict about content near the edge. The source icon is treated as a square asset, then the system applies masking where needed. Rounded artwork baked into the file can make the result worse, because you lose control over how the shape survives across different contexts.
Keep important text, symbols, and edges comfortably inside the center of the square. If the icon depends on a thin border or a letterform that reaches the corners, the mask can make it look clipped even when the PNG looked fine in a design tool preview.
Keep the master square, keep the center clean, and assume the system will be less forgiving than your design tool preview.
The practical takeaway is straightforward. For iOS, the master file should stay an unmasked source, not a finished rounded badge. That keeps the asset catalog predictable and lowers the chance of a reviewer seeing a crop that never showed up in local testing.
Android Mipmap Densities and the 512x512 Play Store Asset
Android splits icon delivery across two different jobs. The Play Store listing asset follows Google Play's own submission requirements, which call for a 512×512 px icon in 32-bit PNG format with a maximum file size of 1024 KB. The launcher icon family is separate. It is generated into density buckets so Android can choose the right size for each device.
The launcher icons are not the store asset
The density buckets that matter are mdpi, hdpi, xhdpi, xxhdpi, and xxxhdpi. In React Native projects, those usually map to the android/app/src/main/res/mipmap-* folders. The goal is not five different visuals. One clean base image should scale into multiple launcher assets without losing shape, edge quality, or contrast.
The store asset and launcher icons serve different jobs:
- Play Store asset: one canonical listing image, square, compact, and formatted for Google Play submission rules.
- Launcher icons: multiple density-specific files generated for the device that installs the app.
- Base image: the source that everything else should come from.
Why density buckets matter in practice
Android hardware varies widely, so the system expects launcher icons at several resolutions instead of one universal file. That multi-density approach is why a React Native team cannot just copy the same PNG into every folder and move on. It may pass on one device and look rough on another.
The Play Store listing asset deserves its own check. The file size cap matters because oversized artwork can be rejected or compressed in ways that reduce clarity. Simple shapes and strong contrast help here, not because they are trendy, but because they hold up better when the image is reduced than ornate art or thin detail.
Android Adaptive Icons and the 18 dp Safe Zone
Adaptive icons are where a lot of Android confusion starts. The source art fills a square canvas, but launchers can mask the visible shape in different ways, so the outer content isn't equally safe on every device. Expo's guidance says the icon should fill the square with no rounded corners or other transparent pixels, while the foreground and background are configured separately for adaptive icons. Community guidance also calls out the outer 18 dp on each side as the area that can be clipped or masked (Stack Overflow discussion on Android icon cut-off issues).
Full bleed, but not edge-hugging
That sounds contradictory until you separate the file from the visual composition. The file itself needs to be full-bleed and square. The artwork inside that file still needs breathing room so the important parts survive launcher masks.
The practical takeaway is to keep the visible logo, wordmark, or symbol inside the center safe area. If the art sits too close to the edge, some launchers will crop it harder than others. That's why an icon can look fine in one preview and feel cut off on another device.
How Expo maps the layers
Expo expects adaptive icon configuration to split into a foreground image and a background color or image in app.json. That keeps the layers flexible, because the launcher can render them independently. The foreground carries the mark, the background provides the field behind it, and the system handles the final shape.
Practical rule: if the logo needs to read cleanly inside a circle, squircle, or other launcher mask, design for the center first and treat the outer margin as disposable.
A lot of teams save themselves trouble by reviewing the icon at several apparent crop shapes before shipping. The source file may still be a square, but the visible artwork has to survive more than one mask. That's the difference between an icon that merely exists and one that looks intentional on Android.
Configuring Icons in app.json and the Android Manifest
Expo-managed projects usually wire the icon through configuration, not hand-edited native files. The key values are the global icon, the Android-specific android.icon, and the adaptive icon settings under android.adaptiveIcon.foregroundImage and android.adaptiveIcon.backgroundColor. EAS Build then translates that configuration into the iOS asset catalog and the Android manifest references during the build.
The Expo config that drives the bundle
A typical setup looks like this in principle:
iconfor the main app icon source.android.iconfor the legacy Android launcher icon path.android.adaptiveIcon.foregroundImagefor the adaptive foreground layer.android.adaptiveIcon.backgroundColorfor the background field behind the foreground.
In managed workflows, those settings are enough for EAS Build to generate the platform assets. In bare React Native, the process is more manual, because you're editing Assets.xcassets on iOS and the res/mipmap-* folders on Android yourself.
What EAS Build does for you
The useful part of EAS Build is that it copies the right source image into the right place during the build, so you're not babysitting density folders by hand. That doesn't eliminate responsibility, it just moves the responsibility to the config file where it belongs.
If you want a service to handle the release packaging side of that workflow, LetsDeployIt is one option that prepares store assets and submission materials for React Native and Expo apps. The key point, though, is still the same, the build pipeline only works well when the icon config is already correct.
A clean configuration file is also easier to review than a pile of generated images. When something goes wrong, you check the source keys first, not twenty output files. That keeps icon problems from spreading into unrelated release tasks.
Manual Generation vs Automated Asset Tools
Hand-building icons in Figma or Sketch still has a place, but it's not the default answer for a mature React Native team. Manual work is useful when the icon needs brand-specific adaptive foreground art or a very particular visual treatment. Automation is better when the goal is to resize one correct master into every platform variant without introducing accidental drift.
Where manual design still wins
A designer can make better judgment calls on edge cases than a resizing script can. If the logo uses custom line art, layered shapes, or a background that has to align exactly with the foreground, the manual pass often catches problems earlier. That matters most for adaptive icons, because the visible foreground and the background field are distinct pieces of the final result.
Where automation saves real time
For repeatable release work, automation is faster and more reliable. Tools like sharp, ImageMagick, and community packages such as expo-icon-generator can take a single master and generate the required outputs during CI or a release script. That means fewer hand-export mistakes and less chance that a rushed release leaves one density folder stale.
A practical example is a sharp-based pipeline that downscales the master into iOS slots and Android densities in one pass. The exact implementation can vary, but the principle stays the same, one source file in, multiple platform assets out, with transparency preserved where Android needs it and flattened where the store image should stay opaque.
The right choice usually isn't either-or:
- Manual for brand-critical composition when the icon's visual balance is still being tuned.
- Automated for release consistency when the master is approved and only the derivatives need generation.
- Hybrid for real teams when design owns the source and engineering owns the repeatable output.
The strongest workflow I've seen uses both. Designers approve the master, engineers automate the derivatives, and nobody wastes time exporting the same sizes by hand every release.
Compression, File Size, and Pre-Submission Verification
Icon failures usually come from file hygiene, not design. A PNG can look fine in Figma or Sketch and still carry metadata you do not need, compress poorly, or shift after export. On Android, the store asset still has to stay within the 1024 KB limit mentioned earlier, so the final check belongs in your release workflow, not after a failed submission.
Compress first, then inspect the result
Use PNG optimization tools such as pngquant, optipng, or sharp’s built-in compression path to strip unnecessary metadata and reduce bloat. The goal is not to squeeze every file aggressively. The goal is to keep the icon visually identical while removing bytes that add no value to a store listing or device bundle.
A practical verification pass should include both image inspection and file inspection. Open the generated assets in a viewer, then confirm the file matches the format you expect. On macOS, file icon.png should report a 32-bit PNG, and stat -f%z icon.png should show a size under the store limit. On Linux, file icon.png and stat -c%s icon.png cover the same ground.
If you are using a shell step in CI, those checks are easy to automate. Run the compression job first, then fail the build if the output is not a PNG, if alpha gets stripped where it should stay intact, or if the store asset exceeds the size cap. That catches the kind of mistake that slips through visual review, especially when the icon still looks fine at a glance.
What to check before you press submit
Look closely at the center composition, edge spacing, and contrast. Thin strokes, tiny text, and pale marks on light backgrounds are the first things to degrade when an export step or optimizer makes a bad decision. If the icon depends on those details, verify it at the sizes users and store reviewers see, not only at full resolution.
Review the generated outputs, not just the source file. A clean master does not guarantee a clean launch if the export step introduces a bad crop, a broken alpha channel, or a file that is technically valid but no longer reads well at launch size. Once the icon looks right in preview and the file size is compliant, you have removed one of the most avoidable causes of store friction.