We have implemented Carplay in our voip based project and in this we have implemented Incoming call and chat notification feature for Carplay. For Carplay we implemented siri. Siri Object donated Successfully in Notification service Extension when notification didreceive method called. Donation Code :- func donateIncomingMessageIntent(sender: String, senderId: String, message: String, messageId: String, userInfo: [AnyHashable: Any],destination:String) { // Create proper name components clearAllinteraction() var nameComponents = PersonNameComponents() nameComponents.givenName = sender //unknown let senderPerson = INPerson( personHandle: INPersonHandle(value: senderId, type: .unknown), nameComponents: nameComponents, displayName: sender, image: nil, contactIdentifier: senderId, customIdentifier: "sender_\(senderId)" ) let recipientPerson = INPerson( personHandle: INPersonHandle(value: "me@example.com", type: .emailAddress), nameComponents: nil, displayName: "Me", image: nil, contactIdentifier: "me_id", customIdentifier: "user_id" ) let inMessage = INMessage( identifier: messageId, conversationIdentifier: "conversation_\(senderId)", content: message, dateSent: Date(), sender: senderPerson, recipients: [recipientPerson], groupName: nil, messageType: .text ) let intent = INSearchForMessagesIntent( recipients: [recipientPerson], senders: [senderPerson], searchTerms: [message], attributes: .unread, dateTime: nil, identifiers: [messageId], notificationIdentifiers: [messageId], groupNames: ["Messages"] ) let interaction = INInteraction(intent: intent, response: nil) interaction.identifier = "message_\(messageId)" interaction.direction = .incoming // Add direction DispatchQueue.global(qos: .userInitiated).async { interaction.donate { error in if let error = error { print("❌ Failed to donate INSearchForMessagesIntent: \(error.localizedDescription)") } else { print("✅ Donated INSearchForMessagesIntent successfully!") let intentData: [String: Any] = [ "senderName": sender, "senderId": senderId, "message": message, "messageId": messageId, "timestamp": Date().timeIntervalSince1970, "conversationId": "conversation_\(senderId)", // Add conversationId "destination":destination ] let defaults = UserDefaults(suiteName: "group.com.chatapp") // 🔁 Use your App Group ID defaults?.removeObject(forKey: "lastCarPlayIntentData") defaults?.set(intentData, forKey: "lastCarPlayIntentData") defaults?.synchronize() } } } } Here SenderID is like 3000@abc,2000@abc etc. In siri ,When we handle INSearchForMessagesIntent at that time all data getting from Userdefaults because without Userdefaults INSearchForMessagesIntent value nil. Even we enabled announcement using .allowAnnouncement. We also tried to save same sender in contact Book because sometime siri search contact and not found then may be raise this type of issue. So we need code level support for read incoming message in carplay when notification comes. Thank you.

I’m building a firefighter app that needs to automatically check in a firefighter when they arrive at the station and check them out when they leave — even if the app is killed. We need reliable enter/exit detection, low latency, and only one fixed location per user. We’re evaluating Region Monitoring, which works in the killed state but may introduce delays and inconsistent accuracy. To ensure mission-critical reliability, we are considering the Location Push Service Extension, since it can fetch precise location on demand and wake the extension even when the app is terminated. Before requesting the restricted entitlement, we need clarification on Apple’s expectations: Is Region Monitoring recommended for this fixed-location use case? Would Apple consider approving the Location Push Service Extension for a public-safety workflow? What prerequisites do we need before submitting the entitlement request (Always permission, prototype, privacy disclosures, etc.)? What details should be included in the justification form? Our goal is to follow the most reliable and Apple-approved approach for firefighter check-in/out. Any guidance would be greatly appreciated.

You are probably aware of the upcoming root certificate change for any servers you might have that you use to send push notifications by connection to APNs. If you are not, here is the announcement. We have been getting some questions about this, and understand not everyone is familiar with their server setup. First, we would like to clarify that this is only a change to your server's certificate trust store. You do not need to update anything else, like your APNs push certificates, the build certificates and provisioning profiles for your team/app, and so on. All you need to do is to install the mentioned new root certificate to your push server's trust store. If you are using a 3rd party push provider, it is them who will need to handle their servers. But you may want to double check with them nevertheless. If you are managing your own push servers that connect to APNs directly, then it is your responsibility to download and install the root certificate mentioned in the above link on your server(s). Unfortunately we cannot provide specific instructions on how to install this root certificate on every kind of server out there. Each server operating system/push server software will have different ways these root certificates are installed, which is out of scope of our support abilities. If you are not sure how to do this, I would recommend you seek help for this from your server-side developers or server admins. Or, if you don't have access to such resources, you can ask the support channels for your system the question: How do I install a root certificate? We have setup a test server at 17.188.143.34:443 that you can use to try and send pushes to test whether your new root certificate is correctly installed. An alternative way to test this would be, from a terminal prompt: openssl s_client -connect 17.188.143.34:443 -servername api.sandbox.push.apple.com -verifyCAfile USERTrustRSACertificationAuthority.crt -showcerts Change the parameter to the -verifyCAfile argument to point to your trust store, and it should allow you to validate Sample return results would be: Connecting to 17.188.143.34 CONNECTED(00000003) depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority verify return:1 depth=1 CN=Apple Public Server RSA CA 11 - G1, O=Apple Inc., ST=California, C=US verify return:1 depth=0 C=US, ST=California, O=Apple Inc., CN=api.sandbox.push.apple.com verify return:1 Argun Tekant /  DTS Engineer / Core Technologies

sending the following POST request: ---- HTTP REQUEST ---- POST https://appleid.apple.com/auth/token Headers: Content-Type: application/x-www-form-urlencoded Body: client_id=au.com.thejlrguy.businesschat&client_secret=eyJhbGciOiJFUzI1NiIsImtpZCI6IktLUDc4MkhGVTcifQ.eyJ...QeDn7ug&grant_type=client_credentials&scope=https%3A%2F%2Fappleid.apple.com Getting the below error: {"error":"invalid_client"} The private key used to sign the JWT was created 24 hours ago.

I have converted a large part of the data, but only 5% of the data was successfully converted. The failed devicetoken shows "bad devicetoken" when accessing APNS. Here are examples of failed conversions devicetoken. Is there any official documentation for this part? DeviceToken Orgin \xc2\xa1\xcb\x9cr\xc3\x81\xe2\x80\x9e\x01b\xc3\xbce1pf\t\xc2\xa7\xc3\x82v}\xc3\xa1\xc3\x9a:?\r\n\xc3\xa5\xc6\x92\xc3\xb7y\xc3\x9e\xe2\x80\x9c\xc3\x89r

