So lädst du App-Store-Screenshots in nativer Auflösung herunter

Probier es einmal aus und das Problem liegt auf der Hand. Du öffnest einen App-Store-Eintrag, machst einen Rechtsklick auf einen Screenshot, speicherst ihn und landest bei einem Bild von gerade mal rund 300 Pixeln Breite. Auf eine brauchbare Größe hochgezogen wird daraus Matsch. Es ist keine gute Kopie des Bildmaterials. Es ist eigentlich überhaupt keine Kopie des Bildmaterials.

Das liegt nicht daran, dass Apple sich querstellt. Es ist ein Nebeneffekt davon, wie die Seite aufgebaut ist, und sobald du das verstehst, ist das Beschaffen der echten Datei ganz einfach.

Die Seite hat nie das echte Bild

Apple liefert das Bildmaterial der Einträge über ein Bild-CDN auf mzstatic.com aus. Und das ist entscheidend: Das CDN speichert nicht eine Datei pro Screenshot, sondern ein Original und erzeugt bei Bedarf eine skalierte Kopie, je nachdem, was die URL verlangt. Die URLs sehen so aus:

https://is1-ssl.mzstatic.com/image/thumb/PurpleSource211/v4/…/WH_iOS_03.jpg/300x650bb.webp

Lies das Ende dieser URL: 300x650bb.webp. Das ist eine Anweisung. Sie sagt gib mir dieses Bild mit 300×650, beschnitten, als WebP. Der Browser fordert ein kleines WebP an, weil ein kleines WebP dafür sorgt, dass die Seite auf einem Handy schnell lädt. Das ist die richtige Entscheidung für eine Store-Seite und die falsche Datei für dich.

Wenn du also mit einem Rechtsklick speicherst, schnappst du dir keine komprimierte Version des Originals. Du schnappst dir eine völlig andere Datei, die das CDN spontan nach Apples Vorgabe erzeugt hat, nicht nach deiner.

Stattdessen das Original anfragen

Ändere das Ende der URL und das CDN erzeugt eine andere Größe. Frag 1284x2778bb.png an und du bekommst das Bild mit 1284×2778, als PNG. Das ist das Original in nativer Auflösung.

Die naheliegende nächste Frage: Woher weißt du, dass es 1284×2778 ist und nicht etwas anderes? Raten kannst du nicht, und hoch zu greifen bringt nichts: Mehr Pixel anzufragen, als die Quelle hat, liefert dir nur eine hochskalierte, unscharfe Datei, die die richtigen Maße behauptet.

Zum Glück verrät Apple es dir. Vergraben im HTML der Seite steckt ein JSON-Block: Halte nach einem Script-Tag mit der id serialized-server-data Ausschau, und darin wird jedes Stück Bildmaterial so beschrieben:

{
 "$kind": "Artwork",
 "template": "https://is1-ssl.mzstatic.com/…/WH_iOS_03.jpg/{w}x{h}{c}.{f}",
 "width": 1284,
 "height": 2778
}

Da ist es. Die template enthält die wörtlichen Platzhalter {w} und {h}, und der Knoten liefert dir gleich die echten nativen Maße dazu. Füll die Vorlage mit der eigenen Breite und Höhe des Bildes aus und das CDN gibt genau die Datei zurück, die der Entwickler hochgeladen hat.

Ein wissenswertes Detail: Die Dateinamen bleiben erhalten

Sieh dir diese URL noch einmal an und dir fällt etwas Nützliches auf: WH_iOS_03.jpg. Die CDN-Pfade von Apple bewahren den ursprünglichen Dateinamen des Bildmaterials vom Upload.

In der Praxis ist das wertvoller, als es klingt. Echte Einträge tragen oft Namen wie EC-15030-WH-UK-Offer-R30-CPP-UK-iOS-6.5-1284x2778-S01.jpg, worin der Kampagnencode, der Markt, die Geräteklasse und die Foliennummer stecken. Wenn du versuchst, extrahierte Assets mit den Quelldateien eines Design-Teams oder einem Kampagnen-Briefing abzugleichen, nehmen dir diese Namen einen großen Teil der Zuordnung ab.

Die Falle: Schnapp dir nicht das Icon der falschen App

Eine Warnung, denn es ist ein leichter und peinlicher Fehler.

Das App-Icon steckt nicht zuverlässig in diesem JSON-Block: Der Kopfbereich, in dem es angezeigt wird, wird clientseitig gerendert und ist im rohen HTML leer. Zugleich enthält dieselbe Seite eine Leiste „Das könnte dir auch gefallen“, vollgepackt mit den Icons anderer Apps, in einer fast identischen JSON-Form.

Ein naives Scraping, das die Seite nach etwas Icon-Förmigem durchsucht, liefert also seelenruhig das Icon eines Konkurrenten zurück. Wir wissen das, weil die erste Version unseres eigenen Tools genau das tat und einem Kunden beinahe das Logo eines Rivalen als sein eigenes untergejubelt hätte.

Die Lösung ist, mit dem Scrapen aufzuhören und stattdessen zu fragen. Apple betreibt einen öffentlichen Abfrage-Endpunkt, der für eine gegebene App-ID maßgeblich ist:

https://itunes.apple.com/lookup?id=465712788&country=gb

Der gibt die echten Metadaten der App zurück, einschließlich der Icon-URL, und weil er sich an der App-ID orientiert, gibt es keine Möglichkeit, versehentlich das Bildmaterial des Nachbarn zu erwischen. Beachte, dass dieser Endpunkt manchmal eine leere Screenshot-Liste zurückgibt, er ist also kein Ersatz fürs Parsen der Seite. Nutze die Seite für die Screenshots und die Abfrage für das Icon.

Welche Qualität du tatsächlich bekommst

Reden wir Klartext, denn viele Tools versprechen zu viel.

Was du zurückbekommst, ist genau die Datei, die der Entwickler zu App Store Connect hochgeladen hat, nicht besser. Apple speichert sie als JPEG. Unser Tool exportiert sie als PNG, was verhindert, dass beim Ausgeben eine zweite Runde verlustbehafteter Kompression angewendet wird, aber es kann die bereits in der Quelle eingebrannte Kompression nicht rückgängig machen. Es gibt kein Hochskalieren und kein Zurückholen von Details, die nie da waren.

Für die Nutzung am Bildschirm, für Präsentationen, Audits, Wettbewerbsanalysen oder den Nachbau eines Eintrags ist das genau das, was du willst. Für den Druck ist es das nicht, und keine noch so clevere URL-Manipulation ändert daran etwas. Besorg dir die Design-Dateien.

Das Ganze ohne die Handarbeit

Alles oben ist mechanisch, deshalb haben wir es automatisiert. Füg die URL eines Eintrags in das Tool ein, und es liest das JSON, holt jeden Bildmaterial-Knoten in seinen eigenen nativen Maßen, ruft das Icon über die Lookup-API ab und übergibt dir ein ZIP mit einem Manifest, das jede Datei ihrer Quelle zuordnet.

Wenn du auch die Play-Store-Seite verstehen willst, das funktioniert nach demselben Prinzip, aber mit einer völlig anderen Datenstruktur, das haben wir separat beschrieben.