App Store Connect API 4.6: Was tun, wenn der INSTALLS-Bericht eingestellt wird? 2026

Der geplante Abruf läuft durch, aber eine neue INSTALLS-Datei fehlt.

Schnellste Einordnung: App Store Connect API 4.6 beendet die Erzeugung neuer INSTALLS-Berichte; bereits vorhandene Berichte können weiterhin abrufbar sein. Behandeln Sie das Fehlen eines neuen Berichts deshalb nicht automatisch als CI-Störung: Prüfen Sie den Apple-Berichtsstatus, sichern Sie die Historie und ändern Sie Dashboard und Aufgabenlogik, bevor Sie endlos erneut abrufen. Apple veröffentlichte API 4.6 am 04.11.2026; der Stand dieses Artikels wurde am 07.11.2026 anhand der Apple-Veröffentlichungsseite und der Release Notes der App Store Connect API geprüft.

Dieser Leitfaden richtet sich an Entwickler, die Berichte über die App Store Connect API herunterladen und den Berichtstatus von Authentifizierungs- oder Anfragefehlern unterscheiden müssen.
Er ist für CI-Verantwortliche gedacht, die geplante Läufe an eine geänderte Berichtserzeugung anpassen möchten.
Auch für Dashboard-Verantwortliche ist er relevant, wenn fehlende Daten derzeit als null oder als echter Rückgang erscheinen.

Die Änderung nach Nutzungsszenario einordnen

Der zentrale Unterschied lautet: Ein neuer Bericht wird nicht mehr erzeugt ist nicht dasselbe wie ein Abruf ist technisch fehlgeschlagen. Laut Apples Unterlagen zu API 4.6 wird der INSTALLS-Bericht nicht weiter neu erstellt. Apple unterscheidet davon die Verfügbarkeit bereits erzeugter Berichte. Prüfen Sie für Ihre konkrete Abfrage die Release Notes, die Sales-Reports-Schnittstelle und die Angaben zur Verfügbarkeit von Sales- und Trends-Berichten.

Für die Fehlersuche sind drei Fälle getrennt zu behandeln:

• Kein neuer Bericht vorhanden: Der Auftrag hat die Anfrage durchgeführt, aber es gibt keinen neuen INSTALLS-Bericht zum Abruf. Das kann der erwartete Zustand sein.
• Anfrage wurde abgewiesen oder schlug fehl: Prüfen Sie Berechtigungen, Authentifizierung, Anfrageparameter und Netzwerkpfad. Die Änderung der Berichtserzeugung erklärt nicht automatisch solche Fehler.
• Bericht wurde geladen, aber downstream nicht verarbeitet: Untersuchen Sie Entpacken, Formatannahmen, Speicherung und den Import in Dashboard oder Datenbank.

Die Release Notes beschreiben die API-Änderung; sie ersetzen nicht die Prüfung Ihrer eigenen Anfrage und ihrer Antwort. Die Apple-Dokumentation zum API-Zugang hilft dabei, Zugang und Berechtigungen als separate Fehlerquelle zu betrachten.

Wichtig: Ein erfolgreicher Prozessstatus besagt nur, dass Ihr Skript den Lauf entsprechend seiner eigenen Logik abgeschlossen hat. Er bestätigt nicht, dass Apple einen neuen INSTALLS-Bericht bereitgestellt hat.

Wenn der geplante Download keinen neuen Bericht findet

Beginnen Sie nicht mit einer Änderung an der CI-Maschine. Prüfen Sie zuerst, ob die Anfrage tatsächlich auf INSTALLS zielt und ob das Skript einen leeren oder nicht verfügbaren Bericht korrekt von einer fehlerhaften Antwort unterscheidet. Ein Abruf, der zuvor regelmäßig eine Datei geliefert hat, kann nach einer Änderung des Berichtsstatus weiterhin technisch korrekt ausgeführt werden, ohne dass es eine neue Datei gibt.

Gehen Sie die Protokolle in dieser Reihenfolge durch:

• Anfrageziel und Parameter: Halten Sie fest, welche Berichtskategorie, welcher Zeitraum und welche weiteren Filter angefragt werden. Verändern Sie für den Vergleich nur einen Parameter auf einmal.
• Authentifizierung und Berechtigung: Prüfen Sie, ob die Anfrage weiterhin gültige Zugangsdaten verwendet und ob die erforderlichen Zugriffsrechte vorliegen. Ein fehlender Bericht und eine abgelehnte Anfrage sind unterschiedliche Ergebnisse.
• Antwort und Prozessausgang: Speichern Sie den relevanten Antwortstatus und die Fehlermeldung, nicht nur die abschließende Zeile „Job fehlgeschlagen“ oder „Job erfolgreich“.
• Datei- und Importpfad: Prüfen Sie, ob eine erwartete Datei tatsächlich fehlt oder ob sie zwar ankommt, aber wegen eines Pfad-, Namens- oder Formatfehlers nicht in die nächste Verarbeitung gelangt.
• Apple-Dokumentation: Vergleichen Sie die konkrete Report-Kategorie mit den aktuellen Release Notes und den verfügbaren Berichten. Interpretieren Sie einzelne Community-Berichte nicht als allgemeine Bestätigung.

Wenn Sie bereits einen allgemeinen Leitfaden für Berichtsabruf und Automatisierung pflegen, ergänzen Sie dort den Unterschied zwischen „kein neuer Bericht“ und „Abruffehler“. So muss das Team dieselbe Diagnose nicht bei jedem Lauf erneut aus der Loghistorie ableiten.

Fehlende Daten im Dashboard korrekt darstellen

Ein Dashboard, das eine fehlende Datei als numerischen Wert null behandelt, kann einen nicht vorhandenen Messpunkt in einen scheinbaren Rückgang verwandeln. Das ist besonders problematisch, wenn nachgelagerte Kennzahlen aus dem Wert berechnet werden: Eine Grafik sieht dann vollständig aus, obwohl sie einen anderen Sachverhalt abbildet als den gemessenen Wert.

Speichern Sie deshalb den Messwert und den Berichtstatus getrennt. Ein Datensatz kann etwa enthalten, ob ein Bericht erfolgreich importiert wurde, ob für den Zeitraum kein Bericht vorlag oder ob ein technischer Fehler den Abruf verhindert hat. Die konkrete Darstellung sollte diese Zustände für Nutzer sichtbar unterscheiden, statt eine einzelne Zahl für alle Fälle zu erzwingen.

Prüfen Sie anschließend alle Stellen, die den Wert weiterverarbeiten:

• Diagramme: Unterbrechen Sie die Reihe oder kennzeichnen Sie den Zeitraum als nicht verfügbar, statt fehlende Werte automatisch auf null zu setzen.
• Warnungen: Lösen Sie keine Meldung über einen vermeintlichen Installationsrückgang aus, wenn die Datenquelle lediglich keinen Bericht geliefert hat.
• Aggregationen: Prüfen Sie, ob Mittelwerte, Summen oder Vergleichszeiträume fehlende Werte stillschweigend als null berücksichtigen.
• Datenexporte: Geben Sie Status und Messwert mit aus, damit ein nachgelagertes System den Unterschied nicht wieder verliert.
• Dokumentation: Erläutern Sie im Dashboard, ob ein Zeitraum gemessen, nicht verfügbar oder wegen eines technischen Fehlers unvollständig ist.

Apple definiert Kennzahlen in seiner Dokumentation zu App-Store-Connect-Metriken. Verwenden Sie diese Definitionen, wenn Sie Daten aus verschiedenen Berichtsarten vergleichen. Ein ähnlicher Name oder eine ähnliche Darstellung belegt nicht, dass zwei Kennzahlen denselben Inhalt und dieselbe Zählweise haben.

Historische INSTALLS-Berichte sichern, bevor Sie die Pipeline ändern

Die Möglichkeit, neue Berichte zu erzeugen, und der Zugriff auf bereits erzeugte Berichte sind unterschiedliche Fragen. Apple dokumentiert die Berichtverfügbarkeit und den Abruf über die Sales-Reports-Schnittstelle separat. Prüfen Sie daher die aktuellen Verfügbarkeitsregeln und die Schnittstellenbeschreibung, bevor Sie aus einem erfolgreichen historischen Abruf eine dauerhafte Verfügbarkeitsgarantie ableiten.