Good day We developed a simple swift code to make the device ringing when a certain type of notifications arrives from our backend. This is the code: let phoneNumber = CXHandle(type: .generic, value: (self.userInfoForPluginCall!["data"] as! [String:Any]) ["caller"] as! String) callUpdate.remoteHandle = phoneNumber let configuration = CXProviderConfiguration(localizedName: "Trec Conf") configuration.maximumCallGroups = 1 configuration.maximumCallsPerCallGroup = 1 configuration.supportsVideo = false configuration.supportedHandleTypes = [.generic] configuration.iconTemplateImageData = UIImage(named: "callkit-icon")?.pngData() let callProvider = CXProvider(configuration: configuration) callProvider.setDelegate(self, queue: nil) callProvider.reportNewIncomingCall(with: callUUID!, update: callUpdate, completion: {error in}) We are noticing some problems on the call screen: on certain devices (iOS 18.4RC) the normal call screen appears and the user can answer or decline the call, on other devices (iOS 18.3, especially with dynamic island) only a phone icon appears in the upper right corner and no possibility to answer or deny call. Any idea on why we are encountering that behavior? Thanks

Howdy, I'm trying to figure out how to replicate the following behavior for our app: The system is able to ascertain that the Mac equivalent of some iOS app is installed locally, and it prevents notifications from being mirrored. However, I am unable to determine how this association is inferred. When I check our iOS app under this prefpane, the switch remains enabled and toggleable—we'd like to act like Slack here. My initial assumption is that an app group containing both the Mac and iOS apps can be used to create the association; however, I would like to confirm that this is indeed the case before doing so. I'm not terribly confident about this. Details: The bundle identifiers of both apps do not match. This also applies to Slack; its iOS app is com.tinyspeck.chatlyio while its Mac app is com.tinyspeck.slackmacgap. In our case, the iOS app's identifier is like com.company.app while the Mac app's identifier is com.company.app.desktop. Both apps are signed with certificates that have matching team identifiers. The com.apple.developer.team-identifier entitlement is present on the Mac app. The Mac app shares a keychain access group with the iOS app. The Mac app is not sandboxed. The Mac app is an Electron app. The Mac app does not use APNs. It sends notifications "locally". I currently only have the iOS app installed on my iPhone via TestFlight, if that matters. Notification mirroring does work, but we'd like to forcibly disable this by associating the apps together. To my knowledge, the iOS app makes use of both a UNNotificationServiceExtension and a UNNotificationContentExtension. The iOS app currently doesn't have an assigned category (at least in Xcode). The Mac app is currently miscategorized as a developer tool (LSApplicationCategoryType = "public.app-category.developer-tools";), but that should be fixed. (Redacted) bundle information for the Mac app: CFBundleDisplayName = App; CFBundleExecutable = "App Desktop"; CFBundleName = App; Note that our CFBundleExecutable differs from the bundle's display name/name because we're currently migrating our users to a new version of the app that they'd likely want to live alongside the new one. The filename of the bundle itself is, similarly, App Desktop.app. For the iOS app, to my knowledge, the CFBundleName and CFBundleDisplayName are App.

