“We are unable to process your request”

A quick test shows it uses the xattr-specific ES events. Not definitive, and may differ on some systems, but this was one of the affected devices. ES_EVENT_TYPE_NOTIFY_DELETEEXTATTR: process=/System/Applications/TextEdit.app/Contents/MacOS/TextEdit path=/Users/matt.slot/Library/Containers/com.apple.TextEdit/Data/tmp/TemporaryItems/NSIRD_TextEdit_ihoZLx/21B97262-CCCD-4DE3-929D-DC322367AC80.rtf xattr=com.apple.genstore.origdisplayname ES_EVENT_TYPE_NOTIFY_DELETEEXTATTR: process=/System/Applications/TextEdit.app/Contents/MacOS/TextEdit path=/Users/matt.slot/Library/Containers/com.apple.TextEdit/Data/tmp/TemporaryItems/NSIRD_TextEdit_ihoZLx/21B97262-CCCD-4DE3-929D-DC322367AC80.rtf xattr=com.apple.genstore.info ES_EVENT_TYPE_NOTIFY_DELETEEXTATTR: process=/System/Applications/TextEdit.app/Contents/MacOS/TextEdit path=/Users/matt.slot/Library/Containers/com.apple.TextEdit/Data/tmp/TemporaryItems/NSIRD_TextEdit_ihoZLx/21B97262-CCCD-4DE3-929D-DC322367AC80.rtf xattr=com.apple.genstore.gen_opt

You can also kill it by sudo pkill -9 remotepairingd If you encounter an instance where you actually find this necessary, please file a Feedback Assistant Report which includes a devicectl diagnose (and separate mac / phone / watch sysdiagnoses if they're not all collected by it). There are no known issues for which this step should be necessary, so if there are issues, we want to know about them. make sure NOT to un-pair your device If you un-pair or you accidentally tap the button to not trust, the only way to get the prompt to appear again is by physically re-connecting the phone. watch is ON throughout the connecting process Yes, and it needs to remain unlocked throughout the DDI mounting process as well. If the device locks before the DDI mounting completes, you will need to re-attempt mounting the DDI. --Jeremy jeremyhu at apple dot com

Thank you @Tomato and @DTS Engineer ! The purpose of my app is to provide a notification mechanism when there are drastic air quality changes. To accomplish this, I have an async function that makes a GET request to an air quality sensor (using UrlSession), decode the payload, and then do comparisons with previous readings. If the readings have changed drastically, an UNMutableNotificationContent() is scheduled. Currently, my async function is called from within a repeating scheduled timer so that I can poll my sensor every minute: Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { _ in timerVal -= 1 if timerVal == 0 { timerVal = startVal getAQI() } } This all works just fine (including when the app is in the background) ONLY when I run the app from Build and Run in Xcode on my dev iPhone as the destination. I've left the app running this way for hours in the background and with the phone locked and it works great! However, when I try to run the app purely from the app shortcut on my iPhone

Thank you for your post @briggr1 . The information provided by @Tomato is highly valuable, is your intention is to create a testing application that sends requests every x minutes. In that case, please clarify your specific requirements. If the application is intended to run in the background, you may consider disabling that feature within the app’s settings. Is this application intended for macOS or iOS? Are you using iOS as standard iOS lifecycle. Is the app going to the background if the user swipes to the home screen, iOS gives your app a few seconds to finish what it's doing, and then completely suspends it to save battery. Any Timer, DispatchQueue, or standard network calls you have running will freeze immediately. You can ask iOS for up to ~30 seconds of extra time to finish the task. Use UIApplication.shared.beginBackgroundTask(expirationHandler:). Once the task finishes, you must call endBackgroundTask, or iOS will forcefully kill your app. In macOS, to prevent this, you use the ProcessInfo

Part 2: No, not really. Memory exceptions (what a seg fault is) happen because you’re accessing memory that you either never allocated or have already freed, neither of which will happen due to direct lack of memory. Keep in mind that your app can't really run out of memory in the way you're describing. SO, the issue here is that the term memory is commonly used to describe two separate, but distinct, concepts: How much RAM your process is using. How much address space your process has been given by the system. The important thing to understand here is that those two factors are somewhat independent of each other. In simple terms, address space is what you actually use when you call “malloc, but RAM usage doesn't change until you actually touch the memory you've malloc'd. Similarly, the question here: is it possible that memory usage has increased significantly in iOS 26.4 compared to previous OS versions? ...doesn't really make sense in the context of address space. Real RAM usage changes c

I will go ahead and file a request for a Core HID development variant. Perfect, thank you. FYI, I can't guarantee anything will change, but I'd like to get this sorted out as soon as possible, so this might be working relatively soon (at least on paid accounts). One comment here: More broadly, I think it would be very valuable to have a simple user-space API for controller virtualization available to hobbyists and personal developers as well, even if limited to development builds. I've seen a few requests asking about providing this support to the free account tier, not just the paid tier. It's a reasonable suggestion, but I did want to explain that the main reason the development entitlements are restricted to paid accounts is as a form of practical security protection. The idea here is that the underlying details of development signing's limitations: Builds only run on the specific devices that were registered when the signing profile was generated. Registering a device requires extracting