“file uri scheme”

We should not be expected to all file feedbacks for Apple to fix a critical bug that should not have shipped in the first place. CloudKit is opaque and difficult enough to implement and test that there is sometimes no way to know if we are at fault or if it’s some quirk of the system. Only apple could have caught this bug with certainty and they should be performing a root cause analysis about why it shipped at all. Apple’s own sample app fails. Why is that not an automated test?

Thank you! this is very helpful and clarifies the issue a lot. I will go ahead and file a request for a Core HID development variant. Regarding the SIP / AMFI workaround: I understand the security concerns, and I agree that lowering system security is not an ideal solution. Of course there isn't a way to enable that only while the app is in use isn't it? That would be an acceptable risk for me. Or is it inherently a reboot-level change? In parallel, I will also explore mapping to keyboard and mouse events as a fallback, even though that is not the original target and is clearly less suitable than a true controller-visible solution. 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 understand it's possible on Windows. Thanks again for the detailed explanation.

I have managed to wrap a command line tool into a .app package and to test my package localization. while this works it's obviously not the idle way to test a package localization. Just waiting to see if I get any more responses from someone who has actually tried to do this. Just to recap, there is nothing special here, just a command line tool with a Localization.xcstrings file that has one sentence both in English and fr-CA.

I filed a similar report yesterday... Xcode 26.4 (17E192) Simulators Keep Showing As Unavailable After Successfully Intalling Them FB22346008 ... with sysdiagnose tarball and screen shots. Am also running Tahoe 26.4. I spent the better part of this evening removing the following items: /Applications/Xcode.app /Library/Developer ~/Library/Developer ~/Caches/com.apple.dt.* ~/Preferences/com.apple.dt.* /private/var/tmp/com.apple.CoreSimulator.SimDevice.* rebooting my machine, and then reinstalling Xcode 26.4 (Apple Silicon) and the command line tools. I then used xcrun simctl to flush all of my devices and runtimes. I spent a lot of time fighting Xcode because after removing old simulators, Xcode automatically downloads them all again (SMH!). Once Xcode seemed to stabilize its downloads (using xcrun simctl list to monitor everything), I then added the iOS, watchOS, and tvOS simulators for 26.4. So far, things seem to be behaving. We'll see whether or not I wake up tomorrow to joy or despair. I have a 20

Exactly same issue here since iOS26.4. Mac works as expected, on iOS not getting updates on cloud sync. Filed the feedback FB22353668

Since updating the OS to 26.4, the app has been crashing more often after I launch it. Please post the full crash log, using the instructions found here. Additional information: The app was developed using Unity. After contacting Unity, they indicated that based on the crash logs, it is highly likely that a “Segmentation Fault” occurred. A Segmentation Fault just means your app attempted to access invalid memory, which doesn't actually tell you very much about why you actually crashed. The document Diagnosing memory, thread, and crash issues early has a good overview of the tools that can help file this sort of issue, followed by some specific examples of what can cause this kind of failure. I suspect the “Segmentation Fault” is caused by insufficient memory. 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 rea

Are you sure it isn't an auth event? Without going into too much detail, it's possible, but unlikely given the methods in the stack that led to the deadlock. Auth events are primarily for security and integrity protection. What are you actually doing to the files? I suspect you're copying them, but wouldn't mind confirming that. The method on the stack is -[MyPathHelper fetchFileTypeForFileAtPath:], which is mostly used for scanning and reporting. Having said that, my suggestion to whitelist RevisionD is really about what it does, not how it's doing it. I was mostly thinking of its interaction with extended attributes, as we see the target threads touching those as well. I will post more detail in the FB ticket, and we can dive deeper there.

I'd like you to try something — go into your scheme, and uncheck Debug Executable from the Run tab. When you click Run, Xcode will run your app with going through the process to attach LLDB. Does the launch performance after this look more like you're expecting? If so, we'd really appreciate getting diagnostics so we can look into the root cause of this slow down. Add the following to your ~/.lldbinit file, and the restart Xcode to ensure this is enabled: log enable gdb-remote packets --timestamp -f /tmp/log_packets.txt Before you launch your app, run the following in Terminal: sample lldb-rpc-server 60 --wait -file /tmp/sample.txt Attach both of those files that those commands placed in /tmp on your bug report, and let me know here when that's done. I also suggest removing the log line from ~/.lldbinit so it's not always logging debugger packets. @Code4Food, it'd be helpful if you could run the same tests and collect the same data, and attach them to your own bug report. P

If an app assumes it's appending only one path component on a directory it owns (like inside a package), it may think it is safe, but it can be tricked into overwriting files at unexpected file system locations.

Thank you for the additional detail on the EDR/auto-brightness inconsistency — that's a useful and distinct report. Please do file a bug report for this second issue. Include a description of the two behaviors (auto-brightness on vs. off) and the inconsistent state you described. I'll check the status next time I do a sweep of forums posts where I've suggested bug reports and post any information about changes I am able to share to this thread. I’m happy to make sure your bug gets routed to the right team. Bug Reporting: How and Why? has tips on creating your bug report.

I was able to replicate this issue in a very simple way, within a new project created with the standard Xcode template, to which I added a Swift Package as a library (MyLibrary). This is the Package definition: // swift-tools-version: 6.3 // The swift-tools-version declares the minimum version of Swift required to build this package. import PackageDescription let package = Package( name: MyLibrary, platforms: [.iOS(.v18)], products: [ // Products define the executables and libraries a package produces, making them visible to other packages. .library( name: MyLibrary, targets: [MyLibrary] ), ], targets: [ // Targets are the basic building blocks of a package, defining a module or a test suite. // Targets can depend on other targets in this package and products from dependencies. .target( name: MyLibrary, path: Sources/MyLibrary ), ], swiftLanguageModes: [.v6] ) If the target name is equal to library name (MyLibrary) the preview of SwiftUIView works as expected. If I change the target name (for example MyLibrar

What I’m trying to understand is whether Apple supports any path for this on macOS that does NOT require restricted entitlements or paid-program-only capabilities. So, let me lay out the state of things that you listed: Both DriverKit and Core HID require restricted entitlements. All DriverKit entitlements have Development Only variants which allow those entitlements to be used in development signed builds without any approval (they're added through the portal like any other entitlement). Virtual Core HID does not currently have a development variant, but that's an issue I'm looking into correcting (r.173531752). In both cases, that means using these entitlements currently requires joining the paid program. If you'd like to see us expand these to the free account as well, please file a bug asking for that and then post the bug number back here. Also, to be clear, that is a serious request - I'd like to look at expanding the availability of these entitlements, but that's hard to justify without a bit