Silent Push — Essence, Background Tasks and Delivery Configuration

What is Silent Push — Essence and Purpose

Silent Push is an iOS mechanism that delivers data to the device without any visual notification to the user. Unlike a standard push that shows a banner, plays a sound, and appears in Notification Center, a silent push “wakes” the app in the background and passes data to it for processing. The user never knows about the delivery of such a notification — the result is updated content the next time they open the app.

Difference from Regular Push Notifications

The key difference lies in the JSON payload: a silent push contains the content-available: 1 flag and does NOT contain alert, sound, or badge. A standard notification with alert is always displayed to the user, regardless of content-available. Silent push only works with content-available: 1 and without alert — if you add alert, the system will display the notification even with the background delivery flag.

When to Use Silent Push

Silent notifications are indispensable for scenarios where data needs to be fresh by the time the user opens the app, but the user should not be distracted. Examples: updating a news feed in the background, synchronizing subscriptions, downloading new content for offline access, updating widgets, cache invalidation. Silent Push is also used for “warming up” the app before an expected user action.

How Silent Notification Delivery Works

Silent Push delivery differs significantly from regular notifications and follows power optimization rules. The iOS system receives a push request from APNS, determines it is a silent push (content-available: 1), and decides whether to deliver it based on multiple factors: battery level, power saving mode, frequency of previous silent pushes, app activity, and current CPU load.

The Role of Power Nap and Background Modes

On devices with Apple M chip and iOS 15+, silent push integrates with the Power Nap mechanism, which periodically wakes the device for background tasks. Power Nap consolidates multiple silent pushes into one activity period, reducing overall power consumption. The developer cannot control Power Nap directly — the system makes decisions automatically based on user behavior and app usage history.

The 30-Second Processing Window

When the system delivers a silent push, the app receives a call to application(_:didReceiveRemoteNotification:fetchCompletionHandler:) in AppDelegate. The developer must call the completion handler within 30 seconds, passing the correct result (UIBackgroundFetchResult). If processing does not complete in time, the system may limit the frequency of silent pushes for this app or stop delivering them altogether.

// Silent Push handling in AppDelegate
func application(
    _ application: UIApplication,
    didReceiveRemoteNotification userInfo: [AnyHashable: Any],
    fetchCompletionHandler completionHandler:
    @escaping (UIBackgroundFetchResult) -> Void
) {
    guard let type = userInfo["sync-type"] as? String
    else {
        completionHandler(.failed)
        return
    }

    if type == "news-feed" {
        NewsFeedSyncService().sync { success in
            completionHandler(success ? .newData : .failed)
        }
    } else if type == "cache-invalidate" {
        CacheManager.shared.invalidateAll()
        completionHandler(.newData)
    } else {
        completionHandler(.noData)
    }
}

Intervals Between Deliveries

Apple does not publish exact intervals between silent pushes, but based on tests and documentation, it is recommended to send no more than 2–3 silent notifications per hour per device. If sent more frequently, the system begins to ignore silent pushes, and data stops being delivered. If more frequent synchronization is required, consider using URLSession with a background configuration or VoIP push.

Silent Push Use Cases

Silent Push is used in a wide range of tasks where data needs to be up-to-date without active user participation. Let’s look at the most effective use cases for this mechanism in real iOS applications.

Content Updates for Offline Access

News apps, readers, and travel applications use Silent Push to download new content in the background. When the user opens the app, the data is already loaded and available even without an internet connection. This approach dramatically improves the user experience — empty loading screens disappear, and content displays instantly. The server sends a silent push when new articles appear, and the app downloads them in the background for offline reading.

Widget State Synchronization

iOS WidgetKit updates widgets on a schedule, but for instant updates after server-side data changes, Silent Push is used. The app in the background processes the silent push, updates the local data store for widgets, and forcibly refreshes the timeline via WidgetCenter. The user sees up-to-date information on the widget without opening the app — exchange rates, weather forecasts, delivery status.

Cache Invalidation and Stale Data Cleanup

When the server updates critical data (e.g., pricing rules, available features for premium users), Silent Push allows instant cache invalidation. On the next open, the app will load fresh data from the server instead of using stale cached data. This is especially relevant for apps with paid content or subscriptions.

Badge Update Without Visible Notification

In some scenarios, the badge on the app icon needs to be updated without showing a notification. A Silent Push with the badge field in the payload allows setting the desired counter value without disturbing the user with a banner. For example, a chat app can update the badge with the number of unread messages without showing each new message as a notification if the user is already in the app.

Silent Push Configuration: Payload and Capabilities

Proper Silent Push operation requires configuration at three levels: the Xcode project, the JSON payload on the server, and the processing code in the app. Each level is critical: skipping any step will result in the notification being delivered as a regular one or not delivered at all.

Configuring Capabilities in Xcode

In Xcode, you need to enable the Push Notifications capability and Background Modes with the Remote notifications checkbox checked. Push Notifications generates a certificate for APNS, while Remote notifications in Background Modes allows the system to wake the app when a silent push is received. Without Remote notifications, the silent push will be delivered, but the app will not activate in the background, and the data will not be processed.

JSON Payload Structure

A Silent Push payload must contain the aps key with content-available: 1 and must NOT contain alert, sound, or badge. Custom fields are passed at the same level as aps and contain data for processing: operation type, object identifiers, metadata. A payload without content-available will be treated as a regular notification; with alert, it will be regular even with content-available.

{
    "aps": {
        "content-available": 1
    },
    "sync-type": "news-feed",
    "last-article-id": "article_8521",
    "priority": "high"
}

Client-Side Processing

When receiving a silent push, iOS calls application(_:didReceiveRemoteNotification:fetchCompletionHandler:) before the app becomes visible. In this method, you need to analyze userInfo, perform the necessary work (network requests, Core Data writes, cache updates), and always call the completionHandler with the correct result within 30 seconds. Not calling the completionHandler is considered an error by the system and affects the frequency of future silent pushes.

Limitations and Best Practices

Silent Push is not a reliable data delivery channel for critical operations — it is an optimization mechanism, not guaranteed synchronization. The developer must understand the limitations and design the system so that the app works correctly both with and without silent push.

Delivery Limitations

iOS does not guarantee delivery of every silent push. The system may delay or cancel delivery when the battery is low (below 20%), in Low Power Mode, after frequent previous silent pushes, or if the app has not been used for a long time. Average delivery statistics according to Apple: about 70–80% of silent pushes are delivered within 5 minutes, the rest may be delayed or lost.

Apple Recommendations for Silent Push

Apple recommends following several rules for effective silent push usage. Do not send more than 2–3 silent pushes per hour per device — exceeding the limit results in blocking. Use a compact payload: minimal payload size speeds up processing and reduces network load. Always call the completionHandler as quickly as possible: the longer processing takes, the higher the chance that the system will restrict silent pushes in the future.

Alternatives to Silent Push

For scenarios requiring guaranteed delivery or more processing time, consider alternatives. VoIP push (PushKit) guarantees delivery and provides more time but is intended only for VoIP applications. Background fetch (UIApplication background fetch) is launched by the system on a schedule but cannot be initiated by the server. WebSocket maintains a persistent connection but drains more battery and is not suitable for all app types.

Monitoring and Debugging

To debug Silent Push, use Console.app on Mac and filter by the app name. The system logs each silent push with a “background task” label and indicates whether processing was successful. On a device, check via Settings → Developer → Background Modes Logging. Server-side tracking is done through the APNS Feedback Service to identify undelivered notifications.