Für eine belastbare Archivierung sollten Sie Ihre eigenen Kopien kontrollieren, nicht allein auf spätere Abrufe vertrauen:

• Erfassen Sie, welche Zeiträume und Berichtstypen tatsächlich lokal oder in einem Teamarchiv vorliegen.
• Speichern Sie die unveränderte Originaldatei und halten Sie zusätzlich fest, wann und mit welchen Anfrageparametern sie abgerufen wurde.
• Dokumentieren Sie, welche Verarbeitungsschritte aus dem Original eine Kennzahl oder Dashboard-Reihe erzeugt haben.
• Sichern Sie die Daten in einem Speicher, auf den das zuständige Team zugreifen und dessen Aufbewahrungsregeln es nachvollziehen kann.
• Testen Sie einen historischen Abruf separat von einem Auftrag, der auf einen neuen Bericht wartet.

Beachten Sie dabei Datenschutz und Zugriffskontrolle: Legen Sie fest, wer Rohberichte lesen und exportieren darf, und richten Sie Aufbewahrung und Löschung nach Ihren internen Vorgaben sowie den anwendbaren Datenschutzanforderungen aus. Ein Archiv ist nicht automatisch sinnvoll, nur weil ein Bericht verfügbar ist; es braucht einen definierten Zweck, begrenzte Zugriffe und einen nachvollziehbaren Lebenszyklus.

Ersatzkennzahlen nicht ohne Prüfung gleichsetzen

Wenn Produkt- oder Vertriebsverantwortliche eine Ersatzreihe verlangen, klären Sie zuerst, welche Frage beantwortet werden soll. Geht es um Installationsereignisse, um Akquisition beziehungsweise Herkunft neuer Nutzer oder um eine andere Aktivität? Die passende Kennzahl hängt davon ab, ob die Entscheidung die Reichweite, Nutzung, Kampagnenbewertung oder einen internen Prozess betrifft.

Apple dokumentiert unterschiedliche Berichts- und Analysebereiche, darunter App-Installationen und Löschungen sowie Platform App Installs. Die Existenz einer anderen Dokumentation ist kein Beleg dafür, dass deren Kennzahl den eingestellten INSTALLS-Bericht mit identischer Definition ersetzt. Prüfen Sie zunächst die Beschreibung, den Erfassungsumfang und die verfügbaren Zeiträume in Apples Quellen. Gleichen Sie anschließend die Bedeutung mit den konkreten Anforderungen des Teams ab.

Gehen Sie für eine mögliche Ersatzkennzahl so vor:

• Schreiben Sie die fachliche Frage auf, die der bisherige INSTALLS-Wert beantworten sollte.
• Lesen Sie die offizielle Definition der vorgeschlagenen Kennzahl und notieren Sie Unterschiede in Umfang oder Interpretation.
• Testen Sie die neue Datenquelle parallel zu einer gesicherten historischen Reihe, ohne beide Werte zunächst zusammenzuführen.
• Markieren Sie einen Wechsel in Datenquelle oder Definition im Dashboard und in exportierten Daten.
• Stimmen Sie die neue Interpretation mit den Personen ab, die anhand der Kennzahl Entscheidungen treffen.

Ohne ausdrückliche Bestätigung durch Apple oder eine nachvollziehbare Prüfung in Ihrem eigenen Projekt sollten Sie keine andere Kennzahl als gleichwertigen Ersatz bezeichnen.

macOS CI an den erwarteten Berichtstatus anpassen

Die API ist nicht deshalb an macOS gebunden, weil sie App-Store-Daten liefert. Ein geeigneter CI-Lauf kann auf einer Plattform ausgeführt werden, die Ihre Skripte, Sicherheitsanforderungen und Abläufe unterstützt. Wenn Ihre bestehende Pipeline jedoch macOS-spezifische Werkzeuge, Abhängigkeiten oder Betriebsprozesse nutzt, müssen Sie den Statuswechsel in dieser Umgebung gezielt abbilden.

