I've been using NSEs extensively for a decade. I've noticed very occasionally something in the OS just seems to get broken. Have you tried simply rebooting the phone? That's fixed inexplicable out-of-nowhere issues for me in the past.

"we don't "mix" data like this. There's basically a "hierarchy" of data sources and we only present the data from that data source (whichever one "works"). For example, if there is a contact card for a specific number then that's what we're going to show to that user, regardless of what any other data source would have returned*." @Kevin Elliott When there is an incomming call what is the hierarchy of data sources? I would guess from my observations its: Contacts Call Directory Extension Live Caller ID SIP header content Would that be correct? There's additionally Voip Calls, but beyond that, are there other sources of data where call time information is extracted from to display on the call screen? Thank you

"(its more complex to verify as app A is developed by one company and app B by another)" Just to clarify, developed by different companies, but having the same bundle id stems (possible as provisioning profiles, signing certificate etc. have been shared from on company to the other)

I first encountered this issue many years ago, and yes, like you say, once it has occurred its not possible to recover, the user has no option but to hard reset their phone if they want to be able to use the app. I tried to find my post(s) about it but the forum only seems to archive posts from 2021 onwards.

@eskimo Hello "Or because you’re trying to decide how to handle the error?" Yes. In the example you gave that's a compile-time programming error. I'd like to know if there are any errors that can occur at run time for example and are re-tryable, for example any errors caused by connectivity failures, in which case if the app tried again then next time the failure might succeed?

I was asking the same question on here several months ago, seems there is no way. Do you have an Apple IP range list? How did you obtain it, how do you know it won't change at some point in the future though.

I know what the local laws are and how they apply to users. Texas requires this, but the USA has 50 states. If an app is destined for distribution in the USA, in order to comply with Texas, its necessary to force users of the other 49 states to go through this even though they don't live in Texas? Have Apple considered this and provide a solution to this situation? Making all users of the app perform something intrusive and unnecessary just because Texas says its necessary.

@Kevin Elliot "One thing that I'd like to understand here is what the actual use case/concern is here." What if, as a user, you receive a call from an unknown caller. You don't answer, but instead call that number back to see whom, if anybody, answers. If after doing that you decide the caller is a spammer, or nuisance caller, whatever, and you decide to use an app using CallKit to block the number. Well, that caller is not going to be blocked due to the outgoing call.

@Argun Tekant Thank you, however having to obtain notification authorization for background silent notifications seems to be contradictory to this logic? The app can consume and do something with the push without it resulting in a notification.

@Argun Tekant Thank you. In my case the NSE has the filtering entitlement, how does that change the list of pre-conditions?

Ok, so found that that if you don't have the background capability of push notifications to your project then you have to call requestAuthorization() in order to get the push token, as described above. But when you add that background capability, then you can obtain the token without calling requestAuthorization(). What's with that?

This can be reproduced from scratch in just 2 minutes: create a brand new iOS app and give it the push notification capability. Change the app delegate template code to this: @main class AppDelegate: UIResponder, UIApplicationDelegate, UNUserNotificationCenterDelegate { func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { UNUserNotificationCenter.current().delegate = self // UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in // NSLog("Notification permission granted: \(granted)") // DispatchQueue.main.async { application.registerForRemoteNotifications() // } // } NSLog("didFinishLaunchingWithOptions returning") return true } // Called when an APNS token has been sucessfully obtained func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) { let token = deviceToken.map { String(format: "%02.2hhx", $0) }.joined() NSLog("Apn Push token: \(token)") } // Called when APN token request fails func application(_ application: UIApplication, didFailToRegisterForRemoteNotificationsWithError error: Error) { NSLog("❗️Failed to register for remote notifications: \(error)") } Neither didRegisterForRemoteNotificationsWithDeviceToken() nor didFailToRegisterForRemoteNotificationsWithError() get called. Now uncomment the code and didRegisterForRemoteNotificationsWithDeviceToken() will get called. So based on this experiment, requestAuthorization() is a requirment. Now where does it state that in the Apple documentation, it doesn't, how does this code differ from what's in the Apple documentation, it doesn't. https://developer-mdn.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/HandlingRemoteNotifications.html#//apple_ref/doc/uid/TP40008194-CH6-SW4

Hello It doesn't occur when using OSLog, just NSLog. Is this intentional? My apps can change over, of course, but there's a installed app base out there of millions of users (some users are savvy enough to be able to collect console logs if ever there's an issue they report)

What type of extension is it? Some have read and write access, but others only have read access.

FWIW I've got an app in the App Store using CallKit to block and identify calls. After reading this thread I gave it try out with some iOS 16 devices but didn't encounter any issues. Doesn't mean there aren't any of course, but at least its not something endemic affecting all apps/users. I'll keep watching the thread with interest.