PWA, App Icons & the History
of Digital Identity

An in-depth journey through four decades of icon design — from Susan Kare's 32×32 bitmaps to adaptive vector layers on Android 14 — and a practical guide to shipping your own icon in every format that matters today.

~ 22 min read · Last updated: June 2026

Prologue: why an icon at all?

Look closely and an app icon is an extreme art of constraints. It has to persuade on four square millimeters of a smartphone, look alive on a 6K studio display at the same time, avoid drowning in a mosaic of thirty other apps, carry a brand, create recognition value for casual back-and-forth swiping, and forge an emotional connection in the user's mind. It's the smallest business card a product has. And although the technical requirements shift every two to three years, astonishingly little has changed about this core task since the early 1980s.

This article is both a cultural investigation and a technical guide. We start with the first pixel symbols on the Apple Macintosh, take the curious detour via the original iPhone — which was never supposed to have native apps at all — sort out today's mandatory platform requirements, and end with a concrete workflow for turning a single vector source into a fully production-ready icon bundle in under thirty seconds.

Chapter 1: 1983 — Susan Kare and the myth of the 32×32 bitmap

When the Apple Macintosh was unveiled in Cupertino in 1984, its built-in display measured just 512 × 342 pixels — monochrome, no grayscale. The only way to visually offer the user a "program" was a tiny square of 32 × 32 dots. Today those are the dimensions of a browser favicon file. Back then they were microcosms in which entire concepts had to be conveyed. Apple hired the artist Susan Kare, a trained sculptor with no classic programming background. She bought graph paper, drew pixels by hand, and coined symbols that still survive in simplified form today, forty years later: the lasso cursor, the scissors for cutting, the floppy disk for saving.

Kare formulated three design principles back then that still hold for every icon system today. First: the symbol must remain recognizable even when the viewer squints. Second: it must work in extreme simplification — even at 16×16 in a toolbar — while not looking impoverished when displayed larger. Third: metaphor beats literalness. A pair of scissors is not a photo of scissors, but a concept of "cutting something out". Those three sentences are the reason Susan Kare's work hangs in the MoMA today — and why every later icon system quotes her.

Chapter 2: the 1990s — skeuomorphism conquers the symbol

With Mac OS 8 (1997) and Windows 95/98, available color depth jumped from 1 bit to 256 colors and then to TrueColor. Designers suddenly became illustrators. The lasso cursor turned into sculpted scissors with shadow and gloss; the floppy disk became a three-dimensional pixel painting. The design language was called skeuomorphism: the digital imitation of physical objects. The idea behind it was pragmatic: anyone using the internet for the first time in 1996 needed visual anchors. A trash can that looks like a trash can is more intuitive than an abstract square.

Apple pushed the concept to its peak with the introduction of Mac OS X in 2001. Steve Jobs' famous dictum was that the buttons should look so realistic you'd "want to lick them". The design team under Cordell Ratzlaff and later Bertrand Serlet created Aqua: glassy buttons, gel-like reflections, photorealistic icons at 128×128 and later 512×512 pixels. Adobe Photoshop had an icon that looked like an eye of polished glass. iTunes had a CD with a real light reflection. App icons had suddenly become little sculptures.

Chapter 3: 2007 — the iPhone and the ironic prehistory of the PWA

It's a curious punchline of tech history that Progressive Web Apps — today's gold standard for cross-platform applications — were invented by Steve Jobs personally. On June 11, 2007, three weeks before the iPhone launch, Jobs opened the annual WWDC with a casual remark: developers should write applications for the iPhone that work like "Web 2.0 + AJAX". There was no SDK, no App Store, no marketplace. The only official recommendation was: write web apps that run in Safari, and use the mobile browser engine as an application environment.

This vision was dramatically ahead of its time — and at the same time completely impractical. The mobile Safari of 2007 had no service workers, no web storage, and no way to run apps offline or launch them from the home screen. The developer community responded with polite silence and a public revolt. Within a year Apple caved and launched the App Store on July 10, 2008, with native iOS apps in Objective-C. The web-app idea sank into irrelevance — for the time being.

