Limitations

Apple enforces system budgets for Live Activities and widgets to preserve battery life and device performance. These limits are not officially documented in full and are dynamically adjusted based on factors such as battery level, thermal state, and Low Power Mode status.

Live Activities

The following thresholds have been identified from device logs. Note that these are estimates and may vary across iOS versions:

• Started activity limit: A budget of 10 started Live Activities within a rolling window. In testing, we’ve seen the budget replenish by 1 every 15 minutes (on a fully charged device), but expect this to vary.
• Updates per activity: Up to 240 high-priority updates per activity. Aivi currently sends all updates as high priority to ensure timely delivery.
• Content up to 4 KiB per push: Apple refuses a Live Activity push over 4096 bytes, and the activity’s name rides along when it starts. Text written in ASCII always fits; emoji and other non-Latin text take up to 4 bytes a character, so filling every field of a progress activity to its maximum length in them does not. An update whose content does not fit is rejected with a 422 (payload_too_large) and nothing is stored.

Widgets

Widgets are the persistent, best-effort layer, and iOS budgets them differently:

• Background delivery: Widget content pushes are delivered at background priority. iOS batches and defers them to save battery, so an update typically appears within minutes rather than seconds, occasionally longer in Low Power Mode or on a sleeping device. See the freshness model for what stays live on device between pushes.
• Reload budget: WidgetKit gives each widget a daily refresh budget: Apple’s guidance is roughly 40 to 70 reloads per day for a frequently viewed widget, further adjusted for battery and usage. Very frequent content pushes are throttled rather than displayed one by one, so design widgets around “latest known state”, not around a stream of updates.

Buttons and toggles

Presses on buttons and toggles travel from the phone through Aivi to your system, with limits of their own:

• Online only. A press needs a connection; nothing is queued for later.
• Short-lived events. A press expires 5 seconds after it happens. Aivi delivers nothing after that. A stream that resumes with Last-Event-ID gets only the events that haven’t expired yet, so a press nobody receives within 5 seconds is lost.
• Rate limits. Presses are limited per phone and per account. See Rate limit and duplicates.
• 15 seconds to confirm. A toggle shows the requested state for 15 seconds; if your update hasn’t arrived by then, it shows the state you last published with No response.
• One widget update every 2 seconds. Aivi sends each widget’s updates to phones at most once per 2 seconds, with the latest content.
• Running Live Activities only. A Live Activity takes presses while it is ONGOING, and every update that changes its content counts toward its update budget.
• 4 event streams per account, each closed by the server after 15 minutes.
• Webhooks reach only public HTTPS addresses on port 443, with 2 seconds per attempt. A second attempt comes only after a transient failure, and only if it fits before the event expires. Redirects are not followed.
• Pictures come later. Pictures are fetched on the phone, so a new one can take a while to appear, and one at an unchanged URL is refreshed about once a day. See Pictures for sizes.