App Store Connect API 4.6: What to Do When INSTALLS Reports Stop Updating? 2026

Apple lists App Store Connect API 4.6 as released on November 4, 2026, in its release announcement. As of November 7, the practical conclusion is clear: new INSTALLS reports will no longer be generated, while eligible historical reports remain downloadable. Don’t treat the absence of a new report as a temporary CI failure and retry indefinitely. Preserve the history you can retrieve, revise your job and dashboard states, and don’t label another metric an equivalent replacement unless Apple confirms that relationship.

Suitable for: Engineers maintaining App Store Connect report downloads who need to separate a report lifecycle change from authentication, network, or script failures.
Also for: macOS CI owners adjusting scheduled jobs, and dashboard maintainers protecting historical trends from false zeroes.

Last updated November 7, 2026; checked against Apple’s API 4.6 release notes, reporting endpoint documentation, and sales and trends report availability guidance.

Start with the report’s lifecycle, not the CI host

The first diagnostic question is whether Apple still generates the requested report. API 4.6 changes the expected outcome for new INSTALLS reports; a successful network connection cannot make a discontinued report appear. Apple’s API release notes are the primary source for the change. The Sales and Trends Reports availability page provides the relevant context for report availability.

This distinction matters because “no report returned” can describe different conditions:

• Apple no longer generates a new report of the requested type.
• The request targets an unsupported report or date range.
• Authentication or authorization failed.
• A transient network or service issue interrupted the request.
• The script received a response but mishandled its status, headers, or payload.
• A downstream step discarded a valid file or interpreted an empty result as zero.

Treat the first condition as an expected product behavior, not an infrastructure incident. Treat the others as possible faults that still need investigation. Record which category you observed; a generic “download failed” message makes future diagnosis harder.

Will API 4.6 still generate new INSTALLS reports?

No. The change described in Apple’s API 4.6 information means new INSTALLS reports will not continue to be generated. Keep the distinction between generation and retrieval: the end of new report generation does not, by itself, mean every previously generated report has disappeared.

A successful request for an older report is evidence about that historical retrieval path only. It is not evidence that Apple has resumed generating current reports. Likewise, a request that returns no new file should not be called an API outage until you have checked the report lifecycle and the response details.

When a scheduled job stops finding a fresh file, compare its request target and requested period with Apple’s current documentation. Then inspect the response and job logs. If the request asks for a report that is no longer generated, change the expected result. If it asks for an eligible historical report and fails, investigate the ordinary request path instead.

Is a missing new report a script error?

Not necessarily. The absence alone cannot identify the cause. Check the request parameters, response status, authentication outcome, and the script’s handling of an empty or unavailable result. Save enough diagnostic information to distinguish an expected no-report response from a failed request, while keeping credentials and sensitive data out of logs.

Apple documents the Sales and Trends report endpoint separately from the report’s availability. Use those documents together: the endpoint explains the request surface, while availability guidance helps you determine whether a report should exist for the period you asked for.

Separate dashboard states before changing the metric

A missing report is not a zero-install result. If your ingestion pipeline converts an empty response, absent file, or failed download into 0, the dashboard can show a sharp but fictional drop. That can trigger incorrect business decisions and make historical comparisons unreliable.

Represent report state separately from metric value. A useful model distinguishes:

• Available: a report was retrieved and parsed. Display the measured value.
• Not generated: the report is no longer produced for the requested period. Show that status, not a fabricated value.
• Unavailable or not yet retrievable: the report is expected, but no usable file was obtained. Keep it separate from a valid zero.
• Request failed: authentication, network, permission, or parsing errors prevented a reliable result.

Your dashboard may use different labels, but the underlying distinction should survive through ingestion, transformation, storage, and presentation. If a warehouse table stores only a number, add a report-status field or another explicit representation before backfilling or changing chart logic.

The table is a decision aid, not a claim that every historical report will remain available indefinitely. Check Apple’s current report availability guidance for the requested report and period before promising a retrieval window to your team.

Dashboard warning: A missing observation and a measured value of zero are different facts. Preserve that difference in your data model, not only in chart formatting.

For metric interpretation, consult Apple’s analytics metric definitions. Apple separately documents App Store installs and deletions and Platform App Installs. Their names are not enough to establish that either can replace the discontinued report in your dashboard. Check definitions, population, timing, and intended use before comparing them.

Preserve historical files as a separate data product

If your team needs to analyze pre-change INSTALLS data, treat the existing archive and the new-report generation state as separate concerns. Apple’s API 4.6 change does not justify deleting local files, clearing report tables, or rewriting the historical series as if new observations had arrived.

Can you still download historical INSTALLS reports through the API?

Historical retrieval remains distinct from generating a new report. Apple’s reporting documentation describes the endpoint and report availability; use it to verify that the particular report and period you need can be requested. Do not infer an unlimited retention promise from the fact that historical reports remain available now.

For a historical recovery or validation, keep the request parameters, retrieval timestamp, response outcome, and resulting file together. Record the report period represented by the file, rather than using the download date as the data period. If your archive already contains the file, compare its metadata and content before replacing it with a newly retrieved copy.

Build an archive owned by your team rather than relying on the API as the only copy. Preserve original downloads in a controlled location, retain enough metadata to trace each file to its request, and keep parsed tables reproducible from those source files. Apply your normal access controls and retention rules, especially if the files feed financial or operational reporting.

This is also where teams often discover a hidden dependency: a dashboard may still look correct because it reads a local cache, while a new download has been failing for some time. Compare the archive, job logs, and dashboard’s latest data timestamp. A visible chart alone does not prove that the scheduled retrieval path is healthy.

