With iOS 18 there are now five ways for a caller to be blocked/silenced: the caller can be blocked via the Live Caller ID extension the caller can be blocked via the Call Kit extension the caller can be blocked via Block Caller via the call history recents the call could be silenced via Silence Junk Callers the call could be silenced via Silence Unknown Callers These are all totally separate and there's no way of reconciling all of them and presenting a holistic overview and management system to the user. Call blocking applications have no way of knowing which numbers will be blocked by 3) or silenced by 4) or 5), or even of determining 4) and 5) are enabled. And iOS doesn't indicate to users what will be blocked by 1) or 2). Currently users have no way of knowing what's been blocked/silenced where. Neither via call blocking apps nor via the OS. From users' perspectives its a confusing and frustrating mess. If the OS exposed which numbers have been blocked via 3) to applications and exposed if Silence Unknown

I've been following the instructions on how to set up Live Caller ID Lookup using the example PIRService. And I have been successful - I'm managed to get name information and images retrieved and displayed on the call screen, in addition to being able to block numbers via PIRService too. So while I did get it working, it was, and still is, incredibly painful to do so due to the fact it only works about 1% of the time. There's two main problems, which look like they're different manifestations of the same issue. The first problem is difficulty enabling the Live CallerID lookup feature via the flip switch in the iPhone's settings, and then the second issue is when this has been enabled, then a phone number's details is being attempted to be retrieved. There's a lot, a very lot, of timeout issues being reported by CallKit logging i.e.: configure failed Error Domain=com.apple.CipherML Code=1100 Unable to query status due to errors: The request timed out. UserInfo={NSLocalizedDescription=Unable to query status due