I noticed the time sensitive entitlement says it's only for iOS and macOS. But without the entitlement, the time sensitive toggle doesn't show in my app's notification settings on visionOS. When I archive my visionOS app for App Store Connect, the entitlement seems to be taken out as it doesn't show in my entitlement list for the build in App Store Connect. I'm confused at this point if the entitlement is really necessary, since it seems to be needed to debug on the simulator at least. I don't have a physical device to test it on unfortunately.

I’m building a standalone Apple Watch smart alarm app that should trigger alarms on the watch in response to Bluetooth or internet events. This means the app operates in the background and attempts to trigger an alarm when such an event occurs. As far as I know, the appropriate API for this is WKExtendedRuntimeSession.notifyUserWithHaptic:repeatHandler. However, I can’t seem to start an extended runtime session while the app is in the background. I’m getting the following error: -[WKExtendedRuntimeSession _invalidationReasonAndDelegateCallbackErrorForError:outCallbackError:]:729: WKExtendedRuntimeSession hit internal error. Error Domain=com.apple.CarouselServices.SessionErrorDomain Code=17 "startSession cannot be called on a scheduled session" UserInfo={NSLocalizedDescription=startSession cannot be called on a scheduled session} Calling notifyUserWithHaptic directly also similarly fails. It seems notifyUserWithHaptic is intended to be scheduled during a foreground session to trigger at a later time, rather than being called ad hoc from a background context. Is there any way to create a proper alarm view on the Apple Watch from a background execution context?

@App Store Commerce Engineer hi, have you already implement something for handle server notification if user buy non consumable purchases product, how my server should know if user boutght something ?

Hi Team, We are building oru subscrption app and want to rely on server side purchase / subscription related notifications. We went through https://developer.apple.com/documentation/appstoreservernotifications/enabling-app-store-server-notifications We wanted to understand the reliability and latency for server side notifciations provided by Appstore.