Evaluate substitutes by definition, not by label

A request to “fill in INSTALLS” is incomplete until the team specifies what decision the number supports. It might mean install events, acquisition activity, a platform-specific measure, or another product behavior. These concepts can overlap without being interchangeable.

Start with the business question. If the chart is used to assess acquisition performance, identify whether the intended measure is about users, downloads, or another event. If the chart supports operational monitoring, establish what should count as a successful installation and which platforms or populations are included. Then compare those requirements with Apple’s documented definitions.

Apple’s metrics reference and its documentation for App Store installs and deletions and Platform App Installs are useful sources for that review. A matching label or a plausible trend is not enough. Differences in scope, attribution, timing, or inclusion rules can create a misleading join between series.

Until the definitions have been checked and the team has validated the measure against its use case, display a candidate metric as a separate series with its own label. Do not backfill INSTALLS with another report, rename it “INSTALLS,” or splice values into one historical line. If Apple later confirms a replacement or updates its documentation, revise the mapping with an explicit effective date and retain the original series.

Adapt the macOS CI scheduled job

A macOS CI scheduled task can still be useful for retrieving eligible history, archiving files, or running other report processing. The API change affects the job’s expected result; it does not prove that the task must run on macOS. Choose the host based on what the rest of the pipeline requires.

Use this sequence to update the job without hiding genuine failures:

• [ ] Capture the current behavior. Save a representative request, response status, relevant response headers, script output, and job result. Redact tokens and other secrets before retaining logs.
• [ ] Check the report target. Confirm that the request asks for the intended report type and period. Compare the target with Apple’s API 4.6 notes and the current endpoint documentation.
• [ ] Classify outcomes explicitly. Separate “not generated” from authentication failure, transport failure, permission problems, parsing errors, and an unexpected empty payload.
• [ ] Change retry rules. Retry transient failures under your normal policy. Do not keep retrying an expected absence of a newly generated INSTALLS report as though another attempt will restore it.
• [ ] Protect the stored data. Keep a missing-report status distinct from a numeric zero. Avoid overwriting the last valid historical value with an empty result.
• [ ] Test historical retrieval. Request a historical period that Apple’s current guidance indicates is available to your account, and verify the file and parsed records. A successful historical request tests retrieval, not new report generation.
• [ ] Test the scheduled path. Run the actual task and confirm that logs, alert routing, and dashboard updates reflect the outcome correctly. A green job status means the task handled its expected state; it does not mean new INSTALLS reports are still being generated.
• [ ] Document the change for consumers. Tell dashboard users when the series stops receiving new reports, how they should interpret the final period, and whether any separately defined metric is shown alongside it.

Operational boundary: Successful authentication or a successful CI run does not prove that a discontinued report can be generated. Keep transport health and report availability as separate signals.

For access and credential setup, use Apple’s App Store Connect API access guide. Keep the permissions required for the task narrow, and avoid rotating credentials or changing the CI host merely because an expected report is no longer produced. Those actions can add risk without addressing the actual cause.

If you need to review whether a persistent remote Mac fits the rest of your workload, the UDPMac guides cover remote Mac workflows, and the data center overview helps you assess location considerations. Neither changes the API’s report lifecycle; they are relevant only if your wider pipeline needs a managed macOS environment.

A practical decision rule for the next run

Use the following rule when the next scheduled download completes:

• If Apple’s current documentation says the requested new INSTALLS report is no longer generated, record not generated, stop retries for that expected outcome, and keep the dashboard value distinct from zero.
• If you are requesting a historical report, check the documented availability for that report and period, then diagnose request failures independently.
• If the request fails before a report outcome can be established, investigate credentials, permissions, network handling, and parsing as normal CI faults.
• If a stakeholder proposes a replacement metric, compare its definition and population with the original use case before presenting it as a continuation of the same series.

This decision rule avoids the two costly extremes: paging an engineer repeatedly for a report that will not be created, and suppressing a genuine failure by labeling every empty response “expected.” Keep an explicit status in logs and dashboards so the team can tell which condition occurred.

Choosing a host for ongoing report operations

The report API does not require a Mac simply because it concerns App Store Connect. If your downloader is a straightforward API client and your existing infrastructure handles scheduling, secrets, storage, and monitoring reliably, there may be no reason to move it to macOS.

A Mac environment becomes relevant when the same workflow depends on macOS-only tools, needs to share a host with Apple-platform build or release tasks, or must run alongside other macOS-specific automation. A self-managed physical Mac can provide direct control, but it ties the workflow to hardware you own and maintain. A non-Mac cloud host may be a sensible fit for API-only processing, but it cannot host native macOS tooling. A remote Mac can avoid a hardware purchase and keep a Mac environment available, but it still adds a host, access controls, and operating costs to your operations.

Choose based on the whole workload, not the INSTALLS change alone. If you are comparing those options, start with the UDPMac remote Mac overview and assess whether your scheduled work actually needs macOS. Renting is a reasonable option for temporary validation, a migration period, or a Mac-specific CI workload without an existing machine. If the task is a stable, heavy workload that needs dedicated physical access, buying and operating your own Mac may suit you better.

The key operational change is not a new API workaround. It is to preserve the history you can retrieve, represent unavailable reports honestly, and let the CI job distinguish an expected report lifecycle outcome from a real failure. App Store Connect API 4.6 does not make every empty response harmless; it makes correct classification more important.