Passen Sie die Fehlerbehandlung so an, dass ein erwartetes Fehlen neuer INSTALLS-Berichte nicht dieselbe Reaktion auslöst wie ein ungültiges Token oder eine fehlerhafte Anfrage. Eine automatische Wiederholung kann bei zeitweiligen Netzwerkproblemen sinnvoll sein; sie ist aber kein Ersatz für die fachliche Behandlung eines Berichts, der nicht mehr neu erzeugt wird. Legen Sie fest, welche Antwort erneut versucht werden soll und bei welchem Ergebnis der Lauf mit einem dokumentierten Status beendet wird.

Ein kontrollierter Anpassungsablauf sieht so aus:

1. Ausgangszustand erfassen: Sichern Sie die aktuelle Anfrage, die relevanten Protokolle und die Verarbeitungsschritte vom Download bis zum Dashboard.
2. Ergebnisse klassifizieren: Unterscheiden Sie Bericht nicht verfügbar, Authentifizierungsfehler, Anfragefehler und Fehler in der Weiterverarbeitung.
3. Wiederholungen begrenzen: Wiederholen Sie nur solche Ergebnisse, bei denen ein erneuter Versuch technisch begründet ist. Der Zustand „kein neuer Bericht“ sollte nicht ohne Ende neue Läufe auslösen.
4. Protokolle verbessern: Halten Sie Berichtstyp, Anfragezeitraum, Antwortstatus, Laufstatus und Importergebnis fest. Entfernen oder schützen Sie sensible Zugangsdaten in den Logs.
5. Archivpfad prüfen: Rufen Sie einen vorhandenen historischen Bericht ab, sofern er laut Dokumentation verfügbar ist, und testen Sie damit die Lese- und Importstrecke.
6. Fehlerpfad testen: Prüfen Sie mit einem realen CI-Lauf, ob ein fehlender neuer Bericht als eigener Zustand erfasst wird und ob technische Fehler weiterhin sichtbar bleiben.
7. Dashboard und Warnungen abnehmen: Stellen Sie sicher, dass fehlende Daten nicht als null erscheinen und die zuständigen Personen keine irreführende Trendmeldung erhalten.

Dieser Test trennt zwei Aussagen, die im Betrieb leicht verwechselt werden: Der historische Abruf belegt, dass Ihre Pipeline eine vorhandene Datei verarbeiten kann; ein aktueller Lauf belegt, wie Ihre Aufgabe auf den gegenwärtigen Zustand reagiert. Keiner dieser Tests beweist für sich allein, dass künftig neue INSTALLS-Berichte erzeugt werden.

Betriebshinweis: Wenn Sie macOS CI für weitere geplante Aufgaben nutzen, dokumentieren Sie deren Abhängigkeiten getrennt vom Status dieses Berichts. Die Einstellung eines einzelnen Berichtstyps ist kein Grund, eine ganze CI-Umgebung ungeprüft als ausgefallen oder überflüssig einzustufen.

Prüfliste für die Umstellung

Arbeiten Sie die Punkte für Ihre Pipeline ab und lassen Sie jeden Schritt von der zuständigen Person bestätigen:

• [ ] Die Release Notes und die Berichtverfügbarkeit wurden mit dem tatsächlich angefragten INSTALLS-Bericht abgeglichen.
• [ ] Die Protokolle unterscheiden fehlenden Bericht, Authentifizierungsfehler, Anfragefehler und Importfehler.
• [ ] Ein leerer Berichtstatus wird weder als Installationswert null gespeichert noch in der Visualisierung als echter Rückgang dargestellt.
• [ ] Wiederholungen sind auf technisch plausible vorübergehende Fehler begrenzt.
• [ ] Vorhandene historische Berichte wurden inventarisiert und wichtige Dateien in ein teamkontrolliertes Archiv übernommen.
• [ ] Der historische Abruf und die Reaktion auf einen aktuellen Lauf wurden unabhängig voneinander geprüft.
• [ ] Eine mögliche Ersatzkennzahl wurde anhand ihrer offiziellen Definition und der tatsächlichen fachlichen Frage bewertet.
• [ ] Verantwortliche für Datenpipeline, Dashboard und Auswertung kennen den dokumentierten Wechsel.