But the iPhone had left behind two things that changed the industry forever: a 4×6 icon grid on the home screen — and an aesthetic tradition in which icons were rounded squares with a soft inner edge, the so-called squircle (a blend of square and circle, mathematically a superellipse). Every later mobile operating system has adopted, modified, or deliberately broken this convention — but never ignored it.

Chapter 4: 2008–2013 — the gold rush of native icons

Between the launch of the iOS App Store in 2008 and the unveiling of iOS 7 in June 2013 lay the heyday of skeuomorphic mobile icon design. The weather app on iOS had a perfectly simulated sun-and-clouds diorama. Game Center had a green felt table with playing cards and poker chips. iBooks was a wooden shelf with real grain. Apps like Convertbot or Tweetie became designer darlings because they had perfected the photorealistic play with materials.

Meanwhile, a very different tradition was growing on the Android side. With the release of Android 1.5 (Cupcake) in 2009, Google had begun building its own independent icon system. Instead of squircles, Android allowed arbitrary silhouettes — robots, light bulbs, abstract letters. App symbols had hard outer edges and were allowed to break out of the square. To iOS designers at the time it looked chaotic — and to Android fans like liberation from the squircle dictate.

With Android 5 (Lollipop, 2014), Google then introduced Material Design, formulated by Matías Duarte. The design language was flat, with clear shadows, material planes (cards, layers, elevation levels), and an entirely new icon philosophy: app symbols got a standardized shape but were allowed to play within their geometry. A magnifying glass was a magnifying glass again — but stylized, without gloss effects, without photorealism.

Chapter 5: iOS 7, the flat shock, and the Swiss School

In June 2013, at his first WWDC keynote as Chief Design Officer, Jony Ive presented iOS 7 — and buried twelve years of Aqua tradition in two hours. Shadows vanished, materials became flat color surfaces, transitions became blur effects. All the app icons had to be redrawn. The weather app was now a color gradient with a minimalist sun. Mail was a flat white envelope. The design world was split between "finally" and "Apple has lost its mind".

The conceptual background was the Swiss School of Design: the Helvetica tradition of Max Bill and Josef Müller-Brockmann, who had argued as early as the 1950s that typographic clarity must be the means to the content, not the spectacle. Ive quoted them explicitly. Six months later Microsoft followed with Metro — same principle, different coloring. Google stayed flat with Material. Three years later skeuomorphism was a niche — surviving only in nostalgia reissues and deliberately retro designs.

Chapter 6: 2015 — "Progressive Web App" finally becomes a term

It was a blog post in June 2015 that gave the movement its name. Alex Russell, then a Chrome engineer at Google, wrote a piece together with designer Frances Berriman titled "Progressive Web Apps: Escaping Tabs Without Losing Our Soul". In it, the two formulated a manifesto: web apps should be installable, work offline, receive push notifications, and feel like native applications — without having to give up the web as a platform.

The technical foundation was a stack that had been growing in browsers since 2014. Service workers (Chrome 40, January 2015) made it possible to insert a proxy between browser and network, enabling caching, offline fallbacks, and background sync. The Web App Manifest (a W3C draft since 2014) was a JSON file telling the browser how a web application should be presented as an app: name, icons, theme color, start page, display mode. The Push API arrived a year later, and the BeforeInstallPrompt event landed in Chrome in 2017.

Russell's point was a clever one: PWAs were meant to be progressive, not binary. An application should at least work in every browser — and work especially well in those that supported PWA standards. No "App Store or nothing" coercion, no platform lock-in, no installation hurdle. The crowning of the standard came in 2018, when even Apple grudgingly enabled service workers in Safari 11.1. Eight years after Jobs' original vision, the web app was finally reality — except that today hardly anyone remembers it was originally Jobs' idea.

Chapter 7: adaptive icons — Android 8 Oreo changes the rules

