1984: Susan Kares Icons und die Resource-Forks

Die Vorgeschichte von ICNS beginnt mit den allerersten Icons der Computer-Geschichte. Als der originale Macintosh 1984 erschien, hatte Apple-Designerin Susan Kare die Programm-Icons gezeichnet — Pixel für Pixel, in einem 32×32-Raster, mit nur 1 Bit pro Pixel (Schwarz oder Weiß). Die Icons lagen nicht in eigenen Dateien, sondern in den Resource-Forks der Programm-Dateien.

Das klassische Mac OS hatte ein eigenwilliges Datei-System: jede Datei bestand aus einer Data Fork (die eigentlichen Inhalte) und einer Resource Fork(strukturierte Sub-Datenblöcke). Icons waren Ressourcen vom Typ ICN#(32×32-pixel-monochrome Bilder mit Masken). Diese Resource-basierte Architektur war elegant für ein Single-Vendor-Betriebssystem, aber problematisch für Cross-Plattform- Datei-Transfers — Resource-Forks gingen verloren, sobald eine Mac-Datei auf einer Windows-Diskette landete.

1991: System 7 bringt Farbe

Mit Mac System 7 (1991) bekamen Icons erstmals Farbe. Apple definierte neue Resource-Typen für Farb-Varianten: ics8 (16×16 in 8-Bit-Farbe), icl8 (32×32 in 8-Bit-Farbe), ics4 und icl4(entsprechende 4-Bit-Varianten). Eine vollständige Icon-Resource bestand aus mehreren dieser Sub-Ressourcen — die monochromen Originale für 1-Bit-Displays plus die farbigen Varianten für 8-Bit- und höhere Display-Modi.

Diese Multi-Resolution-Architektur war konzeptionell ähnlich wie das parallel entwickelte ICO unter Windows (siehe unsere ICO-Geschichte) — beide Systeme erkannten, dass Icons in verschiedenen Größen und Tiefen gebraucht werden und bündelten alles in einem Container. Apple's Lösung war jedoch über Resource-Forks an die Programm- Datei gebunden, nicht als eigenständige Datei.

2001: Mac OS X 10.0 erfindet ICNS neu

Der große Bruch kam mit Mac OS X 10.0 (März 2001). Das neue Betriebssystem brach mit der Resource-Fork-Tradition und führte ein modernes Datei-Konzept ein. Icons wurden zu eigenständigen .icns-Dateien, die als separate Datei oder als Bestandteil eines Application-Bundles gespeichert werden konnten.

