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?

I'm experimenting with creating a Framework and have noticed a difference when dragging and dropping/or adding it into a project. If I create a brand new app and add the Framework then Xcode automatically creates a "Frameworks, Libraries, and Embedded" section within the app settings general section. The framework gets added with a default embed setting of Do Not Embed, which can be changed to Embed & Sign or Embed without Signing. However, I have an existing app which doesn't already contain a "Frameworks, Libraries, and Embedded section" section, if I add the framework to that app then Xcode is NOT creating a "Frameworks, Libraries, and Embedded section", instead it is adding the framework to the existing "Link Libraries with Binary" section. However this section does not have the embed box that a "Frameworks, Libraries, and Embedded" section has. Why is there this difference? And how can you choose whether to sign or not the framework if its been added by Xcode to the "Link Binary With Libraries" section rather than the "Frameworks, Libraries, and Embedded" section. I am finding that when Xcode adds the framework to the "Link Binary With Libraries" section and the app is run then there are run time errors about the framework not being able to be found, this does not occur when it gets added to the "Frameworks, Libraries, and Embedded" section. Is it possible to there explicitly create a "Frameworks, Libraries, and Embedded" section? I can't find one, nor can I get Xcode to create one, it keeps insisting on adding the Framework to "Link Binary With Libraries", which results in the app not running.

I received an email from Apple saying the app is using: NSPrivacyAccessedAPICategoryDiskSpace NSPrivacyAccessedAPICategoryFileTimestamp NSPrivacyAccessedAPICategorySystemBootTime I'm not directly calling (afaik) any API that might be involved in getting the disk space, file timestamp, nor system boot time, so presumably these are indirectly originating in a pod whose api I'm using. However I have about 100 pods in the app, how can I know which one these are originating from? (100 seems a lot, but its a React Native app and that alone pulls in dozens and dozens of pods implicitly in addition those specified explicitly in a pod file) I can try and update all the pods to the latest version, but if the offending pod(s) hasn't added a manifest file, then I have no way of knowing which one it is - therefore I can neither contact them to ask when they will release a new version, nor can I attempt to try and remove the pod, because I just don't know which one might be causing the manifest warning. So what are we supposed to do in this situation?

I've got an app which has a notification service extension (and has had so for a few years). I noticed that the pushes were getting delivered directly to the user for a handset, and in the log could see a SpringBoard error saying Error Domain=PluginKit Code=4 RBSLanchRequest error trying to launch plugin Error Domain=RBSRequestErrorDomain Code=5 Launch failed ErrorDomain=NSPOSIXErrorDomain Code=111 Unknown error:111 I rebooted the phone and it started working as expected. But it's worrisome this happened, and it's not the first time I've seen it either. Observed with iOS 17.3.1

I don't follow the section in the wwdv video on http3 https://developer.apple.com/videos/play/wwdc2021/10094/ From about 07.00 onwards for a couple of minutes, the presenter says URLSession won't use http3 unless the server advertises it. Then he uses instruments to show the app is using http2 - BUT the server is advertising http3. Then he says the fact the server advertised http3 will be remembered for future sessions. Why does the app use http2 for the first session even though the server advertised http3? Does that mean the first time any app connects to a http3 server it'll actually be http2 and only http3 for subsequent connections?

I've installed the same developer certificate onto three different Macs. When viewed in the keychain (or in Xcode) on one Mac it says its revoked, on another it says its not trusted, but on a third there's no issue reported. How could there be a difference between the three Macs? (Both Macs have the date/time set to be the same). Can 3rd party software, VPNs etc. interfere in this at all?