This is about the 3rd time I've seen this now (in about 5 years of using notification service extension, however all the occurrences have been in the past couple of months so presumably its some recent instability). What happens is a push is sent to the handset and is meant to get intercepted by a notification extension, except that doesn't happen - not due to an error with the app - something internally has gone wrong with the OS. Once this starts the notification service extension can never receive pushes again until the phone is restarted after with the extension starts to receive the pushes again. I got log from the OS when it did this and found there was an RBSRequestErrorDomain Code=5 error [u A0F3A639-F287-4B0C-AADE-A6F547D91404:m (null)] [<private>(<private>)] Failed to start plugin; pkd returned an error: Error Domain=PlugInKit Code=4 "RBSLaunchRequest error trying to launch plugin com.theCompany.app.NotificationServiceExtension(A0F3A639-F287-4B0C-AADE-A6F547D91404): **Error Domain=RBSRequestErrorDomain Code=5 "Launch failed**." UserInfo={NSLocalizedFailureReason=Launch failed., **NSUnderlyingError=0x5faa61190 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111"** UserInfo={NSLocalizedDescription=**Launchd job spawn failed**}}}" UserInfo={NSLocalizedDescription=RBSLaunchRequest error trying to launch plugin com.theCompany.app.NotificationServiceExtension(A0F3A639-F287-4B0C-AADE-A6F547D91404): Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x5faa61190 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}} Can file a radar but just posting here first just in case anybody from Apple know what the OS error code and hence the reason. (longer console log available)

I want to implement a scheme whereby the server gets instructed by the app during a handshake whether the server should send pushes over the Apple sandbox environment or the production environment. There's several variations where the push environment will vary depending upon the circumstances: Debug build/scheme with app installed via XCode Release build/scheme with app installed via XCode Developer distribution installed via .ipa/Apple Configurator app Ad hoc distribution installed via .ipa/Apple Configurator app App is installed from Testflight App is installed from the app store Is there a way the app can programmatically detect at run time which push server should be used and thus it can instruct the server accordingly during its handshake with it? I guess this boils down to if the app is able to programatically detect at run time if there's a production provisioning profile being used or not? Or is there some other mechanism to detect which push server should be used? There's a couple questions/answers on Stackoverflow about programatically detecting if a provisioning profile is present but they look a bit hacky and I don't know if they can be trusted to be future proof.

This has been a continual headache for months, ever since Xcode 15 came out. Everything is working just fine, you just made a code change, built and run it, and Xcode installs to the phone nice and quickly and runs it. But them bamn, next time you do the same thing, Xcode displays "Installing to " forever. It just never finishes. I've had this occur numerous times every day, with different versions of Xcode, multiple different iPhones, running multiple different versions of iOS, and even with different Macs. Always the same. It'll be working just fine, then out of the blue, without changing anything, Xcode will suddenly just decide to get into this state where it just hang and during installation, and won't recover even after terminating and restarting Xcode. Please somebody from Apple, what is going on? Is there a work around, how can it stopped from happening? Deleting the app doesn't fix it, restarting Xcode doesn't fix it. Unplugging the usb cable doesn't fix it, Restarting the phone doesn't fix it. What will? Wasted sooo much time with this happening every day for that several months. I've asked this question before and was met with total silence. Must I really raise an official support ticket to get an answer to this? Surely I'm not the only one this is happening to? And if its not "Installing to " that hangs forever then its "Attaching to on <name of phone" that hangs forever, usually both at the same time. (Currently running Xcode 15.2, iPhones are connected via usb).

If I try to run Instrument's logger for an app downloaded from TestFlight it says "Permission to debug app name was denied". "Recover Suggestion: The app must be debuggable and signed with 'get-task-allow'. How do you make the app debuggable? (I tried creating an archive with the scheme set to Debug, but after uploading that to TestFlight, it doesn't appear. So presumably its not possible to upload an app built with debug scheme builds to TF?). Therefore how can I make a TF build debuggable?, and how to sign it with get-task-allow? Does it have to be a developer distribution .ipa rather than a TestFlight build to enable Instruments/Logger to run it?