Here are some questions we received and answers: Q1: Is there a limit to the number of alarms that can be scheduled using AlarmKit? There is no set number as a limit, but this does not mean you can schedule a limitless number of alarms. Depending on device state, available resources, etc., the device may impose a limit, and restrict an app trying to schedule too many alarms simultaneously. When you hit a limit and not able to schedule more alarms, you will receive the maximumLimitReached error. Q2: Will the scheduled alarms persist after system or app events that may terminate an app, for example, a reboot, force quit, or app crash? Yes, all alarms are expected to persist regardless of app or device state changes, once they are successfully scheduled. Q3: Will alarms work if scheduled by an app that is hidden, or requires a passcode or Touch ID/Face ID to launch? Hidden or passcode required apps do not work with AlarmKit. Currently, any scheduled alarms by such apps will silently fail. Q4: When an alarm is dismissed (either by swiping or pressing the power button), can an app detect this action and execute code in response? What about force closed apps? When an alarm is dismissed, the stopIntent set in the AlarmConfiguration is called. Any code in the perform method of this AppIntent would execute. Q5: Is there a focus mode that AlarmKit cannot break through? No. AlarmKit alarms can break through all focus modes. Q6: What is the expected behavior when alarms from multiple apps overlap? Which one gets priority? Which alarm would get activated when multiple alarms are scheduled for the same time is non-deterministic. There is no way to guarantee which app or which alarm will "win". Q7: What do pressing the physical buttons do when an AlarmKit alarm is active? Any physical button that causes a reaction from AlarmKit will stop the currently alerting alarm. Q8: If there are multiple alarms active at one time, which ones do physical buttons interact with? Pressing a physical button will dismiss all currently alerting alarms Argun Tekant /  DTS Engineer / Core Technologies Change History: 2025-08-15: First posted

We integrated App Store Server notification, to get notified about CONSUMPTION_REQUESTS and REFUND notifications. In the data, we noticed same transactionId have multiple REFUND decisions, usually REFUND_DECLINED and then REFUND. Why is that? Did user contact customer support ? For the second (or later) REFUND decision, CONSUMPTION_REQUEST notifications are usually not sent, but thats not always the case. Sometimes, REFUND decision are the same. Sometimes, we get even 3 or more REFUND related notifications for same transactionId, e.g: 2024-12-02: REFUND_DECLINED 2024-12-05: REFUND_DECLINED 2024-12-12: REFUND Do user request refund again ? Do they contact customer support ? But I can not explain why sometimes status it REFUND at first, but then later REFUND_DECLINED. Thank you already in advance:)

Hello, I am developing a calling service using CallKit and VOIP push. I have occasionally encountered a strange issue. The issue is that VOIP permanently fails to receive calls. I was previously informed that even if the device is blocked, it can receive calls again after 24 hours. Also, when I checked the device logic, it complied with the policy requirements set by Apple, including correctly calling CallKit's reportNewIncomingCall method. Once the issue occurs, no matter how many times I try, VOIP does not receive calls, and neither a device reboot nor checking the Device Console Log shows any logs related to CallKit or VOIP. I suspect this might be an issue with the VOIP token, and I believe that the only way to get a new one is to reinstall the app. Is that correct? Of course, after reinstalling, it works fine again, but this is very inconvenient. I don't think this is the right solution. Is there anyone who can share their insights on this issue? Thank you.

