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 them in an input.txtpd file and then process that, and then to re-capture and re-process it endlessly. Instead what would be required is the ability for the Live Caller ID server to evaluate at query time, using a regular expressions for example, if a number is nanp or not. Is this possible?

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?

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 thus greatly reduces the possible functionality of the Live Caller Id feature. (It would be possible for the app to install multiple extensions, each of which connects to a different data set by specifying a different user tier, but the user having to flip these one and off within the Settings app is a dreadful user experience).

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 developer certificate and set of provisioning profiles, but they would keep the distribution certificate and do the TestFlight/App Store release themselves. There's two limitations that come into play here, the first is that we can't distribute the app to TestFlight and secondly, we can only install the customer's apps on hardware registered with their Apple account. Given how the limitation for that is 100 in total, and these are large companies, they just don't have slots available and hence we might have a single device on which their app can run. These are very severe limitations given the complex nature of the applications and the need to have several developers/testers involved, which isn't possible. To mitigate those limitations we have "mirror" versions of customers' apps, these are apps which are identical to the customer apps except they have bundle ids registered to our Apple account. This enables the apps to be developed by any number of developers and distributed via Testfight and hence to any number of testers. But the problem is, the functionality of the mirror apps is severely reduced due to the fact they don't have the entitlements of the customers' apps. To get to the point of the post - I would like to know if there any potential solutions to this? For example: could it be possible for our mirror applications to be granted required entitlements (given the relationships we have with the customers. I'm sure the customers could vouch for us as a company and the need for this) could the entitlements be granted if we switched the mirror apps over to an Enterprise account (as enterprise apps can't be released to the App Store)? any other technical options or suggestions? Thank you

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 capable of storing individual user's preferences. All that would be required would be two data sets: one where blocked content is none and and one where blocked content is some. Then a user/app could switch between them as indicated by the user. Is that possible? If the database structure and service-config.json etc. is not configured to permit that, then could two different servers be set up to achieve this instead? i.e. so the server url specified in the app's extension can be set at run time and not at compile time?

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 to errors: The request timed out., NSUnderlyingError=0xd98344450 {Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={NSLocalizedDescription=The request timed out., NSErrorFailingURLKey=http://192.168.1.100:8080/issue}}} When this occurs I can see that the request is getting through to the PIRService as it outputs logging to the Mac console: 2024-07-28T09:33:15-0700 info Hummingbird : [HummingbirdCore] Server started and listening on 0.0.0.0:8080 2024-07-28T09:33:37-0700 info Hummingbird : hb_id=5e0330c893af6a98c20e5100fdb26871 hb_method=GET hb_uri=/.well-known/private-token-issuer-directory [Hummingbird] Request 2024-07-28T09:33:37-0700 info Hummingbird : hb_id=5e0330c893af6a98c20e5100fdb26872 hb_method=GET hb_uri=/token-key-for-user-token [Hummingbird] Request So it would appear that requests are getting through to PIRService but then something is timing out after that. Could that be the PrivacyPass/Homomorphic Encryption stuff? Or something else? What could be a cause of this instability, and is there anything that can be done to increase reliability of it? (Xcode 16 beta 4, iOS 18 developer beta 4, Sonoma 14.5, the iPhone(s) being tested are connected to the Mac via usb cable, running on the same Wifi network).

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 Callers and Silence Junk Callers are enabled then call blocking applications could present a unified way for users to see and manage what's going on with their device holistically.

A Notification Service Extension is one of the more capable extensions, and there's a lot that can be done within it (for example, it can invoke a Call Extension). However its not possible to use a Contact Provider Extension within it. If a CPE has been enabled by the main app, then if a push is sent to the NSE, then within the NSE the ContactProviderManager class reports that the CPE is disabled and its not possible to anything with it. For example a call to ContactProviderManager.signalEnumerator() will hang and not complete. I was hoping to create a contact and make it available to the system on receipt of a push, but this isn't going to possible. Is this intentional and by design, or just due to the immaturity of this feature/iOS beta? The documentation of a Contact provider Extension says: "signalEnumerator() An example of using this call is to handle a push notification to your app when the provided contacts from your server update" It therefore seems strange that the main cited use case for ContactProviderManager.signalEnumerator() isn't actually possible if the push is delivered to an extension rather than the app.

If using Xcode beta 16 beta 4, a target type of Contact Provider Extension is created, then the auto-generated template code has errors right off the bat. Compiler be like what in the dickens is this?: class ContactProviderExtension: ContactProviderExtension

I've followed the instructions to configure and launch a live caller id test service (https://swiftpackageindex.com/apple/live-caller-id-lookup-example/main/documentation/pirservice/testinginstructions) i.e. I've constructed a database, built and installed the PIRService etc. Additionally I have created a test app with a Live Caller ID Extension. The problem I'm facing is when turning on the Live Caller ID feature on an iPhone (the Settings|Apps|Phone|Call Blocking & Identification|Live CallerID Lookup switch) with iOS 18 Beta 4 is the phone logs: "The request timed out." UserInfo={NSLocalizedDescription=The request timed out., NSErrorFailingURLKey=http://MacBook-Pro.local:8080/.well-known/private-token-issuer-directory The configuration notes say: "When running things locally on your Mac, and your testing device is on the same network, then you can use mDNS to let the device find your Mac. Let’s assume that your Mac’s hostname is Tims-MacBook-Pro.local. Then we should use the following value for the URLs: http://Tims-Macbook-Pro.local:8080. Thanks to the mDNS protocol your device should be able to resolve your hostname to the actual IP address of your Mac and make the connection." My Mac hostname is "MacBook-Pro" therefore the Live Caller ID Extension is configured as: LiveCallerIDLookupExtensionContext( serviceURL: URL(string: "http://MacBook-Pro.local:8080")!, tokenIssuerURL: URL(string: "http://MacBook-Pro.local:8080")!, userTierToken: Data(base64Encoded: "BBBB")! ) And the service-config.json is configured as: { "issuerRequestUri": "http://MacBook-Pro.local:8080", "users": [ <snip> (I've also tried excluding the issuerRequestUri as the instructions say "This value can be omitted from the configuration. Setting this explicitly will not be required for devices using iOS 18.0 beta 4 or later.") And the PIR Service is started on the Mac as: PIRService --hostname 0.0.0.0 service-config.json And it starts and runs. The iPhone and Mac are on the same Wifi network and connected by usb cable. As far as I can tell, everything has been set up in accordance with the Testing Live Caller ID instructions, yet I get the error when attempting to enable the extension on the iPhone. Is there something missing/incorrectly configured?

If an app has a Live Caller ID Lookup extension and the lookup server indicates that a caller is identified and not blocked, then if the user wished to locally block that number they can do so either via the iPhone call block button, or via the app's Call Extension block list. However there's apparently no way for the user to do the inverse. i.e. if Live Caller Id Lookup indicated that a number should be blocked, then how could a user indicate they don't want that number blocked for them? If they added it to the Call Extension as an identified number, but live lookup is saying the number should be blocked, then what does the OS do? Give priority to the blocking instruction from the live lookup server, or give priority to the fact its in the Call Extension's Identified list?

I've got a custom run script build phase in my Xcode iOS project, however I want it to run before the items in the Target Dependencies section get built. So I added a Pre-Actions phase to the target's build scheme and pasted the contents there. However, during a build, there's no way to see if the stuff in the pre action is successful or not. It's possible to put echo statements into a run script build phase which is useful to print values such as file paths etc. but these don't work when part of a scheme pre action. Also if I deliberately put garbage into the scheme pre action, then I can see Xcode is still running the pre action, but as its full of garbage it should fail, but Xcode doesn't report any errors anywhere. So, is there any way to see and confirm if a scheme pre-action was successful or not, or to output logging statements from it to verify values its using are as expected?

I'm getting Sandbox:rsync.samba deny errors trying to build an app using Xcode 16 betas. There's lots of info on this on google, and the solution everybody used to fix it is to change the Xcode build setting User Script Sandboxing from NO to YES. However this doesn't exist with Xcode 16. Does it have a replacement?

Our company is going to develop an iOS library of functionality for inclusion in several apps, some of the apps will be developed in-house and some externally. When the library is included in external apps the source code shouldn't be visible. When the library is included in internal apps, having the option to view and step through the code within the library will be invaluable for debugging. How could I set things up so that two forms of the library can be easily generated - one exposing source code and the other not. Ideally they should be capable of being incorporated within the apps in the same manner regardless of if the source code is expose or not Is that possible? I looked at Swift Packages, but it seems its for distribution of source code only, and its not possible to hide the source code. However, conversely, a framework only contains binary and no source code. Is there any other option?

We have an app which is using CTSubscriber.simInserted (using the carrier entitlement com.apple.CommCenter.fine-grained). In iOS 18, simInserted returns false for every sim (where it should instead be returning true). Presumably this just is a temporary bug in 18 beta?