Hello everyone,
I'm implementing the "Push to Start" feature for Live Activities, and I've run into an issue where the activity seems to be processed by the system but never appears on the Lock Screen or in the Dynamic Island.
I suspect there's a silent crash happening in my widget extension immediately after launch, but I'm unable to capture any logs or crash reports in the Xcode debugger.
Here is the flow and all the relevant data:
1. The Process
My app successfully requests a pushToStartToken using Activity<EJourneyLiveActivityAttributes>.pushToStartTokenUpdates
The token is sent to our server.
The server uses this token to send a "start" event APNs push notification.
The device console logs (from liveactivitiesd) show that the push is received and the system is "Publishing event".
Expected Result: The Live Activity UI appears on the device.
Actual Result: Nothing appears. The UI is completely absent.
2. Device Console Logs
Here are the logs from the device console, which indicate a successful receipt of the push:
pushServer default 12:08:22.716353+0200 liveactivitiesd Received push event for com.wavepointer.ejourney.staging::pushToStart
pushServer default 12:08:22.716818+0200 liveactivitiesd Reduced budget for com.wavepointer.ejourney.staging::pushToStart to: 7
pushServer default 12:08:22.723458+0200 liveactivitiesd Publishing event: timestamp: 2025-07-24 08:57:19 +0000; activityIdentifier: 53C3EE9D-623C-4F38-93AE-8BB807429DAA; eventType: start(...)
3. APNs Payload
This is the exact payload being sent from our server:
{
"aps": {
"event": "start",
"timestamp": 1753347375,
"attributes-type": "EJourneyLiveActivityAttributes",
"attributes": {
"journeyId": "test123453"
},
"content-state": {
"distanceInMeters": 1000,
"depTime": 1752745104,
"arrTime": 1752748704,
"depStop": "Arth, Am See",
"arrStop": "Oberarth, Bifang",
"depZone": "571",
"arrZone": "566",
"co2Save": 5.0,
"co2SavePerc": 44,
"companyName": "WP Innovation",
"countryCode": "CH",
"categoryId": 5,
"subcategoryId": 3,
"stationStartAssoc": "Assoc1",
"stationEndAssoc": "Assoc2"
}
}
}
4. ActivityAttributes Struct
To prevent decoding errors, I have made all properties in my ContentState optional and added a custom decoder.
@available(iOS 16.1, *)
struct EJourneyLiveActivityAttributes: ActivityAttributes, Hashable {
public struct ContentState: Codable, Hashable {
var distanceInMeters: Int = 0
var depTime: Int = 1752843769
var arrTime: Int = 1752843769
var depStop: String = ""
var arrStop: String = ""
var depZone: String = ""
var arrZone: String = ""
var co2Save: Double?
var co2SavePerc: Int = 0
var companyName: String = "Test"
var countryCode: String = "CH"
var categoryId: Int = 3
var subcategoryId: Int = 4
var stationStartAssoc: String?
var stationEndAssoc: String?
}
var journeyId: String?
}
What I've Tried
I have carefully checked that my Codable struct matches the JSON payload. I've made all properties optional to avoid crashes from missing keys.
I have tried attaching the Xcode debugger to the widget extension process (Debug -> Attach to Process...) before sending the push, but no logs, errors, or crash reports appear in the Xcode console. The process seems to terminate before it can log anything.
My question is: What could cause the widget extension to fail so early that it doesn't even produce a crash log in the attached debugger? Are there other methods to debug this kind of silent failure?
Any help would be greatly appreciated. Thank you!
Notifications
RSS for tagLearn about the technical aspects of notification delivery on device, including notification types, priorities, and notification center management.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
iOS app crashes on launch after updating and adding push notifications, but no crash logs are received; however, it works fine after restart. What could be the reason?
launch failed, RBSProcessExitContext voluntary
self.pushRegistry = [[PKPushRegistry alloc] initWithQueue:dispatch_get_main_queue()];
self.pushRegistry.delegate = self;
self.pushRegistry.desiredPushTypes = [NSSet setWithObject:PKPushTypeVoIP];
//处理接收到的VoIP推送
(void)pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type withCompletionHandler:(void(^)(void))completion
then we send message from our server or from apple's cloud service: https://icloud.developer.apple.com/dashboard/notifications website services:
when app is in foreground,withCompletionHandler wil be called correctly,but when app is in background or has killed ,withCompletionHandler not be called!!!
the background fetch、voice over ip is checked in signing & capabilities tabs
why?why?why?why?why?why?why?why?why?
Hello everyone,
I’m an iOS developer working on a real-time communication app that supports VoIP calls using CallKit. The app has been in production for more than 5 years.
Over the years, some users have occasionally reported that they do not receive incoming call pushes. We have tried multiple optimizations on both the client and server side, but the improvement has been limited.
From Apple documentation and discussions online, I understand that iOS may restrict VoIP pushes if the system detects violations of VoIP push usage rules (for example, not presenting a CallKit call after receiving a VoIP push). However, the exact rules and thresholds for these violations are not clearly documented, so I’d like to ask a few questions to better understand the expected behavior.
Below is a simplified description of our current call flow.
Call Flow
Caller
When the user initiates a call:
We do not use CallKit
The call is handled entirely using a custom in-app call UI
Callee
When the user receives a call:
Device locked or app in background
A VoIP push wakes the app
The app presents the CallKit incoming call UI
App in foreground
The server still sends a VoIP push
The app first reports the call to CallKit
After a very short delay, the app programmatically ends the CallKit call
Then a custom in-app call UI is presented via the app's long connection
The reason we always send a VoIP push (even when the app is in the foreground) is that we want to maximize call delivery reliability.
We have been experimenting with silent notifications to update the content in our app and connected bluetooth peripheral at regular intervals. We are facing issues every once in a while with some users not receiving the notifications reliably even if the app is in the background and not killed.
Is there a way we can ensure we reliably receive notifications every time without any issues? If there is no guaranteed delivery with silent notifications, then is there any other way that we can explore to achieve our use case?
Notification coordination between iOS and watchOS is not working properly
watchOS and iOS try to coordinate between phone and watch notifications.
The concept here is that if there is a main app and a companion app, they could both be sending a notification, then the notification would alert on both, which is a deviation from how notification mirroring is handled if there is an iOS app but no watch app.
The watch waits for the iOS notification to fire so they can determine if this is the same notification that needs to be deduped, displayed on one device but not the other, or separate notifications to be displayed both.
If there is no notification on the phone, the watch will timeout after 13 seconds and alert anyway.
If you have an iOS companion app, the best solution to this is to send the same notification on both devices simultaneously, and ensuring the UNNotificationRequest.identifier matches on both notifications. This will let the systems determine how to handle the notification correctly and quickly, and the notification will alert right away.
https://developer.apple.com/forums/thread/765669
According to the above article, "when a notification arrives on watchOS alone first, it coordinates with iOS," but in reality, it doesn't work properly.
Detailed process of this phenomenon
watchOS receives a notification.
On watchOS, the notification is not immediately shown to the user.
iOS receives a notification with the same UNNotificationRequest.identifier as in (1).
The notification in (3) does not appear on either iOS or watchOS. However, the notification from (3) does appear in iOS Notification Center.
Thirteen seconds after watchOS received the notification, the notification from (1) is shown to the user on watchOS.
In the end, the iOS and watchOS notifications are not consolidated and each remains in its respective notification center.
Up to (3) there are no issues. Starting with (4), both iOS and watchOS exhibit a lot of odd behavior.
This phenomenon occurs with both local notifications and push notifications.
When iOS receives the notification first, there is no problem. The notification for watch received later is processed appropriately, and the watchOS notification is not additionally displayed to the user.
Expected proper process
Same as above.
Same as above.
Same as above.
The notification in (1) is integrated into the notification in (3).
The notification in (3) is alerted to the user immediately.
2 sample projects to reproduce
Only the main code is attached.
Sample project1: local notifications
Swift code for local notification app (iOS, watchOS) - App.swift.txt
Sample project2: push notifications
This sample project is implemented using Firebase Functions and Firebase Cloud Messaging.
Swift code push notification app (iOS, watchOS) - App.swift.txt
Server side JavaScript code for FirebaseFunction - index.js.txt
Tested devices and OS
This phenomenon occurred in both of the following patterns.
Pattern 1
Xcode 26.0
iPhone 16 (iOS 26.0)
Apple Watch series 10 (watchOS 26.0)
Pattern 2
Xcode 16.4
iPhone 11 (iOS 18.6)
Apple Watch SE 2nd gen (watchOS 11.6)
Question
Is this phenomenon a bug?
Or is my understanding or implementation incorrect?
Feedback Assistant number
FB20339772
Im creating a basic app, needs push notification capability. I have created two profiles (development & distribution), selected my app in Identifiers and checked the PN box to enable it (no need for broadcast). I add the profile to Xcode and it says "Provisioning profile "New VP App Jan 2026" doesn't include the Push Notifications capability."
What am I missing?
Topic:
App & System Services
SubTopic:
Notifications
Hello guys,
i need a little help. Im building an alarm clock app, pretty good one, and i have my own sounds i want to use as the alarm ring but notifications on apple cant work when the phone is turned off or the device is in silent mode (Or at least thats how i understand it) unless they have this feature called critical alerts that lets you have notifications even when the phone is turned off or silented. Without this, the phone can do just one beep and only when you open the notification, then it starts ringing but how is this supposed to wake you up? Alarmy has this worked out fine and i cant figure out how, maybe someone here knows. Im thinking maybe they have the critical alerts enabled but then i dont know why Apple would approve theirs and not mine. I tried to submit for the critical alerts feature but apple didn’t approve it saying the app is not the use case and im kinda lost. The whole app could be ruined because of this. So my question is. is there any way how i can use my custom sounds as a notifications on ios even if the phone is turned off or in silent mode+turned off and the app is not straight up running without being approved for critical alerts? Somehow like alarmy does it but i dont know if they have the critical alerts or not.
Thank you very much for any kind of help 🙏. For everyone whos reading this, take care!
Topic:
App & System Services
SubTopic:
Notifications
Hello,
I recently had an unusual experience, and I’m wondering if this is related to Apple’s policies, so I wanted to ask.
While a call is in Picture-in-Picture (PIP) mode, notification pushes from the same app do not appear.
The API is being triggered, but the notification banner does not show on the device.
Once PIP is closed, the notifications start appearing normally again.
Is this behavior enforced by Apple’s policies?
What’s interesting is that banners from other apps do appear — only the banners from the app currently in PIP are not shown.
In the app we are developing, we update the device token upon app launch using didRegisterForRemoteNotificationsWithDeviceToken. Previously, after an iOS major update, if the app was left without being launched, users experienced an issue where notifications would not be received. Later, we confirmed that running didRegisterForRemoteNotificationsWithDeviceToken during app launch updates the device token and restores the ability to receive notifications.
Therefore, we believe that the device token may change due to an iOS major update. We want to understand the detailed conditions under which the device token is updated due to an iOS update:
Does the same issue occur after iOS minor updates as well?
Does it always happen during iOS major updates?
We reviewed the official documentation, but there was no detailed description of the device token update conditions. Additionally, we contacted Apple, but received no clear answers. If anyone has experienced the same situation, we would appreciate any information you can share.
Topic:
App & System Services
SubTopic:
Notifications
Tags:
APNS
Notification Center
User Notifications
Hi, We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on: • iPhone 16 Pro — iOS 26 • iPhone 14 — iOS 26 • iPad Pro 11” (M4) — iOS 18.6.2 • iPhone 16 Plus — iOS 18.5
After restarting these devices, the push notification icon is refreshed and displays the new version correctly.
Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart?
Thank you.
Hi,
We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on:
• iPhone 16 Pro — iOS 26
• iPhone 14 — iOS 26
• iPad Pro 11” (M4) — iOS 18.6.2
• iPhone 16 Plus — iOS 18.5
After restarting these devices, the push notification icon is refreshed and displays the new version correctly.
Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart?
Thank you.
Topic:
App & System Services
SubTopic:
Notifications
Tags:
APNS
Developer Tools
iOS
User Notifications
Hi all,
I’m running into an issue with provisioning profiles not including the com.apple.developer.push-notifications entitlement — even though everything seems to be configured correctly.
Here's what I’ve done:
Checked the App ID has Push Notifications enabled.
I’ve clicked “Configure” and created a Production APNs certificate under the App ID.
I’ve regenerated the provisioning profiles (Ad Hoc and App Store).
I can see within the profiles within App Store Connect that the push notifications capability is listed
I’ve downloaded and decoded the profiles using:
security cms -D -i profile.mobileprovision > decoded.plist
But com.apple.developer.push-notifications is still missing under the <key>Entitlements</key> block.
This is causing issues because:
When I submit the build to eas I receive this error from XCode:
- Provisioning profile "*** Adhoc" doesn't include the com.apple.developer.push-notifications entitlement. Profile qualification is using entitlement definitions that may be out of date. Connect to network to update. (in target '***' from project '***')
Refer to "Xcode Logs" below for additional, more detailed logs.
To isolate the issue further I:
Created a completely new App ID, enabling Push Notifications from the start.
Created new APNs certificate.
Generated new provisioning profiles with a valid distribution certificate.
Still no push entitlement embedded in the profile.
Question:
Has anyone else encountered this issue where Push Notifications are enabled and configured, but the entitlement still fails to embed in the profile?
Thanks in advance.
In the main app, is there a way to distinguish whether the application:didFinishLaunchingWithOptions: method is triggered by the user manually clicking the app icon, or whether it is automatically triggered by the system after Live Activities receives a remote message notification?
Having some discussion about when we should clear out a token from our servers.
Docs say:
Don’t retry notification responses with the error code BadDeviceToken, DeviceTokenNotForTopic, Forbidden, ExpiredToken, Unregistered, or PayloadTooLarge. You can retry with a delay, if you get the error code TooManyRequests.
The way I see it is that with the exception of PayloadTooLarge, all other errors means you should remove the token from your server. Either because:
The token is no longer good
The token is good, but this is just not the right:
environment (sandbox vs production)
topic (the token is from a different bundle id or developer team)
target (app vs live activity appex)
Do I have it right?
Extra context: when using the "JSON Web Token Validator" tool, a colleague reported that a 410 -Expired token (from couple days back) was still valid today. This raises questions about when tokens should actually be deleted and how these error codes should be interpreted.
Also is it possible for the docs to get updated for us to explicitly know if a token should get removed and not leave it for interpretation?
I need to create a background notification that counts down time and uses buttons to add or subtract time. Currently, I'm developing in React Native and using Expo Go to develop my app.
I managed to display a simple notification, but I can't get it to work in real-time, so that when the time is up, it emits a sound indicating that the break is over.
How can I implement this feature?
My application now:
My goal:
After updating to iOS 26 beta 1, I can't receive any push notifications from most applications.
I can receive notifications from like Calendar, which uses local & reserved notifications, but I can't receive any remote-based notifications.
Topic:
App & System Services
SubTopic:
Notifications
We are in the process of preparing our app to support the new Texas law (SB2420) that takes effect 1/1/2026.
After reviewing Apple's recent announcements/docs concerning this subject, one thing isn't clear to me: how to associate an app install with an App Store Server RESCIND_CONSENT notification that could be delivered to our server.
Our app is totally free so there isn't an originalTransactionId or other similar transaction IDs that would be generated as part of an in-app purchase (and then subsequently sent as part of the payload in the notification to our server during an in-app purchase scenario).
So my question is: How do I associate an app (free app) install with an App Store Server RESCIND_CONSENT notification that is sent to our server?
Topic:
App & System Services
SubTopic:
Notifications
Tags:
App Store Server Notifications
Declared Age Range
We have a customer reporting that they didn’t receive some of their push notifications. On November 3, 2025, four push notifications were sent — the customer received the first three but not the last one. Our logs show a successful response from APNs, with the apns-id c116d650-efc6-4fb1-8a74-382d5bab4692.
A very similar case occurred on October 31, where the customer also claimed not to have received the notification, yet our logs again show success from APNs with apns-id 1468ef43-66d6-40d2-b10a-c96889fcb65a.
Wondering if there any way to help us to trace these cases.
Thanks
Push message on the lock-screen disappears in one specific instance.
In general the situation is as follows:
the application, upon starting up, sets the badge counter (i.e. notificationCenter.setBadgeCount(3))
the application is being sent to background
the screen is locked (it doesn't matter if it's turned on or not)
send a push message to the application and set the badge (in aps) to "0"
What happens:
the screen lights up (unless it's lit up already), the push is being displayed for a very short time and gets hidden.
Happens on iOS 18.1, 18.1.1, 18.2. If not setting badge in the aps keys it works correctly.
I've created a feedback report https://feedbackassistant.apple.com/feedback/16095572. I am able to reproduce the issue on a sample app 100% of the time :/