Hi everyone, I recently migrated my individual Apple Developer account to an Organization account for my company "". My Team ID remained the same. I'm now facing persistent issues with code signing and push notifications for my iOS app (Bundle ID: com.).
 Current Problems:
 "Untitled" Certificates in Xcode: When I go to Xcode -> Settings -> Accounts -> [My Apple ID] -> Select "" Team -> "Manage Certificates...", a number of my newly created Apple Development and Apple Distribution certificates are listed древ "Untitled". Some older ones are "Revoked". (See attached screenshot if possible).
 "No App ID" for Push Notifications Console: In my app target's "Signing & Capabilities" tab, I've added the "Push Notifications" capability. However, when I click the info button to open the "Push Notifications Console", it states: "no app IDs: Register an App ID with the Push Notifications capability enabled to use the Push Notifications console." This is despite the fact that the Push Notifications capability IS enabled for my App ID com. in the Developer Portal, and I've configured an APNs Auth Key (.p8) for it.
 Push Notifications Not Received (from Backend): While I can successfully send a test push notification directly from the Firebase Console to my device's FCM token, notifications triggered by my backend (Firebase Cloud Functions writing to a Firestore collection, which then triggers another function to send via FCM) are not being delivered to iOS devices. (Android seems to be working more reliably now).
 Setup: Using an APNs Authentication Key (.p8) linked to my Organization Team ID in Firebase Cloud Messaging. Main App ID com. has "Push Notifications" capability enabled. Notification Service Extension com..ImageNotification also has its App ID and Provisioning Profile set up for the Organization team. Created new Development and Distribution certificates and Provisioning Profiles specifically for the Organization team. Using "Automatically manage signing" in Xcode with the Organization team selected for both the main app target and the extension target.
 Troubleshooting Done: Revoked old/problematic certificates and profiles. Recreated CSRs and new Development/Distribution certificates under the Organization team multiple times. Recreated Provisioning Profiles. Cleaned Derived Data in Xcode. Ensured Bundle Identifiers are consistent. Verified APNs Auth Key details (Key ID, Team ID) in Firebase.
 I suspect there's a fundamental issue with how Xcode is recognizing or linking the signing assets for my Organization team after the account type change, despite the Team ID being the same. The "Untitled" certificates are a major red flag.
 Has anyone encountered similar issues, particularly the "Untitled" certificates or the "No App ID" message for the Push Console, after an account migration or when working with Organization accounts? Any insights on how to resolve this would be greatly appreciated.
 Thanks,
Benni

Hi, We are using Firebase to configure APNs (Apple Push Notification Service) for sending push notifications. During local testing, the push notifications are received properly when the app is in the foreground or background. After TestFlight testing and passing review, we found that when the app is installed using the developer's Apple ID, push notifications are received correctly whether the app is in the foreground or background. However, when the app is provided to other testers (using non-developer Apple IDs), notifications are only received when the app is in the foreground, and they are not triggered when the app is in the background or inactive state. Request for Assistance: Why, after TestFlight testing and passing review, does the app receive push notifications properly in the background when installed using the developer's Apple ID, but on other testers' devices, notifications are not received when the app is in the background? Are there any differences in Apple ID types or device configurations (developer ID vs. regular tester ID) that could affect the behavior of push notifications in the background mode? Do we need to apply any additional settings or permissions, particularly for handling background push notifications? Are there any iOS version or device-specific limitations that could impact the proper delivery of background push notifications? Additional Information: The app is properly configured for APNs, and push notifications are being sent via Firebase. In the developer's Apple ID test environment, the app receives push notifications properly whether it is in the foreground or background. On other testers' devices, push notifications are only received when the app is in the foreground, and they are not received when the app is in the background. All test devices have been verified to have notification permissions enabled, and Firebase configuration is correct.

Hi Apple team and fellow developers, We previously had Location Push Service Extension enabled and working in production. After transferring the app to a new Apple Developer team, the production App ID was transferred, but the Location Push entitlement was not retained. We've also created a new App ID for development, and now need Location Push access enabled for both the transferred production ID and the new development ID. We’ve already submitted the Location Push Access form with all relevant details. Unfortunately, the App Transfer documentation didn’t make it clear that Location Push access would be lost, and now we’re blocked from making new builds — even for the existing production app. ❓ Questions: Is it possible to re-enable Location Push for a transferred App ID? What’s the expected timeline for entitlement approval? Can Apple staff confirm the request status or let us know if any further action is needed? Thanks in advance — this entitlement is critical for our app’s functionality and release pipeline. Best, Aidar

Is there a public method to know when an APNS has appeared on the screen? wrapping up a very high end photogrammetry app, using the front facing camera and screen illumination- incoming notifications completely throw off the math. Ideally, it would be great to turn on Do Not Disturb for the short process, but we’d settle for just the detection of the notification banner. also: extra credit - programattically adjusting Auto Dimming, and True Tone would be lovely too.

