Documentation on APNS Live Activity Broadcast API throttle limit

Thanks for the interesting post. I actually have more questions than answers to find out if you are talking about push notifications rates and what limits are you getting. Do you have any logs to show the numbers you are hitting?

While those limit are not publish the exact broadcast limit, for standard Live Activities, the guideline is generally no more than one update per second per activity. If you exceed this for a single channel, APNs will drop or throttle requests for that specific channel I believe.

The limits are dynamic and calculated based on several factors. The system is designed to scale automatically, and developers are expected to handle limits programmatically by optimizing their connection architecture.

If you are broadcasting updates for multiple games at the exact same time, you might be bottlenecking a single connection.

Upon receiving a 429 response, parse the JSON response body. APNs typically includes a reason key, which in your case is, I believe, TooManyRequests. Maintain a log of these requests with a count to monitor your usage and ensure you do not exceed the limits. Additionally, keep logs for your push and update tokens, and utilize broadcast as much as possible. Optimize your processes and maintain logs of all relevant limits.

Hope this helps, but you can't request an increase of the API rate limit.

Albert
  Worldwide Developer Relations.

Yes, I have logs showing that we are indeed getting TooManyRequests. This is specifically for the live activity broadcast API and not for the push notification. We have concurrent games happening around the same time and i believe we do not send more than one update per channel per second.

Is there a recommendation on number of open connection and keep-alive settings for APNS broadcast?

I will get more details on the rate limit that we are seeing on our end.

Here is some more data regarding the throttling grouped by hour:

---
| day | hour | ThrottleCount |
| --- | --- | --- |
| 2026-05-27 00:00:00.000 | 2026-05-27 03:00:00.000 | 1 |
| 2026-05-27 00:00:00.000 | 2026-05-27 02:00:00.000 | 25 |
| 2026-05-27 00:00:00.000 | 2026-05-27 01:00:00.000 | 16 |
| 2026-05-25 00:00:00.000 | 2026-05-25 02:00:00.000 | 26 |
| 2026-05-25 00:00:00.000 | 2026-05-25 01:00:00.000 | 3 |
| 2026-05-25 00:00:00.000 | 2026-05-25 00:00:00.000 | 3 |
---

Thanks for the post. What do you mean on open connections? Open channels? Open Live Activities?

APNs expects you to maintain persistent connections rather than opening and closing them per request.

Using your words depending what is a connection, are you relying on a single connection? Because establishing a TLS connection to APNs is computationally expensive, you want to keep your pooled connections alive as long as possible. Are you creating multiple channels or reusing the channels?

Albert
  Worldwide Developer Relations.

I mean TLS connection with APNS. We have multiple connection with keep-alive set to 10 mins. Reg channels, we have one channel per game. We are doing max 8-9 updates per min per channel occasionally (game clock plus score updates).

Based on the logs and metrics, it seems that the effective rate might be 4 updates per min per channel. Can you confirm if the rate limiting is per channel or overall at API level per app bundle id?

@pnimit

I cannot provide a definitive confirmation, as the situation may change in the future. We only have recommendations I provided in my initial post. Therefore, my primary recommendation is to always create a test harness to identify the limits and then adhere to those limits that have been tested.

I always like to create test apps for different frameworks Live Activities / ActivityKit and APNs should all have different limitations you should explore fully.

Rate limiting applied per Live Activity instance The system dynamically throttles updates to preserve battery and system performance.

The APNs server itself doesn't typically hard-limit but the receiving device's OS heavily throttles silent background updates based on a dynamic budget.

I’m glad you found a budget and you can make sure your code stays under that limit so the solution works well.

Albert
  Worldwide Developer Relations.

Thanks for looking into this.

I understand your concern but some general guidance in public documentation will help us design solutions while keeping this limit in mind.

the guideline is generally no more than one update per second per activity.

This does not seem right based on my experience.

Rate limiting applied per Live Activity instance

Good to know that it is per channel. I have not seen many concurrent channel updates at this time so not sure about this.

The APNs server itself doesn't typically hard-limit but the receiving device's OS heavily throttles silent background updates based on a dynamic budget.

My concern is more on the server API side than on the device throttling which is something that is not in our control.

does sandbox and production environment have the same rate limits per channel or do they vary? This will help me determine if sandbox load testing is sufficient.

After some testing, I can confirm that APNS broadcast throttling has been zero if I keep my updates up to 4 per min. Hopefully, this is helpful to someone running into a similar issue.

However, now I see another issue where a device sometimes does not get channel updates. I can confirm that battery looks good and allow frequent updates is enabled so wonder what might be causing the device to drop updates?

@pnimit Ok, let's reset the conversation so we can get to the bottom of the issue, why do you think we are getting throttled. Can you looks at the sysdiagnose about the error message, how many push notifications are you sending? What is the error message? Let's start there.

Albert  WWDR

The broadcast push has already been discussed above so no need to revisit this. The question now is what can cause a message to get dropped from device side? I was on wifi and i see sometimes the updates stops even though I can see that it was successfully sent to APNS from logs.