Der automatische Upload läuft noch, aber neue Screenshots lassen sich nicht mehr sauber einem App-Store-Bereich zuordnen.
Schnellster Weg: Neue Integrationen bauen Sie mit der App Asset Library; bestehende migrieren Sie nach Asset-Typ zu Assets und Placements und prüfen Upload, Zuordnung und Reihenfolge je App. Apple kennzeichnet ältere Ressourcen als veraltet, erklärt sie damit aber nicht für sofort abgeschaltet. Die Versionshinweise zu App Store Connect API 4.5.1 nennen die betroffenen Ressourcen und verweisen auf das neue Modell.
Dieser Leitfaden passt zu Ihnen, wenn Sie Screenshots oder Vorschauvideos automatisiert hochladen und alte Schnittstellen zuordnen müssen. Wenn Sie mehrere Apps oder eigene Produktseiten pflegen, finden Sie hier eine Methode für schrittweise Migration und Abnahme. Wenn Ihre Pipeline Medien für In-App-Events verwaltet, können Sie prüfen, wie Sie dafür die neuen Asset-Ressourcen berücksichtigen.
Zuletzt aktualisiert am 15.10.2026; abgeglichen mit Apples Versionshinweisen zu API 4.5.1, der Asset-Dokumentation und den Statusinformationen.
Migrationsentscheidung: nach Integrationsstatus vorgehen
Die Versionshinweise vom 06.10.2026 markieren bestimmte bisherige Ressourcen für Screenshot-Sets, Screenshots, Vorschau-Sets und Vorschauen sowie Medien zu In-App-Events als veraltet. Apple verweist auf die App Asset Library. Daraus folgt jedoch weder ein Abschaltdatum noch, dass bestehende Assets sofort erneut hochgeladen werden müssen. Behandeln Sie „veraltet“ als Migrationssignal und stützen Sie Ihre Planung auf die dokumentierten Statusangaben, nicht auf eine vermutete Frist. Apples Versionshinweise zu API 4.5.1 sind die Quelle für Veröffentlichung und Deprecation-Hinweise.
Nutzen Sie diese Entscheidungszweige, bevor Sie Code ändern:
- Wenn Sie eine neue Integration entwickeln: Verwenden Sie direkt das App-Asset-Library-Modell. Ein neues Projekt auf alte Sets auszurichten, würde eine zusätzliche spätere Umstellung schaffen.
- Wenn Ihre laufende Pipeline alte Screenshot- oder Vorschauressourcen verwendet: Planen Sie die Migration nach Asset-Typ. Erfassen Sie zuerst Lesen, Erstellen, Aktualisieren, Löschen und Sortieren, statt nur den Upload-Endpunkt auszutauschen.
- Wenn Ihre Automatisierung keine der als veraltet markierten Ressourcen aufruft: Lassen Sie sie zunächst unverändert. Prüfen Sie die Abhängigkeiten bei der nächsten geplanten Wartung und vermeiden Sie eine Änderung ohne konkreten Berührungspunkt.
| Situation oder Kriterium | Bisheriges Set-Modell | App Asset Library | Arbeitsbewertung |
|---|---|---|---|
| Neue Automatisierung | Bindet den Ablauf an ältere Ressourcen und Set-Logik | Trennt Asset und Placement | Asset Library: 2 |
| Bestehende Pipeline mit vielen Lese- und Löschpfaden | Vertraute Abläufe, aber mögliche Abhängigkeit von veralteten Ressourcen | Erfordert eine vollständige Abbildung der Operationen | Erst Bestandsaufnahme, dann schrittweise Migration |
| Wiederverwendung einer Bild- oder Videodatei | Set und Anzeigezusammenhang sind eng gekoppelt | Asset und Zielposition werden getrennt verwaltet | Asset Library: 2, sofern Referenzdaten die Verwendung erlauben |
| Nicht betroffene Integration | Kein unmittelbarer Änderungsbedarf | Umstellung kann unnötige Arbeit verursachen | Unverändert lassen: 2 |
Ressourcenmodell: Asset und Placement getrennt behandeln
Im älteren set-basierten Modell richtet sich der Ablauf nach einem Set, das einem bestimmten Anzeigezusammenhang zugeordnet ist. In der App Asset Library verwalten Sie dagegen das Bild oder Video als Asset und verknüpfen es mit einem Placement. Das Placement beschreibt, wo und in welchem Lokalisierungskontext das Material eingesetzt werden soll. Apples Dokumentation zur Verwaltung von App-Store-Materialien erläutert die Verwaltung der Materialien; die Anleitung zum Hochladen von Assets beschreibt den Upload-Kontext.
| Arbeitsobjekt | Bisheriges Modell | Neues Modell | Migrationsprüfung |
|---|---|---|---|
| Bilddatei | Bestandteil eines Screenshot-Sets oder Screenshot-Ablaufs | Image-Asset in der Library | Asset-ID und Herkunft im eigenen Protokoll speichern |
| Videodatei | Bestandteil eines Vorschau-Sets oder Vorschau-Ablaufs | Video-Asset in der Library | Verarbeitungsergebnis getrennt vom Upload erfassen |
| Zielseite und Lokalisierung | Häufig über Set und zugehörigen Kontext abgebildet | Über Placement und verfügbare Placement-Gruppe bestimmen | Verfügbarkeit und Kontext aus Referenzdaten prüfen |
| Reihenfolge und Entfernung | Kann an Set-Operationen gebunden sein | Placement-Verknüpfungen und Assets separat verwalten | Abhängigkeiten vor dem Löschen auflösen |
**Achtung:** Behandeln Sie „Asset vorhanden“, „Placement angelegt“ und „Material auf der Seite ausgewählt“ als unterschiedliche Zustände. Eine erfolgreiche Antwort beim Upload beweist nicht, dass die spätere Darstellung bereits möglich ist.
Schnittstellenabdeckung: alle Operationen je Materialtyp erfassen
Eine Migration bleibt unvollständig, wenn nur der Upload umgestellt wird. In älteren Integrationen stecken oft zusätzliche Aufrufe in Verwaltungsjobs, manuellen Reparaturskripten oder Bereinigungsroutinen. Erstellen Sie vor der Änderung eine Bestandsliste mit den Materialtypen und den tatsächlich verwendeten Operationen.
| Materialbereich | Was in der vorhandenen Automatisierung zu erfassen ist | Ziel der Migration |
|---|---|---|
| Screenshots und Vorschauen für App-Versionen | Lesen, Hochladen, Aktualisieren, Sortieren und Entfernen | Image- und Video-Assets mit den benötigten Placements abbilden |
| Eigene Produktseiten | Zuordnung nach Seite, Lokalisierung und Anzeigekontext | Placements und verfügbare Gruppen verifizieren |
| Produktseiten-Experimente | Materialien und Varianten getrennt dokumentieren | Prüfen, welche Assets und Placements der konkrete Kontext unterstützt |
| Medien für In-App-Events | Alte Ressourcen und ihre Lebenszyklen identifizieren | Betroffene Ressourcen auf die dokumentierte Asset-Richtung umstellen |
Kompatibilität: Placement-Typen dynamisch entdecken
Vermeiden Sie dauerhafte Annahmen über Gerätetypen, Placement-Gruppen, Abmessungen und Einschränkungen. Lesen Sie die verfügbaren API-Referenzdaten aus und behandeln Sie diese als maßgeblichen Ausgangspunkt für die jeweilige App und den konkreten Anwendungsfall. Wenn Sie erlaubte Werte in eigener Konfiguration zwischenspeichern, planen Sie eine Aktualisierung ein, statt sie als unveränderliche Regeln zu behandeln.
Das gilt auch für IPHONE_DUO: Apple dokumentiert diese iPhone-Darstellungskategorie. Ihre Aufnahme in die Erkennung bedeutet aber nicht automatisch, dass jedes Bild oder Video für jedes Placement dieser Kategorie geeignet ist. Entscheidend sind die tatsächlich zurückgegebenen Referenzdaten sowie das Ergebnis der Verarbeitung und Zuordnung. Verknüpfen Sie die Kategorie deshalb mit einer Laufzeitprüfung, nicht mit einer fest eingebauten Freigabeannahme. Für die Einordnung von Zuständen und die Prüfung der Materialverwaltung helfen Apples Informationen zu App-Store-Asset-Status.
Wartung: Upload, Zuordnung, Sortierung und Löschen gemeinsam prüfen
Nach dem Upload kann ein Asset verarbeitet werden, bevor es für die gewünschte Zuordnung nutzbar ist. Danach kommt das Placement hinzu; anschließend müssen die Reihenfolge und die Auswahl im App-Store-Kontext stimmen. Diese Schritte sind voneinander zu unterscheiden. Modellieren Sie sie als getrennte Übergänge in Ihrem Skript und Protokoll, anstatt einen einzelnen booleschen Wert wie „Upload erfolgreich“ als Gesamtstatus zu verwenden.
Gehen Sie bei der Wartung so vor:
- Quelldatei und Ziel erfassen. Speichern Sie den Dateipfad oder eine interne Kennung, den App-Bezug, die beabsichtigte Lokalisierung und den Zielkontext. Damit lässt sich ein späterer Fehler einer konkreten Datei zuordnen.
- Asset erstellen und Antwort protokollieren. Halten Sie die zurückgegebene Ressource und den API-Erfolg fest. Kennzeichnen Sie diesen Zustand nicht als abgeschlossene Veröffentlichung.
- Verarbeitung abwarten und Status prüfen. Erfassen Sie die Verarbeitung getrennt. Apples Dokumentation zum Asset-Status ist maßgeblich, wenn Sie Statuswerte interpretieren.
- Placement anhand aktueller Referenzdaten anlegen. Prüfen Sie Gruppe, Ziel und Lokalisierung, bevor Ihr Skript die Verknüpfung erstellt. Ein erfolgreicher Upload ersetzt diese Prüfung nicht.
- Reihenfolge und Seitenauswahl kontrollieren. Verifizieren Sie die tatsächliche Reihenfolge im bearbeitbaren App-Store-Kontext und prüfen Sie, ob die Seite das erwartete Material verwendet.
- Löschpfad in Abhängigkeitsreihenfolge testen. Entfernen Sie nicht blind ein Asset, nur weil ein altes Set entfernt wurde. Klären Sie zuerst, ob Placements oder weitere Zuordnungen darauf verweisen, und protokollieren Sie das Ergebnis der einzelnen Löschoperationen.
Abnahme: bis zur sichtbaren Auswahl prüfen
Wählen Sie zunächst einen bearbeitbaren App-Store-Fall, bei dem Sie das Material ohne Risiko für eine unmittelbar anstehende Veröffentlichung kontrollieren können. Verwenden Sie eine klar erkennbare Datei und notieren Sie den erwarteten Zielkontext. So können Sie API-Zustände und sichtbare Auswahl vergleichen, ohne einen Upload-Erfolg mit einer fertigen Produktseite gleichzusetzen.
Prüfen Sie die Abnahme in dieser Reihenfolge:
- Das Image- oder Video-Asset wird angelegt und seine Kennung wird gespeichert.
- Der zurückgemeldete Verarbeitungszustand wird separat erfasst und als abgeschlossen bestätigt, bevor der nächste Schritt als erfolgreich gilt.
- Das Placement verweist auf die vorgesehene Position und Lokalisierung.
- Die Reihenfolge entspricht der gewünschten Darstellung.
- App Store Connect zeigt im bearbeitbaren Kontext das erwartete Material und die passende Auswahl.
- Ihre Protokolle halten API-Ergebnis, sichtbaren App-Store-Status und etwaige weitere Freigabe- oder Prüfzustände getrennt fest.
Führen Sie die Abnahme für jede betroffene App und jeden verwendeten Materialtyp durch, bevor Sie alte Pfade abschalten. Wenn Sie den Ablauf über einen Remote-Mac ausführen, ist dieser eine mögliche Laufzeitumgebung für Skripte, Xcode-nahe Werkzeuge oder macOS-spezifische Schritte – aber keine Voraussetzung dafür, die App Store Connect API aufzurufen. Ob ein Mac nötig ist, hängt davon ab, was Ihre Pipeline neben API-Anfragen tatsächlich ausführt.
Häufige Fragen zur Migration
Welche alten Ressourcen sind betroffen?
Apple nennt in den Versionshinweisen zu API 4.5.1 veraltete Ressourcen für Screenshot-Sets und Screenshots, Vorschau-Sets und Vorschauen sowie bestimmte Materialien für In-App-Events. Prüfen Sie die konkreten Einträge in den offiziellen Versionshinweisen, bevor Sie eine Ressource in Ihrer Integration als betroffen markieren. Die Kennzeichnung ist nicht gleichbedeutend mit einer sofortigen Abschaltung.
Wie unterscheidet sich die App Asset Library vom alten Screenshot-Set?
Das ältere Modell ordnet Material stärker einem Set und dessen Anzeigezusammenhang zu. In der App Asset Library speichern Sie Bilder und Videos als Assets und verbinden sie über Placements mit einer Zielposition und Lokalisierung. Dadurch müssen Sie Asset-Verwaltung und Seitendarstellung getrennt nachverfolgen. Ob ein bestimmtes Asset für einen konkreten Zielkontext verfügbar ist, prüfen Sie anhand der Referenzdaten und des Verarbeitungsergebnisses.
Kann dasselbe Bild auf mehreren lokalisierten Seiten verwendet werden?
Prüfen Sie zuerst, ob die gewünschten Placements und Lokalisierungen für den jeweiligen Kontext verfügbar sind. Wenn die Referenzdaten die Zuordnung erlauben, können Sie ein Asset mit mehreren passenden Placements verknüpfen, statt automatisch eine neue Datei hochzuladen. Kontrollieren Sie jede Zuordnung und die sichtbare Auswahl separat; dieselbe Datei bedeutet nicht automatisch, dass jede Seite dieselben Anforderungen oder Darstellungsoptionen hat.
Wie prüfen Sie Placement und Sortierung zuverlässig?
Kontrollieren Sie Asset-Erstellung, Verarbeitungsstatus, Placement-Zuordnung, Reihenfolge und Auswahl in App Store Connect als getrennte Ergebnisse. Protokollieren Sie die API-Antworten und den sichtbaren Zustand, damit ein Upload-Erfolg nicht fälschlich als fertige Darstellung gilt. Bei der Bereinigung prüfen Sie außerdem zuerst vorhandene Verknüpfungen, bevor Sie Assets löschen oder einen alten Set-Löschpfad übernehmen.
Nächster Schritt: Migration und Laufzeitumgebung getrennt entscheiden
Wenn Ihre Pipeline alte Screenshot-Sets oder Vorschauressourcen aufruft, beginnen Sie mit dem Inventar der Lese-, Schreib-, Sortier- und Löschoperationen und migrieren Sie anschließend je Materialtyp. Das ist belastbarer, als einen Upload-Endpunkt isoliert auszutauschen. Wenn Sie nur App Store Connect API-Aufrufe ausführen, macht diese Migration allein keinen Mac erforderlich.
Anders sieht es aus, wenn Ihr Veröffentlichungsprozess zusätzlich macOS-Werkzeuge, Xcode oder lokale Skripte benötigt und dauerhaft laufen soll. Ein eigener Mac bindet Kapital und muss von Ihnen betrieben werden; eine allgemeine CI-Umgebung kann an macOS-spezifischen Werkzeugen oder dauerhaft verfügbaren Sitzungen scheitern; eine Remote-Mac-Umgebung verursacht laufende Mietkosten und ist für dauerhaft hohe, stabile Auslastung nicht automatisch die günstigste Wahl. Wenn Sie zunächst nur eine reproduzierbare macOS-Laufzeit für Tests oder Veröffentlichungsaufgaben benötigen, können Sie die MACGPU-Übersicht zu Remote-Mac-Optionen prüfen oder die verfügbaren M4-Mietoptionen mit einem eigenen Gerät vergleichen. Entscheiden Sie nach Werkzeugbedarf, Betriebsaufwand und Nutzungsdauer – nicht danach, dass eine API-Migration pauschal einen Mac voraussetze.