In the documentation for the example Live Caller ID server (https://swiftpackageindex.com/apple/live-caller-id-lookup-example/main/documentation/pirservice/testinginstructions) there is an example service-config.json. file shown (without thorough documentation). That config file, and the whole of the instructions, center around there being two datasets of numbers: block and identity. My question is - is it possible for more than one dataset to be specified i.e. for block1 and block2 to be specified? The use case for this would be - suppose the Live Caller ID server has a set of numbers it has identified as being nuisance callers and so it lists these in the block section. However user A might want all these nuisance callers to be blocked but user B does not. Therefore the Live Caller ID extension on the handset would need to use a different dataset on the server so that user A's calls from a set of numbers is blocked, but user B's are not. Note that I'm not suggesting that the Caller ID server should be capab

Hello I work for a company which is not itself a carrier, however we develop applications on behalf of carriers (the relationship between us and several large household name US carriers has existed for many years). The applications that we develop typically need carrier and/or special entitlements, for example: com.apple.CommCenter.fine-grained/public-subscriber-info com.apple.developer.coretelephony.sim-inserted com.apple.developer.pushkit.unrestricted-voip com.apple.developer.usernotifications.filtering com.apple.developer.associated-domains Obtaining those entitlements for the carrier applications that are released to the App Store is itself not a problem as the customers apply for them and they are duly granted and applied to the applications. However, what is a problem is working around the strict Apple development and distribution requirements and limitations, and the consequences that has given that the apps don't belong to our Apple account but the customers. Typically, a customer would provide us a d

Hello Apps and their extensions are able to communicate with each other by reading/writing data stored in a shared group location. However this isn't the case with the the Live Caller ID Extension - if data is written to group defaults for example (as opposed to standard defaults) by the app, then that data isn't readable by the Caller ID extension. This has the consequence that its not possible for a user to dynamically switch which data set the extension connects to. Consider the use case where the Live Caller ID Server has one data set where callers are not blocked, and another where they are blocked, then the caller id extension can route different requests to different datasets based on the user tier. However as the extension can't read data from the shared group then the app can't communicate user preferences to the extension, therefore the switching isn't possible. Is this by design or due to the immaturity of the feature? If its by design, then it means the use case outlined above isn't possible, and

The documentation for adding images for Live Caller ID specify that they should be in .heic format and be less than 64KB. However the majority of the time they just don't display. Mostly they would with iOS 18 beta 4, but with beta 5, 90% of the time they don't display. Seems there's some other factor at play, such as pixel size of width/height, or resolution density?

With the Live Caller ID example server, the caller lookup dataset is defined in an input.txtpd and processed by running a ConstructDatabase command which creates a block.binpb and an identity.binpb file. In other words, a static input file is being processed into static block and identity files. However, in the real world, the data content for identified and blocked numbers is something which is in a constant state of flux and evolution, as new numbers becoming available, old ones become stale, numbers which were initially considered safe change into being considered malicious etc. etc. Is the example server just that, merely an example using fixed datasets, and an actual production server is able to use live every changing data to formulate its response back to the iPhone OS query? Here's a concrete use case - suppose it's a requirement to permit US nanp numbers but to block anything else. The total number of non US nanp numbers is so large and ever changing that it would be unfeasible to attempt to capture

I have a project which when I attempt to build with XCode 16 RC fails with the message XCBBuildService quit unexpectedly. This occurs 100% of the time, thus I am unable to build the project. It first occurred in Xcode 16 beta 1 and has been present ever since, ever present in every beta; and now as its still present in the RC its highly unlikely it'll be fixed when the RC release becomes the final release. I submitted a ticket for this many weeks ago (FB14062261), but its not been looked at/updated. This is a problem in the short term because my app needs updating to use some iOS 18 specific features, in the longer term, it won't be possible to submit the app to the App Store if it continues to only be buildable with Xcode 15. As its impossible to build the app, I attempted to create a support ticket to get assistance. However I am unable to create a support ticket because the web page won't permit me to proceed raising a ticket unless there is a test Xcode project that recreates the issue. However, the issue

If I run an app with a message filter extension on a phone with iOS 17.N then it works as expected. However if I run the same app (totally unchanged) on a phone with iOS 18 RC then there's multiple problems. I noticed there's no longer any logging from the extension in the Console (while there is for iOS 17 devices) in the messages app the filter sub categories aren't displayed (but they are on iOS 17 devices) if I try to debug the extension and place breakpoints in it, then there's an exception that occurs when the extension is enabled and the OS logs this (this doesn't occur with iOS 17 devices) '/private/preboot/Cryptexes/OS/usr/lib/swift/libswiftIdentityLookup.dylib' (no such file), '/usr/lib/swift/libswiftIdentityLookup.dylib' (no such file, not in dyld cache) I tried running on: iPhone with iOS 17.6 - no problems iPhone with iOS 18.1 beta - has all the above problems iPhone with iOS 18 RC - has all the above problems Was surprised the RC is so broken in this area as its release will be imminent. As thin

If an app with a Message Filter Extension is run on an iPhone with iOS 18 installed then there's no logging output to the console (using print or NSLog), however there is logging in all previous versions of OS. Being able to view logging at run time for this component is essential as a debugging aid to see, for example, if the extension launches, if a text is handled locally or deferred to the network, to see if there's a network error, to examine the server response etc. Is there a specific reason it was disabled or is it accidental? Thank you

A message filter extension is only forwarded SMSs by the OS for filtering, iMessages aren't. But what is the situation with RCS messages? Will they be filterable by a message filtering extension?

I've got a 2023 M2 MacBook Pro and used to get great battery life out of it (> 6 hours when using it for development purposes). Now however, all of a sudden, that has dropped off a cliff, and the only thing that has changed is Xcode 16 has appeared. As I'm compiling a project I can literally see the % amount of the battery charge remaining tick down in front of my eyes as I watch. I just compiled a project twice and during that time the battery dropped from from %89 to %79 and Xcode is listed as a culprit using significant battery drain. Anybody else noticed anything similar? Anything that can be done to to decrease Xcode's battery drain?

I've got a bit of code which is making a HTTPS GET request. On an iPhone it runs as expected, however when running on the simulator there's a HTTP 400 response. I've logged the url and my http headers that I'm adding, and in both cases they are identical for the simulator and iPhone (there is no http body content). Therefore, as everything is identical, I'm wondering how it could work with hardware and not with the simulator? Does the OS append any additional HTTP headers before the request goes out (such as User-Agent for example) and might those be different between iPhone/simulator?

If a new (iOS) project is created in Xcode then a default set of deployment targets and values gets automatically created and set as follows: If the iPad, Mac, and Apple Vision supported destinations are deleted from the Xcode general section, these deployment targets still remain. If the app is then built using Xcode 16 and uploaded to TestFlight/App Store then the following issue is reported: TMS-90899: Macs with Apple silicon support issue - The app isn‘t compatible with the provided minimum macOS version of 11.0. Why is XCode populating the macOS deployment target with a value that that results in this issue? Why is Xcode even populating all 6 of these targets at all when its for an iOS app and hence 5 of them are redundant? Can the macOS deployment value simply be increased to silence this issue? Or can these that aren't relevant to iOS be deleted (if so how)? TIA

Over the past few weeks I've seen several people mention pushes sent via the sandbox haven't been getting delivered. Today I'm also seeing that (though pushes sent via production are fine). So it would appear to be down again. What's going on recently, any reason it's so unstable these last few weeks?