In August 2017 Google released Android 8 (Oreo), conceptually breaking with everything that came before. Instead of a single square PNG per density bucket, developers now got a new icon format type: the adaptive icon. The icon consists of two vector layers, a foreground and a background. The operating system then masks the composition depending on the manufacturer skin — Samsung's One UI uses a squircle, Pixel stock Android a circle, OnePlus a rounded box. The advantage: a single icon that looks platform-conformant everywhere. The disadvantage: designers have to work with a 108-dp canvas of which only a 66-dp safe zone is guaranteed to be visible. Place letters or fine lines too close to the edge and you risk having them cut off.

Apple followed suit in 2017, though in a different way. With iOS 11, the app-icon workflow was unified in the Xcode asset catalog: AppIcon.appiconset. Instead of 18 separate PNGs in arbitrary folders, you now fill a single asset container, with a Contents.json file defining every size-idiom-scale combination. Since then Apple has explicitly required the 1024×1024 icon for the App Store listing without an alpha channel — which drives many first-time developers to despair in their first weeks, because their transparent background gets rejected by App Store Connect without comment.

Chapter 8: today's requirements sheet

Anyone launching a cross-platform app in 2026 has to deal with the following mandatory sizes — sorted by how often they get forgotten:

Progressive Web App (web manifest)

The W3C standard requires at least a 192×192 and a 512×512 icon. In practice, 72, 96, 128, 144, 152, and 384 pixels are recommended on top — especially for older Android versions and Windows Edge tiles. Maskable icons (purpose: maskable) are mandatory in two sizes if your PWA should appear like a native icon in the Android launcher: they carry 10% safe-zone padding so the system can mask them however it likes.

iOS — AppIcon.appiconset

For a universal app bundle (iPhone + iPad), Apple requires exactly eighteen PNG files plus a Contents.json. The sizes range from 20×20 for the notification bar to 1024×1024 for the App Store. Four point sizes (20, 29, 40, 60 for iPhone; 20, 29, 40, 76, 83.5 for iPad) are multiplied by @2x and @3x. Forget the App Store icon or upload it with an alpha channel, and you get a rejection email with the code ITMS-90717.

Android — mipmap buckets + adaptive icons

Google separates five pixel densities: mdpi (1x = 48px), hdpi (1.5x = 72px), xhdpi (2x = 96px), xxhdpi (3x = 144px), and xxxhdpi (4x = 192px). Each bucket needs an ic_launcher.png and an ic_launcher_round.png (for devices with a round default mask style). In addition, every bucket gets an ic_launcher_foreground.png (108-dp canvas, here at 108 / 162 / 216 / 324 / 432 px) plus two XML files in mipmap-anydpi-v26/ describing the adaptive-icon composition. On top comes the Play Store listing icon at 512×512 pixels, which the Console upload demands separately once again.

Apple touch icons (web browser variant)

When a user places a website on their iOS home screen, Safari looks for <link rel="apple-touch-icon"> entries. Nine sizes belong here: 57, 60, 72, 76, 114, 120, 144, 152, 180. The 180×180 is today's current standard for modern iPhones; the others are legacy fallbacks for older devices and browsers that someone, apparently, still seems to use.

Chapter 9: design principles that endure

Despite all the technical shifts, four design principles crystallize that work in every era:

1. One single strong motif. An icon is not a poster. Letters often work better than illustrations — see Pinterest ("P"), Behance ("Bē"), Bitcoin ("₿"). If your brand has no iconic letter, you need to find a geometric reduction: a mirror (Notes), a staff line (Music), an arrow (Mail send).
2. High contrast in the center. The eye decides in a tenth of a second whether an icon "reads". That decision is made by the center, not the edge. Put the most important shape at the center, with a clear brightness separation between foreground and background.
3. Avoid text except for logos. "Word" without the blue W is unrecognizable at 48 pixels. If your branding is a word, reduce it to the first letter or a monogram. Full-text icons only work when the brand consists of nothing but text (e.g. "IKEA", "GAP").
4. Design for the smallest size. If your 32×32 icon doesn't work, your 1024×1024 doesn't either — it just looks bigger. Deliberately design from small to large, not the other way around. That was Susan Kare's lesson from 1983, and it holds more than ever today, when we render in 4K.

Chapter 10: from concept to production-ready bundle

