Introduction

On iOS, the reliable way to update an app badge while the app is in the background is to send the badge value in the APNs payload. The system applies that badge without needing your app to be foregrounded. If you depend on background code in the app to calculate the badge, delivery becomes less reliable.

The Important Distinction

There are two different models people mix together:

1. APNs updates the badge directly from the push payload
2. the app wakes in the background and computes a badge itself

The first model is the normal solution. The second is conditional and should not be your primary badge strategy.

If you want the icon badge to show 7, your server should usually send 7, not "increment by one." APNs badge updates are absolute values, which keeps devices in sync better than trying to do local arithmetic.

Request Badge Permission

Your app must request notification authorization that includes badge access.

1import UserNotifications
2
3UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .sound, .badge]) { granted, error in
4    if let error = error {
5        print("Authorization error: \(error)")
6        return
7    }
8
9    print("Granted: \(granted)")
10}

Without badge authorization, the push may arrive but the badge change will not be allowed.

Send the Badge in the Push Payload

Your provider sets the badge number in the aps payload.

1{
2  "aps": {
3    "alert": {
4      "title": "New message",
5      "body": "You have unread updates"
6    },
7    "badge": 7,
8    "sound": "default"
9  }
10}

If this notification is delivered while the app is in the background, iOS can update the icon badge directly. Your app code does not need to run just to set that number.

Why Server-Side Badge Calculation Is Better

Imagine a user has multiple devices or clears notifications on one device but not another. If each client increments its own badge locally, counts drift easily.

A better pattern is:

1. server tracks the authoritative unread count
2. each push includes the full desired badge value
3. app clears or refreshes badge state after the user reads the content

This avoids race conditions and duplicate increments.

What About Silent Push

A silent push using content-available can wake the app in the background and let it fetch new data, but it is not guaranteed to run immediately or every time. System conditions, power state, and delivery policy affect it.

So if your requirement is "the badge must update while the app is in the background," do not depend solely on background execution. Put the badge value in the notification payload whenever possible.

Clearing or Resetting the Badge

When the user has viewed the relevant content, reset the badge to the correct value, often zero.

import UIKit

UIApplication.shared.applicationIconBadgeNumber = 0

Some apps do this on launch. Others do it after the user visits an inbox or messages screen. The right behavior depends on product semantics, but the important thing is that badge state stays consistent with real unread state.

Common Pitfalls

The most common mistake is trying to increment the badge on the device instead of sending the absolute badge value from the server. That leads to drift across devices.

Another mistake is assuming a silent push will always wake the app and let it compute the badge. Background execution is not guaranteed enough for that to be the only plan.

A third pitfall is forgetting to request badge authorization as part of notification permissions.

Summary

• To update the badge while the app is in the background, send the badge number in the APNs payload.
• Request notification authorization with the .badge option.
• Treat badge values as absolute counts, not client-side increments.
• Use silent pushes for background refresh only when needed, not as the core badge mechanism.
• Keep server state and badge state aligned so the count remains trustworthy.