Wenn Sie für weitere macOS-Aufgaben eine dauerhaft erreichbare Umgebung prüfen, entscheiden Sie anhand der tatsächlichen Anforderungen an Zeitplanung, Zugriff und Wartung. Hinweise zu Zugang und Einsatzmöglichkeiten finden Sie in den FAQ zu den Umgebungs- und Zugriffsfragen; daraus folgt nicht, dass die App Store Connect API zwingend auf einem Mac laufen muss.

Häufige Fragen

Wird App Store Connect API 4.6 noch neue INSTALLS-Berichte erzeugen?

Nach Apples Dokumentation zu API 4.6 wird der INSTALLS-Bericht nicht weiter neu erzeugt. Behandeln Sie einen fehlenden neuen Bericht daher zunächst als möglichen Status der Berichtserzeugung und nicht automatisch als vorübergehenden CI-Ausfall. Prüfen Sie trotzdem Authentifizierung, Anfrageparameter und Protokolle, damit Sie einen zusätzlichen technischen Fehler nicht übersehen.

Kann ich ältere INSTALLS-Berichte weiterhin über die API abrufen?

Apple unterscheidet die weitere Erzeugung neuer Berichte von der Verfügbarkeit bereits erzeugter Berichte. Prüfen Sie die aktuelle Dokumentation zur Sales-Reports-Schnittstelle und zur Verfügbarkeit der Berichte, bevor Sie den Abruf alter Daten als dauerhaft gesichert einplanen. Laden Sie benötigte Dateien in Ihr eigenes Archiv und dokumentieren Sie Abrufzeitraum, Anfrageparameter und Ergebnis.

Ist ein fehlender Bericht ein Fehler meines geplanten CI-Laufs?

Nicht zwingend. Ein erfolgreicher Lauf kann korrekt feststellen, dass kein neuer Bericht bereitsteht; ein fehlgeschlagener Lauf kann dagegen auf ein Token-, Berechtigungs-, Netzwerk- oder Anfrageproblem hindeuten. Protokollieren Sie diese Fälle getrennt. Ein erfolgreicher Prozesslauf belegt, dass die Aufgabe ihre Logik ausgeführt hat, aber nicht, dass Apple einen neuen Bericht erzeugt hat.

Wie verhindere ich, dass das Dashboard fehlende Daten als null anzeigt?

Speichern Sie den Status „kein Bericht verfügbar“ getrennt von einem numerischen Messwert. Lassen Sie Berechnungen und Diagramme fehlende Daten nicht stillschweigend in null umwandeln; sonst kann eine Unterbrechung der Berichtsreihe wie ein tatsächlicher Einbruch wirken. Kennzeichnen Sie den betroffenen Zeitraum und halten Sie fest, ob ein Wert aus einem Bericht stammt oder schlicht nicht vorliegt.

Wenn die Berichtspipeline mehr als einen kurzfristigen Fix braucht

Ein vorhandener Rechner kann für einen gelegentlichen Abruf ausreichen, hat aber Nachteile, wenn er schlafen geht, gewartet werden muss oder nicht zuverlässig verfügbar ist. Eine allgemeine Linux-Umgebung kann wiederum ungeeignet sein, wenn angrenzende Aufgaben tatsächlich macOS-Werkzeuge benötigen. Ein eigener Mac vermeidet manche Abhängigkeiten von einem Arbeitsplatz, bindet Sie aber an den Kauf und die laufende Pflege physischer Hardware. Entscheiden Sie deshalb nach dem Gesamtbetrieb und nicht nach der Annahme, dass dieser API-Bericht selbst einen Mac voraussetzt.

Wenn Sie für andere geplante macOS-Arbeiten eine zeitweise oder fortlaufende Mac-Umgebung benötigen, kann die Miete eines Mac von UDPMac eine Alternative zum Kauf und zur Pflege eigener Hardware sein. Für einen einzelnen, plattformunabhängigen API-Abruf ist sie nicht automatisch sinnvoll; prüfen Sie zuerst Laufzeit, Wartungsaufwand und macOS-Abhängigkeiten Ihrer gesamten Aufgaben. Einen Überblick über die verfügbare Mac-Umgebung können Sie dann mit Ihrem tatsächlichen Betriebsbedarf abgleichen.

Häufig gestellte Fragen