App Icon Sizes and Design for iOS, Android and PWAs

An app icon is a compact brand asset, not a miniature poster. It must remain recognisable among competing shapes, work without a readable product name and survive platform-controlled cropping. The strongest approach starts with one visual idea and adapts its construction for each destination rather than exporting the same square everywhere.

Establish the small-scale brand idea

Choose the feature users should recognise first: a silhouette, a letterform or a distinctive internal shape. Remove taglines and supporting text. A detailed corporate lockup rarely survives launcher size, and a symbol that depends on tiny decorative strokes will lose identity before it loses technical resolution.

Use the favicon generator for the web-facing favicon portion of the package and its related tags. Treat those outputs as one part of the delivery, not a substitute for native platform assets or PWA manifest review. Check each destination's requirements separately.

Build an icon recognition sheet showing the symbol at approximately 24, 32, 48 and 64 pixels. Those are useful review sizes, not a universal export specification. View the sheet at actual size on an ordinary display. Compare the icon beside both quiet and colourful competitors, then check whether its shape remains memorable without its brand colour.

Keep one editable master with separate platform variants. Label which decisions belong to the identity and which belong to the operating system. The symbol's proportions may be stable while background treatment, padding and masking behaviour change.

Prepare an iOS-specific composition

For iOS, use the current asset workflow and templates rather than drawing your own permanent rounded-square boundary into a generic file. The system controls the final presentation. Baking a rounded mask into an image can create double-rounded edges or unwanted corners in contexts that expect a full square source.

Consult Apple's app-icon guidance before delivery. Platform capabilities and submission workflows evolve, including appearance variants, so confirm the target OS and current tooling with the engineer responsible for the release. Do not assume that a familiar historical export checklist covers every current requirement.

A 1024-pixel master is a useful starting point for traditional iOS app-icon artwork, but the actual asset catalogue or current icon-authoring workflow determines what must be supplied. Follow its transparency and layering rules rather than applying assumptions from an unrelated platform.

Inspect visual weight inside the system's mask. A circular symbol and a square symbol with identical bounding boxes will not necessarily feel equally large. Adjust the artwork optically while retaining the brand's essential proportions. Leave enough breathing room that prominent corners do not appear to collide with the icon boundary.

Review against light, dark and visually busy wallpapers. When alternate appearance assets are supported and supplied, preserve recognition across them. A dark treatment should not become a different logo merely because its colours change.

Separate Android adaptive layers and monochrome art

Android adaptive icons use foreground and background layers so launchers can apply different masks and motion effects. Do not place the whole finished square into the foreground layer and expect a genuinely adaptive result. Extend the background fully and keep essential foreground content within the protected region.

The Android adaptive-icon documentation describes a 108 by 108 dp layer canvas with essential content kept within the central 66 by 66 dp safe zone. Use the official templates and previews to validate construction. Decorative elements may extend farther, but they must tolerate clipping.

Test circular, rounded-square and other launcher masks. A flourish that looks balanced in one outline may disappear under another. Watch for unintended gaps between the foreground and background during motion previews, especially if the foreground includes a large opaque panel.

Create a deliberate monochrome version for themed-icon support rather than assuming a full-colour image can be desaturated automatically. The monochrome asset communicates shape through an alpha silhouette that the system can tint. Internal detail must remain legible when the original colour differences disappear.

Coordinate adaptive, monochrome and legacy assets with the Android developer. They serve different platform needs and should be named clearly in the package. Keep screenshots of the approved launcher previews so later exports can be compared against a known result.

Supply ordinary and maskable PWA icons

A PWA declares install icons through its web app manifest. Supply dependable square raster assets, commonly including 192 and 512 pixels, and distinguish ordinary artwork from maskable artwork. The exact set should reflect the browsers and installation surfaces your team supports.

For maskable icons, fill the canvas background and keep critical content within the central safe circle. That circle has a radius of 40 percent of the image width. The surrounding area may be cropped into different shapes, so do not place essential lettering or distinctive corners there. See web.dev's maskable-icon guide for the geometry and testing approach.

A minimal manifest excerpt can make the intended separation clear:

{
"name": "Northstar Notes",
"short_name": "Northstar",
"icons": [
  {
    "src": "/icons/app-192.png",
    "sizes": "192x192",
    "type": "image/png",
    "purpose": "any"
  },
  {
    "src": "/icons/app-maskable-512.png",
    "sizes": "512x512",
    "type": "image/png",
    "purpose": "maskable"
  }
]
}

These are separate files because the compositions may differ. Include any additional sizes your supported environments need. MDN's manifest icons reference explains the members and purpose values.

Provide an Apple touch icon when needed for supported web installation flows, and test it independently from the manifest icons. Browser favicons, home-screen icons and native app-store artwork are related brand surfaces, but they are not interchangeable delivery contracts.

Review the package as a brand system

Create a delivery checklist with platform, filename, dimensions, purpose and source revision. Keep editable artwork separate from production exports, and avoid ambiguous filenames such as final-new-final. A predictable package lets an engineer replace an asset without guessing which preview the designer approved.

Check exports at their actual display sizes. Look for halos around transparent edges, blurry small details, clipped symbols and accidental colour shifts. Compare installed icons rather than relying only on artboard screenshots. The multi-device testing guide offers a useful testing mindset for this review.

For web vector source cleanup, follow SVG production practices, but rasterise to the formats required by each destination. A mathematically clean vector does not eliminate the need for optical adjustments in small raster exports.

Finally, write a short usage rule explaining which variants are approved. Do not let campaign teams add badges, seasonal decorations or unreadable slogans without review. If a temporary variant is necessary, retain the primary silhouette and define an expiry date so recognition does not drift indefinitely.

Key takeaways

• Design one recognisable symbol, then adapt its construction per platform.
• Let iOS control masking and verify current asset requirements.
• Supply Android adaptive layers and deliberate monochrome artwork.
• Separate ordinary PWA icons from maskable compositions.
• Review installed results and deliver clearly labelled production files.