Hey there my application allows users to have video calls with each other using Agora. I have successfully set up incoming call functionality on Android but on iOS I am struggling to get the call ui to appear when the app is not running/in background/locked. To my knowledge this is because there is much stricter security on iOS which is limiting me from calling this. When i initially set it up it worked at first when the app was in the background but I think I was failing to report the call to call kit in time and now it's not working. I'm not sure if I need access to this entitlement: com.apple.developer.pushkit.unrestricted-voip Which i believe is only for the big boys or if I make sure I'm reporting the call to call kit fast enough that I won't encounter this issue and it will consistently work in the background.

We are observing unexpected behavior in Apple Push Notification Service (APNS) delivery and would appreciate clarification and guidance. Below is a detailed breakdown of the scenario and related questions. Abbreviations: APNP – Apple Push Notification Provider APNS – Apple Push Notification Service Scenario: User1 is registered on iOS device1. Flight Mode is enabled on iOS device1. User2 initiates a call to User1 (Time t = 0 sec). User2 cancels the outgoing call after 5 seconds (Time t = 5 sec). Flight Mode is disabled on iOS device1 after 20 seconds (Time t = 25 sec). Observation: iOS device1 displays an incoming call notification (CallKit UI) after flight mode is turned off, despite the call being cancelled by User2. This notification disappears automatically after approximately 8–10 seconds. Logic Flow: At time t = 0, our APNP sends a VoIP push (priority) to APNS for the incoming call. Since device1 is in flight mode, APNS cannot deliver the push. At t = 25 sec, after flight mode is turned off, APNS delivers the cached VoIP push to device1. The app takes ~5 seconds to initialize (CSDK setup, SIP registration, etc.). It eventually receives a SIP NOTIFY with state="full" and empty dialog info (indicating no active call). Consequently, the CallKit incoming call is removed after ~8 seconds. Questions: → We set the apns-expiration header to 0, expecting that the VoIP push would not be delivered if the device was unreachable when the push was sent. However, APNS still delivers the push 20–30 seconds later, once the device is back online. Q. Why is the apns-expiration header not respected in this case? → Upon receiving the VoIP push, we require ~10–12 seconds to determine if a visible CallKit notification is still relevant (e.g., by completing SIP registration and checking for active dialogs). Q. Is it acceptable, per Apple guidelines, to intentionally delay showing the CallKit UI (incoming call) for 10–15 seconds after receiving the VoIP push? → Apple documentation states that the priority VoIP push channel should be used only for notifying incoming calls, while regular (non-VoIP) pushes should be used for other updates, including call cancellations. Q. What is the rationale behind discouraging the use of the priority VoIP push channel for call cancellation events? In some cases, immediate cancellation notification is as critical as the initial incoming call. Would Apple consider it acceptable to occasionally use the priority VoIP channel for rare call-cancellation scenarios without risking throttling or suspension? → In our implementation, we send an incoming call notification via the priority VoIP channel. Shortly after, we send a call cancellation notification on the regular push channel, marked with "content-available": 1. We expect this regular push to wake the app (triggering application:didReceiveRemoteNotification:fetchCompletionHandler:), but in practice the app never wakes, and our debug logs inside that delegate method never appear. Q. Under what exact conditions does a "content-available": 1 regular push fail to wake the app when it follows a VoIP push? Are there additional requirements (e.g., background modes, rate limits, power optimizations) that could prevent the delegate from being called? → According to Apple documentation: “APNs stores only one notification per bundle ID. When multiple notifications are sent to the same device for the same bundle ID, APNs keeps only the latest one.” However, in our tests: If a device is offline when APNs receives both: (a) a priority VoIP push for an incoming call, (b) a regular push for call cancellation (same bundle ID), Upon the device reconnecting, APNs still delivers the earlier VoIP push, instead of discarding it and delivering only the most recent (cancellation) notification. Q. Why doesn’t APNs replace the queued VoIP push with the newer regular push when both share the same bundle ID? Is this expected behavior due to channel type differences (VoIP vs. regular), or is there a way to ensure that the latest notification (even if regular) supersedes the earlier VoIP push? We’d appreciate your input or recommendations on handling such delayed pushes and any best practices for VoIP push expiration handling and call UI timing.