I want to add Live Activities to my e-commerce app to show the estimated delivery ETA when an order is out for delivery, with the Live Activity initiated from the server.
Issue 1: How can I consistently obtain a pushToStart token when a user logs in to my e-commerce app? Currently, I’m considering starting and ending a dummy Live Activity to retrieve the token. Is there a better way to trigger pushToStartTokenUpdates and send the token to my server?
Issue 2: How do I properly invalidate the pushToStart token when a user logs out, ensuring the next user doesn’t inherit the same token? Ideally, I don't want the user to wait until the token is automatically invalidated before logging out.
Notifications
RSS for tagLearn about the technical aspects of notification delivery on device, including notification types, priorities, and notification center management.
Post
Replies
Boosts
Views
Activity
I have been experiencing a consistent problem when connecting to a bluetooth device (Speaker, Vehicle, Etc.) where the music cuts-out every time I receive a notification or my Iphone screen turns on or off.
This never happened before the update. I have tried restarting, downgrading to previous IOS versions and reupdating to the latest.
No luck, unfortunately.
I thought this might be due to the devices, but this happens when playing music through my device as well. I have checked the notification settings and haven't found anything that fixes this problem.
Any assistance would be much appreciated.
We experienced an issue with delayed App Store Server notifications for an Auto-Renewable Subscription purchase in our app.
On September 27, 2024, at 22:28:28 GMT+0900, a user successfully purchased a Premium membership subscription (transaction ID: 190002223966278, webOrderLineItemId: 190001007274949).
However, our server did not receive the corresponding App Store notification for this transaction after purchase.
The App Store Server Notification was only received 66 minutes later, at 23:35:16 (transaction ID: 190002224000004, webOrderLineItemId: 190001007274949).
The delayed notification contained a different transaction ID than the initial purchase.
We would like to inquire about the cause of this delay and request assistance in understanding why the notification took 66 minutes to be delivered to our server, instead of arriving immediately after the transaction was completed.
Additionally, we would appreciate your guidance on how to prevent or mitigate such delays in the future, ensuring a seamless experience for our users.
Are there any best practices or recommended approaches we should implement to handle potential notification delays more effectively?
We have provided detailed information about the received notification and the related transactions in the Feedback Assistant (FB15330451).
Thank you for your assistance in resolving this matter.
Key Details
Purchase time: 2024-09-27T22:28:28 GMT+0900 (1727443708000)
Notification received: 2024-09-27T23:35:16 GMT+0900 (1727447716463)
Delay: 66 minutes and 48 seconds
Initial Purchase Transaction ID: 190002223966278
Initial Purchase Web Order Line Item ID: 190001007274949
Transaction ID in Delayed Notification: 190002224000004
Web Order Line Item ID in Delayed Notification: 190001007274949
Additional info
Bundle ID: com.reppley.ReppleyApp
SKU: com.reppley.ReppleyApp
Feedback Assistant Number: FB15330451
https://forums.developer.apple.com/forums/thread/685317
Having read the above discussion, I can add there’s one problematic exception on watchOS to the rule that .didBecomeActiveNotification is fired when the Control Center or any other overlay (such as a long-look notification) is dismissed. It’s when it’s dismissed not by the user, but just allowed to dsimiss itself after a period (as determined by Settings > Wake Duration).
This is a problem for any Watch workout app because when one of these overlays is covering the app, it’s considered by the system to be backgounded for purposes of applying the 15% avg CPU load over 60 seconds criteria for being terminated for using too much CPU in the background, so I have discovered.
In the case of these overlays covering an app, the app never gets a .didEnterBackgroundNotification call to know that it should attempt to reduce its activity, when the user presses the Side Button to show the Control Center, which is by design, as I understand it.
The app does get a .willResignActiveNotification when the Control Center covers it, but there is no corresponding .didBecomeActiveNotification when the system dismisses the Control Center after 2 minutes or so.
So if the app reduces its actvity in an attempt to reduce CPU load when covered by the Control Center overlay, it has no way to know it has become active again, in the special case of the Control Center timing out and being dismissed by the system.
What could be done to reduce the likelihood of the system terminating the app in this situation, and maintain the app's functionality and usability?
I previously posted a topic about receiving application(_:didReceiveRemoteNotification:fetchCompletionHandler:) callback when my app is not running, and the system starts the app in the background to respond to a notification.
While I receive the callback reliably, the work performed by the callback seems to have different restrictions whether the app is in the background or not running.
When the app is running in the background, the work started in this callback completes reliably (in my case it takes no more than a few seconds), and I can post the result back to the system via the completion handler.
When the app is not running and the system starts it in the background, the app starts the same work, but this work seems to be terminated quickly without being able to complete, and without me being able to call the completion handler passed to the callback. I’m not talking about 30 seconds - the termination seems to happen after less than a second, which is not enough for my app.
The nature of the work shouldn’t matter, but just in case: I start a Task in the callback for some asynchronous work, which stores the completion handler, and calls back to it when the work is finished. This happens completely reliably when the app is running in the background, and not at all reliably when the app is not running and is started by the system.
Why would application(_:didReceiveRemoteNotification:fetchCompletionHandler:) behave differently based on if it is ran when the app is already running, vs not running and started by the system?
Is there anything I can do on my side to make it more reliable?
We provide users with an iOS app that sends VoIP notifications.
However, we received issue from users that "VoIP notifications were not sent."
So we conducted an investigation on-site and sent VoIP notifications more than 10 times to about 20 devices.
We confirmed that most of the notifications arrived, but there were also times when the notifications were not sent.
We would like to know if the VoIP notifications were really delivered to the devices that did not receive the notifications.
If this phenomenon is a network problem, we would like to consult with the network company.
We have attached the log of when we checked and the VoIP notification was not received.
logs
[2024-09-12 11:50:02]
'ApnsId' => '22541A6E-355E-73D6-D28F-D1F8E340E540'
'StatusCode' => 200
[2024-09-12 11:50:02]
'ApnsId' => '22541A6E-355E-73D6-D28F-D1F8E340E540'
'StatusCode' => 200
[2024-09-12 11:50:02]
'ApnsId' => '2984C9F3-CC81-9080-7B54-EF53D2E77D68'
'StatusCode' => 200
[2024-09-12 12:43:01]
'ApnsId' => 'A936595B-36F7-07C2-CFB7-3276C4BE8FC8'
'StatusCode' => 200
[2024-09-12 12:43:01]
'ApnsId' => '0C633C08-25B0-6FE2-2087-DD66C1C01532'
'StatusCode' => 200
According to these, the status code is 200.
We would like to know if the VoIP notifications in the logs shown above were received by the iPhone device we tested.
To receive silent push notifications in the background, I need to include content-available payload into my APNS push notification, and have application(_:didReceiveRemoteNotification:fetchCompletionHandler:) implemented.
When I send a push notification, my app receives and handles it with the above method.
This works correctly and is straightforward to test when the app is running in foreground or background on my device.
I would like to test if my app is woken up correctly from scratch and does the above work. But how do I do this? How do I get my app into the state where it is started when it receives a silent push notification?
When the user force-kills the app, the notification is not delivered. This is also the case when I as a developer force-kill the app which I am testing. I assume it also applies when I force-stop the app running on my device from within Xcode.
Is there any way for me as a developer to terminate the app, which does not count as “force killing”, and would reliably start the app when it receives the background notification?
After a prolonged BLE connection, we have noticed that ANCS frequently pushes a large number of "remove" messages (event ID 0x02), after which the device no longer receives any notifications. Is this behavior a result of system design, or could it be a potential bug? I would appreciate any insights or experiences that others can share.
Hey everyone,
I work on an app with VoIP calls and essential notifications features, and I'm curious about the new locked/hidden apps functionality in iOS 18.
Specifically, does iOS 18 provide any way for developers to detect if a user has hidden their app from the home screen or app library? I want to notify users if they hide the app, core functionalities like VoiP calls and notifications might not work as expected. Furthermore, would critical alerts also be hidden from the notification center?
Any insight on whether Apple exposes this information to developers, or if there are indirect ways to detect hidden status, would be greatly appreciated!
Thanks in advance!
Hello,
When attempting to assign the UNNotificationResponse to a Published property on the main thread inside UNUserNotificationCenterDelegate's method
func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse) async
both Task { @MainActor in } and await MainActor.run are throwing a NSInternalInconsistencyException: 'Call must be made on main thread'.
I thought both of them were essentially doing the same thing, i.e. call their closure on the main thread. So why is this exception thrown? Is my understanding of the MainActor still incorrect, or is this a bug?
Thank you
Note: Task { await MainActor.run { ... } } and DispatchQueue.main.async don't throw any exception.
i’m on an iphone 15 pro max
18.1 beta. I have apple ai and no matter what i ask it i am unable to see the apple ai response as it is always blurred out?
if i click copy and paste into a text or notepad the answer shows up so the ai is working and answering my commands it just doesnt show on the screen…
if i put that i want the answers read to me it’ll read it but the response will still be blurred ?
please someone help
We noticed that push notifications stopped working on our end from 16th Sep'2024. We are calling these endpoints below. Can you please verify if these endpoints and ports are active, or if anything has changed?
gateway.push.apple.com:2195
feedback.push.apple.com:2196
Totally appreciate your help
Hi when setting the language to iOS 6 my app crashes on this piece of code:
func registerForPushNotifications() {
UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .sound, .badge]) { granted, error in
print("Permission granted: \(granted)")
guard granted else { return }
self.getNotificationSettings()
}
}
It has to do with the requestAuthorization
When I restart the app it crashes immediately. This is because I had already made a choice for this.
When I change the language back to swift 5 it works fine again.
Removing the self.getNotifcationSettings has nothing to do with it.
Also tried to add @MainActor to the function.
This is the tread where it crashes on:
Thread 7 Queue : com.apple.usernotifications.UNUserNotificationServiceConnection.call-out (serial)
Does anybody have a idea how to fix this?
What does APS stand for in APS Environment Entitlement?
I just switched back to Apple Watch from Garmin, and in the time away I got both work and personal vehicles with CarPlay. I've noticed that my AW10 does not get ANY notifications pushed to it while I am using CarPlay, which is annoying because only texts and calls get pushed to my CarPlay screen, so i miss everything else.
Additionally, and this may be a bug issue with iOS18, but I also just noticed that my phone (16) does not light up/make sounds for notifications while using CarPlay - so it doesn't light up, nor do the vehicle speakers make sound with IG/snapchat/etc notifications, and even the screen "lock" sound doesn't audibly go off. I've only had CarPlay for a few months, but I typically keep my phone on Silent anyway, so maybe I'm just noticing this now and its not necessarily a new issue? it does make the sound when i get a text, so logically everything else should make a noise.
I've made sure that my general focus and car focus modes are OFF. Sound is ON. Sound volume setting is all the way up. Have also restarted both phone and watch, and “forgot“ the phone from the vehicle and reconnected
Am I doing something wrong here? is there a solution for either problem? From what I've seen, some people say that the AW not getting notifications at the same time as Carplay is a built-in safety feature, which most people do not want... maybe its the same with the phone not alerting to non-text/call notifications?
I am developing a new App that uses Push Notifications. I completed the development of the App itself and I can send Push Notifications from the CloudKit and receive it on my phone.
My problem is sending the Push Notifications from our service API to Apple. If I use the production address gateway.push.apple.com, I can send messages, but they don't work for my new App because it is in development and not yet released. If I use the sandbox address api.sandbox.push.apple.com, I get the following exception:
System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it. [::ffff:17.188.143.98]:2195
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at System.Net.Sockets.Socket.Connect(IPAddress[] addresses, Int32 port)
--- End of stack trace from previous location ---
at System.Net.Sockets.Socket.Connect(IPAddress[] addresses, Int32 port)
at System.Net.Sockets.Socket.Connect(String host, Int32 port)
at System.Net.Sockets.TcpClient.Connect(String hostname, Int32 port)
at System.Net.Sockets.TcpClient..ctor(String hostname, Int32 port)
The service API for sending Push Notifications was developed in C# .NET 8.0.
Constants:
private readonly string _hostname = "api.sandbox.push.apple.com";
private readonly int _port = 2195;
The code for sending a message.
public async Task Send(string? subtitle, string? title, string message, string deviceId)
{
var payload =
"{ \"aps\": { " +
"\"alert\": { " +
"\"title\": \"" + title + "\", " +
"\"subtitle\": \"" + subtitle + "\", " +
"\"body\": \"" + message + "\"" +
"} " +
"} " +
"}";
try
{
Debug.WriteLine($"apple api request: {payload}");
using var client = new TcpClient(_hostname, _port);
var sslStream = new SslStream(client.GetStream(), false, new RemoteCertificateValidationCallback(ValidateServerCertificate));
var certificatesCollection = new X509Certificate2Collection(_certificate);
await sslStream.AuthenticateAsClientAsync(_hostname, certificatesCollection, SslProtocols.Tls12 | SslProtocols.Tls13, true);
var array = DataToBytes(deviceId, payload);
sslStream.Write(array);
sslStream.Flush();
client.Close();
}
catch(Exception exception)
{
Debug.WriteLine(exception);
}
}
The certificate that is used in this code was read beforehand:
var clientCertificate = new X509Certificate2(iOSApp.Certificate, iOSApp.CertificatePassword);
We are using a p12 certificate file with a private password.
Again, it works great for an App in Production but not at all for an App in Development. I made use that I use a new p12 developer certificate for the new App when I tested. I also tested with a p12 production certificate. I get the same error.
Any help is appreciated.
My Code
private let synthesizer = AVSpeechSynthesizer()
override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) {
self.contentHandler = contentHandler
bestAttemptContent = (request.content.mutableCopy() as? UNMutableNotificationContent)
do {
try AVAudioSession.sharedInstance().setCategory(AVAudioSession.Category.playback)
let utterance = AVSpeechUtterance(string: "Hello Sim")
utterance.voice = AVSpeechSynthesisVoice(language: "th_TH")
utterance.rate = 1.0
utterance.pitchMultiplier = 1.0
utterance.volume = 1.0
utterance.preUtteranceDelay = 0
self.synthesizer.usesApplicationAudioSession = false
self.synthesizer.speak(utterance)
} catch {
print(error.localizedDescription)
}
if let bestAttemptContent = self.bestAttemptContent {
contentHandler(bestAttemptContent)
}
}
Info.plist enable
UIBackgroundModes
audio
fetch
processing
remote-notification
payloadNotification
{
"aps":{
"alert":{
"title":"title"
"subtitle":"subtitle"
"body":"body"
}
"mutable-content":1
"content-available":1
"sound":"tester.caf"
}
}
This code can play in simulator but can't play in real device
Hello,
I am encountering an intermittent TopicDisallowed error while using APNs and would like to ask for your assistance.
Environment:
Authentication: We are using certificate-based authentication with APNs, where the PEM file is stored on the server to authenticate our requests.
API: We are using the HTTP/2 API and calling the /3/device/<device_token> endpoint while passing the apns-topic in the request header.
Issue:
After renewing our APNs certificate, the new certificate mistakenly included an incorrect app bundle ID, resulting in a TopicDisallowed error.
We then issued a new certificate with the correct bundle ID and replaced it on our server before resuming remote push requests.
However, even after replacing the certificate, we are still intermittently receiving the TopicDisallowed error, while other requests successfully return a 200 OK response and deliver notifications to devices.
Over time, the frequency of TopicDisallowed responses has been decreasing, leading us to speculate that APNs might be caching responses and updating this cache over time.
Questions:
Could you provide details on the specific conditions or causes that lead to a TopicDisallowed error?
After replacing the certificate, is there a reason why we might still be intermittently receiving this error? Are there additional certificate or configuration settings we should check?
What might cause some requests to succeed with a 200 OK response, while others result in a TopicDisallowed error with the same setup?
Is it possible that APNs could be caching outdated information from the previous certificate, which might explain the decreasing frequency of the errors?
We have reviewed our certificate and configuration after the renewal, but the issue persists. Any guidance on how to further troubleshoot or resolve this would be greatly appreciated.
Thank you.
PLATFORM AND VERSION
iOS
Development environment: Xcode 15.4, macOS 14.5
Run-time configuration: iOS 17.5.1
DESCRIPTION OF PROBLEM
We use PushKit to push offline messages of Voip, and use Voip notifications to bind with CallKit to implement Voip call functions.
During the test, we found that when the app is in the background or the screen is locked, Voip messages cannot reach the device stably. After several consecutive calls, the phone will not be able to receive new messages for a period of time. Only after the App is uninstalled and reinstalled can it continue to receive messages.
STEPS TO REPRODUCE
1: Open the app and log in successfully
2: Push the app to the background, kill it or lock the screen
3: Use another user to make a voip call to this device
4: Repeated calls
I have set up server notification in my app.
I have set up only production server URL and through that URL I can check "CONSUMPTION_REQUEST", "REFUND" notificationType.
However, I want to check all notifications for in-app purchases.
For example, "ONE_TIME_CHARGE" which is consumable in-app purchase type.
If I want to check more notificationTypes on my server,
Do I need to add another setting?
Test notifications are also checked in my server.
https://api.storekit.itunes.apple.com/inApps/v1/notifications/test