Die ICNS-Struktur ist überraschend simpel: ein 8-Byte-Header (Magic „icns" plus Gesamt-Größe), gefolgt von einer Sequenz von Icon-Elementen. Jedes Element hat einen 4-Byte-Type-Tag und eine 4-Byte-Längen-Angabe; die folgenden Bytes enthalten die eigentlichen Bilddaten. Type-Tags identifizieren Größe und Tiefe: il32 (32×32 in 24-Bit), ih32 (48×48), it32(128×128), und so weiter.

Die Architektur wächst mit den Display-Generationen

Über die Jahre erweiterte Apple ICNS um neue Größen, jeweils passend zu den neuen Display-Generationen:

  • Mac OS X 10.0 (2001) — 128×128 als größte Größe, ausreichend für CRT-Displays mit 75 dpi.
  • Mac OS X 10.5 Leopard (2007) — 256×256 und 512×512. Apples Stack of Coverflow-Album-Cover und das aufkommende Spotlight-Suchergebnis brauchten höhere Auflösungen.
  • Mac OS X 10.7 Lion (2011) — 1024×1024 für Retina-Displays vorbereitet, ein Jahr bevor die ersten Retina-MacBook-Pros erschienen.
  • OS X 10.8 Mountain Lion (2012) — @2x-Varianten für jede Größe (also 16×16 plus 16×16@2x = 32×32 als High-DPI-Version). Damit konnten Apps ihre Icons in doppelter Pixel-Dichte mitliefern, ohne die nominalen Größen anpassen zu müssen.

Komprimierung: PNG und JPEG 2000

Apples älteste ICNS-Dateien speicherten Pixel-Daten als rohe Bitmaps mit optionaler RLE-Komprimierung. Mit dem Sprung zu höheren Auflösungen wäre das absurd ineffizient geworden — ein 1024×1024-Icon in 32-Bit unkomprimiert ist 4 MB. Apple integrierte deshalb zwei moderne Komprimierungs-Formate: PNG (für Icons mit klaren Kanten, siehe unsere PNG-Geschichte) und JPEG 2000 (für photografisch wirkende Icon-Stile, siehe unsere JPEG-2000-Geschichte).

Ein modernes ICNS enthält damit typischerweise nicht mehr rohe Bitmaps, sondern PNG-Datenströme als Sub-Elemente. Das macht die Datei deutlich kleiner und nutzt die bekannten Komprimierungs-Algorithmen ohne dass Apple eigene Implementierungen pflegen muss.

Tools und Workflows

Im klassischen Mac-Workflow nutzten Entwickler Icon Composer, ein mit Xcode mitgeliefertes Apple-Tool, das ICNS-Dateien aus mehreren PNG-Quellen zusammenstellte. Apple stellte Icon Composer mit Xcode 4.4 (2012) ein und ersetzte es durch das Asset-Catalog-System: Entwickler fügen PNG-Varianten in einen.appiconset-Ordner ein, und Xcode generiert daraus automatisch die ICNS-Datei beim Build.

Für nicht-Xcode-Workflows gibt es Drittsoftware: iconutil(Apples Kommandozeilen-Tool, mit macOS mitgeliefert), png2icns(Open-Source, plattform-übergreifend), Online-Konverter. Unser Icon Studio ist auf Favicon und PWA-Icons spezialisiert, deckt aber die ICNS-Größen-Anforderungen nicht direkt ab — für native macOS-App-Icons ist Apples Asset-Catalog-Pipeline die robusteste Wahl.

Wann ICNS gebraucht wird

ICNS hat einen einzigen ernsten Anwendungsfall: native macOS-Anwendungen. Wer eine Mac-App schreibt — egal ob in Swift, Objective-C, mit Electron, mit Tauri, mit PyQt — muss eine ICNS-Datei als Icon-Asset mitliefern. Ohne ICNS zeigt macOS ein generisches Default-Icon, was professionell schwer zu rechtfertigen ist.

Für iOS-Apps ist ICNS dagegen nicht das Format. iOS verlangt PNG-Varianten in spezifischen Größen, eingebunden über das Asset-Catalog-System. Die Verwirrung zwischen ICNS (macOS) und den ICO-/PNG-Workflows der anderen Plattformen ist eine häufige Stolperfalle für Cross-Plattform-Entwickler.

ICNS und das Web

ICNS hat keine Web-Anwendung. Browser können ICNS nicht anzeigen, kein Web-Framework akzeptiert ICNS als Asset-Format. Wer ein macOS-App-Icon zusätzlich auf einer Website darstellen will, exportiert PNG-Varianten aus den ICNS-Quell-PNGs.

Eine pragmatische Pipeline für Cross-Plattform-Apps: PNG-Master-Datei in 1024×1024 erstellen → daraus pro Plattform die nötigen Größen ableiten (ICNS für macOS, ICO für Windows-Favicon, PNG-Varianten für iOS, Android und Web). Eine genauere Übersicht der modernen App-Icon-Praxis findest du in unserem PWA-App-Icons-Geschichts-Beitrag.

Wann ICNS die richtige Wahl ist

  • Native macOS-Apps. Pflicht für jede Mac-Anwendung, die ein eigenes Icon im Dock und im Finder zeigt.
  • macOS-Datei-Type-Icons. Wenn eine App eigene Dokument-Type-Icons registriert (z.B. Photoshop's PSD-Icon).
  • Multi-Resolution-Asset-Bundles. Wenn alle macOS-Größen plus Retina-Varianten in einer Datei verpackt werden sollen.

Wann ICNS nicht ideal ist: iOS-Apps (PNG-Asset-Catalog), Cross-Plattform- Web-Auslieferung, Favicons (ICO ist hier Default), alles Nicht-Apple-Plattformen.

Quellen

Apple Human Interface Guidelines — App Icons · Wikipedia — Apple Icon Image Format · Apple Developer — High Resolution Guidelines · iconutil — macOS Man-Page · libicns — Open-Source-Decoder-Library · Susan Kare — Originale Mac-Icon-Designs · Apple Inc., „macOS App Icon Reference", Developer Documentation 2024.