I have opened the Push Notification and the Broadcast Capability at developer Capabilities, but when I call the api https://api-manage-broadcast.sandbox.push.apple.com:2195/1/apps/already change to my Identifiers/channels, I always got the "TopicMismatch".
Did I set something wrong somewhere?
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
We at Anywayanyday (Apple ID 424980622) utilize push notification technology for our users to enhance customer scenarios. Recently (after the launch of OS 18 update, end of September '24) we started to observe that our customers were not receiving notifications on devices with OS 18+.
In their systems we see that sending a message via transport has been done, but no notifications are reaching the client.
In the system it is visible that the device token is fresh and working.
Could you please tell us what steps we should take to fix the functionality of push notifications?
Thanks
Problem Statement
We are experiencing a critical and persistent issue preventing the successful signing and building of our iOS application. The core problem is that provisioning profiles, whether automatically generated by Xcode or manually created in the Apple Developer Portal, consistently fail to include the UIBackgroundModes entitlement, leading to a build failure.
Specific Question
Why are provisioning profiles generated via the Apple Developer Portal and/or Xcode's automatic signing process consistently omitting the UIBackgroundModes entitlement for our App ID, even when this capability is explicitly configured in Xcode? We seek guidance or backend intervention to ensure our provisioning profiles include the necessary entitlement.
Expected Outcome
We expect to be able to successfully build and sign our iOS application, with provisioning profiles that correctly include the UIBackgroundModes entitlement, allowing for proper implementation of remote notifications.
Observed Symptoms
Primary Build Error: Consistent build failure with the exact error message:
"Automatic signing failed: Provisioning profile 'iOS Team Provisioning Profile: com.scott.ultimatefix' doesn't include the UIBackgroundModes entitlement."
Missing Entitlement in Profile (Confirmed by Inspection): Direct inspection of downloaded .mobileprovision files (including those manually generated in the Developer Portal for com.scott.ultimatefix) consistently shows the absence of the UIBackgroundModes entry within the section of the Entitlements dictionary. The aps-environment key for Push Notifications is present, indicating Push Notifications are enabled, but Background Modes are not.
Certificates Correctly Recognized in Xcode: Our "Apple Development: Stephen Criscell Scott" and "Apple Distribution: Stephen Criscell Scott" certificates are correctly displayed and recognized in both Keychain Access and Xcode's Preferences > Accounts > Manage Certificates window (without "Not in Keychain" status). Furthermore, the Signing & Capabilities tab for the target in Xcode now correctly shows Signing Certificate: Apple Development: Stephen Criscell Scott.
Persistent Issue Across Resets: The problem persists despite extensive local cache invalidation, Xcode reinstallation, and even testing in a fresh macOS user account (which confirmed the issue was not user-specific).
I have a function in my app to detect if screens are added or removed, watching for notifications from NSApplication.didChangeScreenParametersNotification. I am seeing some strange behavior when the screen attached to a Mac mini is turned off, macOS will spit out hundreds of the didChangeScreenParametersNotification, all relating to a 'ghost' screen being added and then subsequently replaced with the original screen a second later. This cycle will go on for hours until the screen is turned back on again.
I can confirm this also happens with the CoreGraphics equivalent, with flags .added and .removed being the only changes. I would imagine this creates immense churn for all apps watching for screen changes.
I've tried debouncing the notifications but even with a delay of 10 seconds this is still being called hundreds of times while the computer is idle and the screen is off.
One constant I can see is that the CGDisplayUnitNumber() for the 'ghost' display is always 0, while the logical unit number for the real screen is '1'. Is it safe to ignore screens with 0? I'm trying to find a reliable way to prevent heavy processing for 'false' screens. I'm afraid because this ghost screen has parameters so different to the actual screen, it's otherwise not possible to ignore it as it looks like a new screen.
See example below:
// Observe notification
NotificationCenter.default.addObserver(self, selector: #selector(displaysDidChange), name: NSApplication.didChangeScreenParametersNotification, object: nil)
// Function to update screens called from displaysDidChange
func updateScreens() {
let screens = NSScreen.screens
for screen in screens {
guard let screenDisplayID = screen.displayID() else {
NSLog("Screen does not have a display ID: \(screen.localizedName)")
continue
}
let screenIdentifier = "v\(CGDisplayVendorNumber(screenDisplayID)), m\(CGDisplayModelNumber(screenDisplayID)), sn\(CGDisplaySerialNumber(screenDisplayID)), u\(CGDisplayUnitNumber(screenDisplayID)), sz\(CGDisplayScreenSize(screenDisplayID))"
}
// -- Logic to determine if screen is new or already exists for window management --
NSLog("Found new screen display ID \(screenDisplayID) (\(screenIdentifier)): \(screen.localizedName)")
}
And the logging I'll get:
Found new screen display ID 2 (v16652, m1219, sn16843009, u1, sz(1434.3529196346508, 806.823517294491)): Philips FTV
Found new screen display ID 10586 (v1970170734, m1986622068, sn0, u0, sz(677.3333231608074, 380.9999942779541)):
Topic:
App & System Services
SubTopic:
Notifications
Hi,
I'm working on an IOS app using capacitor. I'm trying to receive push notifications on my downloaded app from testflight. I tried with FCM and it's working on my android app but not on ios and the logs show no error.
This is how I retreive the FCM token:
const fcmToken = await FCM.getToken()
sendSubscriptionToBackEnd({
fcm_token: fcmToken.token,
device: platform
})
Then I have a job on my backend to send the push notifications:
def perform
fcm = FCM.new(
StringIO.new(Rails.application.credentials.google_application_credentials),
Rails.application.credentials.firebase_project_id
)
NotificationSubscription.find_each(batch_size: 100) do |subscription|
begin
response = fcm.send_v1({
token: subscription.fcm_token,
notification: {
title: 'Un nouveau signal a été publié',
body: 'Un nouveau signal a été publié, cliquez ici pour le voir'
},
android: {
priority: 'high'
},
apns: {
payload: {
aps: {
# alert: {
# title: 'Un nouveau signal a été publié',
# body: 'Un nouveau signal a été publié, cliquez ici pour le voir'
# },
sound: 'default'
}
},
headers: {
"apns-priority": "10",
"apns-push-type": "alert"
}
}
})
if response[:status_code] == 200
Rails.logger.info "Notification sent successfully to #{subscription.id} on device #{subscription.device}"
else
Rails.logger.error "Failed to send notification to #{subscription.id} body: #{response[:body]}"
# subscription.destroy
end
rescue StandardError => e
Rails.logger.error "Error while sending notification to #{subscription.device}: #{e.message}"
subscription.destroy
end
end
end
and the logs show that it's successful but i dont receive the notification. When I test from firebase console I receive the push notification on both ios and android capacitor apps. I also added this in the apple delegate:
Messaging.messaging().apnsToken = deviceToken
Messaging.messaging().token(completion: { (token, error) in
if let error = error {
NotificationCenter.default.post(name: .capacitorDidFailToRegisterForRemoteNotifications, object: error)
} else if let token = token {
NotificationCenter.default.post(name: .capacitorDidRegisterForRemoteNotifications, object: token)
}
})
}
func application(_ application: UIApplication, didFailToRegisterForRemoteNotificationsWithError error: Error) {
NotificationCenter.default.post(name: .capacitorDidFailToRegisterForRemoteNotifications, object: error)
}
I also tried using apns tokens and ther apnotic gem:
console.log('APNs Token:', token.value)
if (platform === 'ios') {
sendSubscriptionToBackEnd({
apns_token: token.value,
device: platform
}).then(() => {
displaySnackbar(`APNs token: ${token.value}`, 'success')
})
}
})
# Create the APNs connection outside the loop
connection = Apnotic::Connection.new(
auth_method: :token,
cert_path: StringIO.new(Rails.application.credentials.apns_key_path),
key_id: Rails.application.credentials.apn_key_id,
team_id: Rails.application.credentials.apple_team_id
)
NotificationSubscription.find_each(batch_size: 100) do |subscription|
if subscription.device == 'ios'
begin
# Create the notification for the current device token
notification = Apnotic::Notification.new(subscription.apns_token)
notification.alert = "Un nouveau signal a été publié"
notification.topic = Rails.application.credentials.apple_bundle_id
# Prepare and send the push
push = connection.prepare_push(notification)
push.on(:response) do |response|
if response.ok?
Rails.logger.info "Notification sent successfully to #{subscription.id} on device #{subscription.device}"
else
Rails.logger.error "Failed to send notification to #{subscription.id} body: #{response.status} - #{response.body}"
end
end
connection.push_async(push)
rescue StandardError => e
Rails.logger.error "Error while sending notification to #{subscription.device}: #{e.message}"
subscription.destroy
end
end
end
connection.join(timeout: 5)
connection.close
end
but i have a bad token error:
Failed to send notification to 223 body: 400 - {"reason"=>"BadDeviceToken"}
I, [2025-01-23T02:23:59.013407 #104] INFO -- : [ActiveJob] [ApnsNotificationJob]
I checked my aps entitlement env and its production, have all the certificates, keys.. so I dont understand why i can receive push notifications from firebase console but not from my app
With the relevantDate field deprecated for Apple passes as of 18.1 https://developer.apple.com/documentation/passkit_apple_pay_and_wallet/pkpass/1618776-relevantdate,
boarding pass notifications on the lock screen no longer seem to display the departure time. Is there a way to show this again?
Would semantic tags (Semantics.currentDepartureDate) or the new PkPass.releaseDates field help?
I'm working with a deeplink I have to implement to my app. The deeplink is working because in some cases i will explain later the method is being executed. So when I tap the deeplink with a deeplink-tester-web I detect if the url is which I want and, if it's the case, i post a notification to NotificationCenter with a string parameter I need.
Case 1. I tap the deeplink when the view controller with the addObserver method is at the background with the app itself. It works (the only case)
Case 2. The app is closed so the deeplink opens the app directly in that view controller (the method is no being called event if the notification is there) Why?
Case 3. The app is at the background but in another screen. When I tap the deeplink and, after returning to the app, travel to my viewController the method is not called when the ViewController becomes visible. Why?
I've not seen anything in the documentation that can help me and i cannot access to the array of observers because the API does not allow that
Thanks. Any help will be appreciate.
Code:
When the deeplink is tapped the app delegate method that manages universal links call to this code when the url is a specific one
@objc func handleRecommendedOffer(offerId: String) {
NotificationCenter.default.post(name: .deeplinkRecommendedOfferNotification, object: nil, userInfo: ["offerId": offerId])
}
In my viewcontroller viewDidLoad (i've tried also viewWillAppear too):
NotificationCenter.default.addObserver(self, selector: #selector(goToDetail(notification:)), name: .deeplinkRecommendedOfferNotification, object: nil)
@objc private func goToDetail(notification: Notification) {
if let userInfo = notification.userInfo, let offerId = userInfo["offerId"] as? String {
showLoading()
getOfferViewModel.getOfferDetail(id: offerId)
}
}
Topic:
App & System Services
SubTopic:
Notifications
We're experiencing an issue with Apple Push Notification service where APNs continues to return 200 OK responses for device tokens belonging to uninstalled applications.
Issue Details:
When sending push notifications to device tokens.
APNs returns 200 OK responses even for devices where our app was uninstalled more than a month ago
According to documentation(https://developer.apple.com/documentation/usernotifications/handling-notification-responses-from-apns), APNs should return 410 status code with JSON body for invalid tokens
Expected Behavior:
APNs should return 410 status code when device token is no longer valid (app uninstalled)
Thanks in advanced for support
User is using my app, the goes to System Settings, and changes some of my App's settings (switches, text fields, etc).
Does the system send my app any kind of notification?
David
PS: I tried all kinds of searches on this and found nothing.
Topic:
App & System Services
SubTopic:
Notifications
Recently, I attempted to use LiveCommunicationKit to replace CallKit. The goal was to explore better features or integration.
However, a major problem emerged. When the app is in the background or killed, it shows no notifications. This seriously impairs the app's communication functionality as notifications are vital for users to notice incoming calls.
And it is working well when the app is in the foreground.
When the app is in the background, when the push message received. the app get crashed with the following information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push.'
Also, when I use CallKit instead of LiveCommunicationKit, the app works well in all cases.
The code is here:
LCK wrapper:
class LCKWrapper : NSObject, ConversationManagerDelegate {
var mgr: ConversationManager
var lckDelegate: LCKDelegate
var currentCallId: UUID
@objc init(handler: LCKDelegate, appName: String, appIcon: UIImage) {
self.lckDelegate = handler
var iconData: Data?
iconData = appIcon.pngData();
var cfg: ConversationManager.Configuration
cfg = ConversationManager.Configuration(ringtoneName: "ringtone.m4a",
iconTemplateImageData: iconData,
maximumConversationGroups: 1,
maximumConversationsPerConversationGroup: 1,
includesConversationInRecents: false,
supportsVideo: false,
supportedHandleTypes: Set([Handle.Kind.phoneNumber]))
self.mgr = ConversationManager(configuration: cfg)
self.currentCallId = UUID()
super.init()
self.mgr.delegate = self
}
func reportIncomingCall(_ payload: [AnyHashable : Any], callerName: String) async {
do {
print("Prepare to report new incoming conversation")
self.currentCallId = UUID()
var update = Conversation.Update()
let removeNumber = Handle(type: .generic, value: callerName, displayName: callerName)
update.activeRemoteMembers = Set([removeNumber])
update.localMember = Handle(type: .generic, value: "", displayName: callerName);
update.capabilities = [ .playingTones ];
try await self.mgr.reportNewIncomingConversation(uuid: self.currentCallId, update: update)
print("report new incoming conversation Done")
} catch {
print("unknown error: \(error)")
}
}
}
And the PushKit wrapper:
@available(iOS 17.4, *)
@objc class PushKitWrapper : NSObject, PKPushRegistryDelegate {
var pushKitHandler: PuskKitDelegate
var lckHandler: LCKWrapper
@objc init(handler: PuskKitDelegate, lckWrapper: LCKWrapper) {
self.pushKitHandler = handler
self.lckHandler = lckWrapper
super.init()
let mainQueue = DispatchQueue.main
// Create a push registry object on the main queue
let voipRegistry = PKPushRegistry(queue: mainQueue)
// Set the registry's delegate to self
voipRegistry.delegate = self
// Set the push type to VoIP
voipRegistry.desiredPushTypes = [.voIP]
}
func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType) async {
if (type != .voIP) {
return;
}
await self.lckHandler.reportIncomingCall(payload.dictionaryPayload, callerName: "Tester")
}
}
I invoked the getNotificationSettingsWithCompletionHandler method of UNUserNotificationCenter on multiple test devices. After dismissing the notification permission request dialog (without explicit denial), the returned UNNotificationSettings object showed inconsistent authorizationStatus values across OS versions:
**iOS 18: Returns UNAuthorizationStatusNotDetermined
iOS 14.2:** Returns UNAuthorizationStatusDenied
Where can I find official Apple documentation explaining this behavioral discrepancy between system versions?
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!
I'm having trouble displaying the Apple Wallet pass logo on iOS 18 when a notification occurs. It works on iOS 17 but not on iOS 18 (tested on versions 18.1 and 18.3).
I ensured the Wallet pass icon sizes are correct:
icon.png → 29×29
icon@ 2x.png → 58×58
icon@ 3x.png → 87×87
Questions:
Has Apple changed any requirements for displaying Wallet pass logos in iOS 18?
Are there new size, format, or metadata constraints?
Hello, I would like to check with you on a possible APNS issue. We saw a huge spike in the number of failed requests towards APNS (both api.push.apple.com and api.development.push.apple.com). On October 31st, at 13:39 (during 1 or 2 minutes), more than 700k requests failed. Which means more than 10% of all requests made by our service to api.push.apple.com. Our service is sending notification requests for more applications, different AppIds, in high amounts.
Even more concerning is the fact that it happens more or less regularly now. 2-3 times a week. Still, just for short time, but I would like to check with APNS, whether it is something you know about.
Checking graphs in CloudKit did not help me much. They don't allow good enough granularity. Not more precise than 1 day.
Please, let me know if you are aware of some very short transient issues in APNS. Happening more or less regularly, with noticeable impact.
Topic:
App & System Services
SubTopic:
Notifications
Hi Everyone,
I noticed that applicationIconBadgeNumber has been deprecated in iOS17. While there's a new method to set the badge number using setBadgeCount(_:withCompletionHandler:), I couldn't find a way to retrieve the current value.
Previously we used to call UIApplication.shared.applicationIconBadgeNumber, to get the current value, which is deprecated now.
Does anyone know how to get the current badge count?
Thanks!
Topic:
App & System Services
SubTopic:
Notifications
I have an app that pairs with a wearable Bluetooth device that collects users' health data. My web backend sends two push notifications every hour to all app users—one at XX:05 and another at XX:15. The first notification instructs the app to download data from the paired wearable device, while the second prompts the app to upload the downloaded data to the backend server's database.
However, I’ve noticed that many push notifications are not processed by iOS apps, especially at night. Based on Apple's documentation, iOS prioritizes push notifications and may ignore lower-priority ones to conserve battery life.
Is there a way to increase the priority to ensure that more (or all) push notifications are processed?
Would integrating the HealthKit framework help? Currently, I use Firebase Cloud Messaging (FCM) to send push notifications. Additionally, my app falls under the Health & Fitness category. Would changing it to Medical increase priority? P.S. I understand that Apple requires certain certifications for an app to be classified as Medical.
Topic:
App & System Services
SubTopic:
Notifications
I am an iOS development engineer. Recently, I updated the Xcode version to 16.1 (16B40) and updated my debugging device (iPhone 15) to iOS 18.1.1. However, I found that I could not respond to the delegate method.
I confirmed that my code, certificate, Xcode settings, and network environment had not changed. Simply executing
application.registerForRemoteNotifications()
in
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool
did not receive a response(didRegisterForRemoteNotificationsWithDeviceToken or didFailToRegisterForRemoteNotificationsWithError ).
In the same environment, when I switched to another device for debugging (iOS 17.0.3), the delegate method would respond.
I really don't know what to do, I hope someone can help me, I would be very grateful.
Please note: Everything is normal when using devices before iOS 18.1.1 version
Good morning all!
We are facing a specific case dealing with push notifications to iOS devices.
In my scenario:
I turn off my device's internet
Send multiple push notifications via server using Firebase.
I turned ON my device's internet again.
I only see the last push notification I sent.
This is an expected scenario?
There is any documentation that supports this statement?
Thank you all!
Topic:
App & System Services
SubTopic:
Notifications
Tags:
App Store Server Notifications
Notification Center
User Notifications
APNS
I am developing a VoIP service.
Usually, when receiving a VoIP Push, Callkit is exposed immediately after receiving the message and the app is designed to be used.
However, there is an extremely intermittent phenomenon (not well reproduced) where the app does not wake up even when receiving a VoIP Push. And after a long time, the app wakes up and Callkit is activated. (A long time after receiving the call…)
Has anyone experienced the above phenomenon? I wonder if there are any reported parts depending on the OS version. (I have identified that it does not occur in the 17.x version, but it is difficult to guarantee because it occurs extremely intermittently)
The app is not running in the background, but... Could this be happening if there are a lot of pending operations in the background?
I need help urgently
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?