Users complain that push notifications arrive without an image — the server sent it, but the device shows nothing. Or in an e2e messenger, "New message" appears instead of the text due to encryption. Standard push handling is not enough. The solution is a Notification Service Extension. We create this Extension end-to-end: from target setup to testing on real devices.
What problems does Notification Service Extension solve?
Media attachments. The server sends an image URL, and the Extension downloads it via URLSession, saves it to a temporary directory, creates a UNNotificationAttachment, and passes it through contentHandler. Without this, attachments won't work in push notifications — the user sees only text. Download time is limited to 30 seconds, so we configure the URLSession timeout to 20 seconds with a fallback: if not in time, we show the notification without an image, we don't fail the Extension.
End-to-end encryption. The payload arrives encrypted, the Extension decrypts it with a key from the Keychain and substitutes the readable text. In e2e messengers, this is the only way to show the notification content without exposing keys on the server. For key sharing, we use App Groups and Keychain Sharing with a common access group.
Delivery analytics. The Extension sends a fire-and-forget request to the backend upon receiving the notification — recording a delivered event. UIApplicationDelegate.userNotificationCenter(_:didReceive:) fires only on tap, while the Extension fires immediately on delivery. This gives accurate metrics.
How to implement end-to-end encryption in Notification Service Extension?
The decryption process consists of several steps:
- Get the encrypted payload from
request.content.userInfo. - Extract the key from the shared Keychain (configure Keychain Sharing with the main app).
- Perform decryption (e.g., AES-GCM) and form the readable notification body.
- Pass the modified content via
contentHandler.
This approach is safer than server-side decryption: the key never leaves the device. We use this method in messengers with end-to-end encryption, where the server has no access to message content.
How we implement the Extension: an example with media attachment
Here is a typical code for handling:
override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) { self.contentHandler = contentHandler bestAttemptContent = (request.content.mutableCopy() as? UNMutableNotificationContent) // download attachment, on error -> contentHandler(bestAttemptContent!) } override func serviceExtensionTimeWillExpire() { // called just before timeout — show what we have if let contentHandler, let content = bestAttemptContent { contentHandler(content) } } The Extension lives in a separate process and has no direct access to the main app's data. For exchange, we use App Groups: UserDefaults(suiteName: "group.com.example.app") and FileManager with the group container. Keychain Sharing is configured via kSecAttrAccessGroup with the same group identifier.
Why the Extension doesn't work in the simulator and what to do about it
APNs push notifications are not delivered to the simulator. For testing, use a real device or simulate local notifications via Xcode. We ensure correct operation on physical devices after configuring provisioning profiles and entitlements.
Scenario comparison: time and complexity table
| Scenario | Implementation time | Complexity |
|---|---|---|
| Media attachment | 1 day | Low |
| Payload decryption | 2 days | Medium |
| Delivery analytics | 1 day | Low |
| Combined (3+ logics) | 3–4 days | High |
Checklist of typical mistakes when setting up Notification Service Extension
Click to expand the list
- Forgot to add the App Groups capability to the Extension target.
- Did not configure the provisioning profile for the Extension (separate App ID).
- Use the simulator for push testing — notifications don't arrive.
- Did not set a URLSession timeout — the Extension may crash with an error.
- Keychain Sharing doesn't work without a common access group with the main app.
Approach comparison: media attachment via Notification Service Extension vs. server-side generation
| Approach | Delivery delay | Traffic usage | Flexibility |
|---|---|---|---|
| Extension downloads media | 0.5–2 sec download | Traffic only on device | Any size and format |
| Server generates push with media | No delay | Double traffic (server→APNs→device) | Limited to 10 MB |
Notification Service Extension is better if you need to display large images or video — saves up to 40% traffic compared to server-side generation.
What's included in the work
- Creation and configuration of the Notification Service Extension target in Xcode
- Implementation of logic: attachment, decryption, or analytics
- Configuration of App Groups and Keychain Sharing for data exchange
- Testing on a real device (Extension doesn't work in simulator for APNs push)
- Preparation of entitlements and provisioning profiles for the Extension target
Timeline and cost
Timeline: from 1 day (single scenario) to 3–4 days (comprehensive solution). Cost is calculated individually — contact us for your project evaluation. Order the Extension implementation and get quality assurance: our engineers have extensive experience in iOS development and Apple certification. Write to us — we'll propose the optimal solution.
Apple Developer Documentation — UNNotificationServiceExtension contains the full API specification.