Say you now have a draft — a vector file (SVG, Figma export) or a high-resolution PNG of at least 1024 × 1024 pixels. The next stage is the tedious part: producing dozens of exactly scaled variants from this one source file, in the right folder structure and with the correct file names. That's exactly what the JNRT Pixel generator is built for.

Three options are available, all freely combinable:

• PWA web (always included): eight standard PWA sizes, optionally two maskable variants, nine Apple touch icons, a complete manifest.json, and an HTML snippet to paste into your <head>.
• iOS (start directly with the iOS bundle): a complete Xcode AppIcon.appiconset with all 18 sizes for iPhone and iPad, an automatically generated Contents.json, and the App Store icon without an alpha channel.
• Android (start directly with the Android bundle): five density buckets with standard and round launchers, an adaptive-icon foreground in every density, XML files for mipmap-anydpi-v26, a separate background-color resource, plus the 512×512 Play Store listing icon.

If you want to generate both native bundles at once, there's also a combined variant. Inside the ZIP you'll then find three top-level folders — icons/, ios/, android/ — each with its own README for integration.

Chapter 11: prefix, suffix, and versioning

A frequently underestimated detail: file names. If you're working on several branding iterations in parallel or maintaining a multi-tenant system, defining your own prefix and suffix schemes is worth its weight in gold. The generator supports this natively. Set v2_ as the prefix and _2026 as the suffix, and all generated web icons are suddenly called v2_icon-192_2026.png — sortable, versioned, automatable.

Practical use cases: A/B testing two logo variants in parallel in the same repo (a_ vs b_); time-based versioning (_q4-2026); customer branding (acme_ vs contoso_) in white-label setups. The native iOS and Android bundles deliberately ignore the prefix/suffix, because there the file names are hard-referenced by the build system — Xcode expects Icon-1024.png, period.

Chapter 12: testing, validating, rolling out

Three tools belong in every PWA developer's tool belt:

• Chrome DevTools → Application → Manifest: shows you live how the browser parses your manifest, which icons it finds, whether the installability criteria are met, and which errors lurk in the manifest.
• Lighthouse → PWA audit: measures installability, service-worker configuration, HTTPS setup, and best-practice checks. A PWA scoring below 90 will most likely not be offered as installable by Chrome.
• Maskable.app: visualizes your maskable icon in all Android launcher masks (circle, squircle, teardrop, rounded square). Indispensable for making sure no important part of the image disappears into the safe-zone margin.

On the iOS side, a test directly in Xcode (asset catalog → Cmd+R in the simulator) and a trial upload to TestFlight are enough before you start the App Store review process. Apple rejects nothing faster than an icon with transparency or with white pixel edges visible from the outside.

Chapter 13: a look ahead

Where is this heading? Three trends are emerging for the coming years. First: animated app icons. With the Live Activity feature (iOS 16, 2022) and interactive widget updates (iOS 17, 2023), iOS has opened the door to icons that aren't static but visualize state — a weather app whose icon shows the current sky; a calorie app whose ring fills up. Second: dynamic coloring. Android 12 (Material You) introduced the concept of automatically tinting icons from the wallpaper palette chosen by the user. Material 3 is now generalizing it. Ship monochrome vector layers (android:monochrome) and you get it for free.

Third, and perhaps most interesting: PWA is catching up to native. With the Web Push standard in Safari (iOS 16.4, 2023), Window Controls Overlay, File System Access, and the ongoing discussion around Background Sync, the web platforms are getting so close to native capabilities that the question "native or PWA?" simply becomes moot for most use cases. Anyone launching in 2026 will probably start with a PWA — and only fall back to native stores when a specific feature (background geofencing, ARKit, native Apple Pay) genuinely forces it.

Epilogue: a 50-second guide

If after this extensive history you want to open the practical tool right away, here's your direct route:

Susan Kare drew the first Apple icon on graph paper in 1983 because she had no other tool. Today, forty years later, the entire chain from vector to platform-conformant bundle runs in under a minute — and entirely in the browser, without any server upload. If that isn't progress.