Trying to run a React Native app via Xcode can be very very very slow. Excruciatingly so. I often see messages saying things like Launching app is taking longer than expected. LLDB is likely reading from device memory to resolve symbols. But I see this all the time, if that's what it's doing it never finishes, and does it every time. This isn't just with one phone, its with several. Is it possible there some fundamental conflict between Xcode and LLDB and React Native Metro trying to communicate / load / debug / whatever that slows things down to a standstill?

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).

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).

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 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?

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 few questions about device check, and would be grateful if anybody knows the answers: why is DC not reset when the device transfers between users? The canonical example of why an app might use DC is if it offers a promotion and to stop user's from getting that promotion multiple times. However, using the same example scenario yes you've stopped the first user from getting multiple promotions but then if that device is transferred to another user you've stopped them from getting any promotions at all? how can you test things when the bits can't be reset? If once you've set the bits on a device then you can no longer ever use that device again to test the apps behavior in the situation when the bits are unset. does the app have complete freedom to set the timestamp to whatever it wants? For example, could the app set a bit with a timestamp of epoch? if the bits are shared between all apps from the same developer, then supposing that developer have more apps in the App Store then there are bits? If they have 5 apps offering a promotion and a device has previously had 4 apps installed, then the user wants to install a 5th app, but with all 4 bits now then the user will be able to abuse the promotion on the 5th app because the app has no way of recording if the promo has been used or not as the collective bits have been used up?

I just noticed this today while building a React Native app. Anybody else seen this and know what it means/how to track it down/how to fix it

In Xcode I've: select Product / Scheme / Edit scheme tap on Archive on the left hand side of the select post actions and + to add a new script Then in there I have added a script I want to run on the archive after its created. I'd like to be able to see the output the script churns out as it goes along but doesn't seem possible? If I just add something like echo "hello" to the start of the script then I don't see "hello" visible anywhere when I build an archive (via Product/Archive). I'm looking in the build navigator. Is there somewhere else to look or is it possible to get the logging into the navigator?

If I run the following code in didFinishLaunchingWithOptions() UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in if granted { DispatchQueue.main.async { application.registerForRemoteNotifications() } } } Then the result is that didRegisterForRemoteNotificationsWithDeviceToken() gets called. However if I change the code to be just: DispatchQueue.main.async { application.registerForRemoteNotifications() } Or as as its already running on main in this scenario, then just application.registerForRemoteNotifications() Then didRegisterForRemoteNotificationsWithDeviceToken() does NOT get called, but also neither does didFailToRegisterForRemoteNotificationsWithError(). Obtaining a push token is supposed to be independent of the user granting notifications permissions, so why am I not observing that behavior? I only observe this behavior when running on hardware, when running on the simulator both forms of the code work. Yet its nothing to do with my phone not being able to contact the Apple servers etc. - if I change the code back and forth back and forth between the two then if 100% works when using requestAuthorization() and 100% doesn't when not using it. There's nothing additional or out of the ordinary with the code, its standard app delete template stuff. Why isn't it getting a push token when requestAuthorization() isn't used? (I've tried adding an async delay to calling registerForRemoteNotifications(), but it made no difference).

How can experimentation and testing calling the AgeRangeService.shared.requestAgeRange() functionality be recreated easily? The very first time I ran this the OS popped up a dialog, however it won't do so again, even after the app is deleted and the device re-started. If one navigates to Settings/User/Personal Information/Age Range for Apps/Apps that have requested your age range appear here. Then the names of apps appear here even after the app has been deleted. Therefore how can it be removed from this section? Erasing and resetting the phone will presumably reset things back to a state such that the dialog can be presented again. But doing that and having to wait for that to complete each development or test run is impractical. Is there an alternative?