“file uri scheme”

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

I was mostly thinking of its interaction with extended attributes, as we see the target threads touching those as well. Just to clarify something, what's really going on here isn't really xattr access. The resource fork has a bit of a strange history, as it predates general xattr support by ~15 years and doesn't really fit into the same mold as any other xattr. It originally had its own API access path through FSReadFork and the ..namedfork/rsrc suffix to open and, more importantly, is routinely MUCH larger than any other xattr, most of which are measured in “bytes. The resource fork was basically added to the more general xattr implementation, rather than being implemented as a native part of the original implementation. Several years ago, we repurposed the resource fork and used it to implement file system level compression of specific files, which is what's happening here. Critically, these files look like standard data files and are accessed by reading the file

File a bug report. I think Apple's bug algorithms won't flag anything unless there are multiple reports on the same bug. Although their Music app still can't properly handle gapless song lists reliably (e.g., Pink Floyd) and yet multiple people have been yelling about this over the years, so I may be off base as to how they prioritize their work. I don't think they have anyone to put the fear of God into them any more like Steve Jobs did when the engineers generated bad code.

Report filed: FB22373888

Could you please suggest the recommended approach? First off, as a clarification, what are you actually trying read here? If this is your apps preference file (meaning, it has your apps bundle ID), then NSUserDefaults (or CFPreference) will read automatically without any special code. Similarly, if this ISN'T your apps data, then what's the relationship between your app and the data you're trying to read? __ Kevin Elliott DTS Engineer, CoreOS/Hardware

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 considerably from r

Part 1: Thank you for your reply. I have attached the log file. I apologize for the inconvenience, but please take a look. So, starting with the log, the first thing that jumps out at me is that it's ascribing the crash to this stack in thread 0: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread: 0 libsystem_kernel.dylib 0x24a42ccd4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x24a43030c mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x24a43022c mach_msg2 + 4 [inlined] 3 libsystem_kernel.dylib 0x24a43022c mach_msg_overwrite + 424 4 libsystem_kernel.dylib 0x24a430078 mach_msg + 24 5 CoreFoundation 0x19b9dfea4 __CFRunLoopServiceMachPort + 160 6 CoreFoundation 0x19b9a9f94 __CFRunLoopRun + 1188 7 CoreFoundation 0x19b9a91d0 _CFRunLoopRunSpecificWithOptions + 532 8 GraphicsServices 0x240eb7498 GSEventRunModal + 120 9 UIKitCore 0x1a166d2cc -[UIApplication _run] + 796 10 UIKitCore 0x1a15d8158 UIApplicationMain + 332 11 UnityFramework 0x11cbfbb08 12 sekai 0x1020bbbb8 13 dyld 0x1985bdc1c start + 6928

Thank you all for filing the feedback reports, which do help. If possible, would you please verify with iOS 26.5 beta (23F5043g) to see if the issue goes away, and update the status here? Thanks again! Best, —— Ziqiao Chen  Worldwide Developer Relations.

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 informat

Hey @Jir_253, You can generate a new license file in the Developer portal. Please see this help article for additional details. If you have any issues, or would like to request enhancements, please provide feedback on the Enterprise APls for visionOS using Feedback Assistant. Feel free to post the feedback number here when you do. Bug Reporting: How and Why? has tips on creating your bug report. Thanks, Michael

@catelinecz May I ask you 2 things if I may. Can you create a new thread and post your code there so can be a separate thread? Can you also create an enhancement request for the universal links team to take a look? If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why? Albert 
  Worldwide Developer Relations.

@Alonso- Thanks for you post, have you file a bug and do you have the FB number: https://developer.apple.com/forums/thread/820393?answerId=881554022#881554022 Albert 
  Worldwide Developer Relations.