“file uri scheme”

Thanks for the reply Quinn. We've spent the time looking into the options you suggested. Am I right in assessing that each needs some level of code modification of the app under test? We're reluctant to add test hooks that would end up in released product, esp networking code, because this app is a medical device that already has FDA trial approval based on SBOM documentation showing no networking libraries (and thus a low cybersecurity risk rating), and no operating differences between tested and released .ipa files. Modifying the iPad's environment is kosher which is why the helper app was helpful.

There is no difference in behaviour. Please send us the transaction ID of the two transactions via a feedback assistant ticket to investigate further. Thank you How to File Feedback assistant ticket? https://feedbackassistant.apple.com/ Login with your developer account, Choose iOS & iPadOS” Choose AppStore “Incorrect & Unexpected behavior Input the issue description and title. Upload attachements Click “Submit” Copy the Ticket ID “FBxxxxxxx” and let us know.

Hi, this is an assertion in the static linker. In cases like this, it automatically creates a snapshot of the invocation that would allow us to reproduce it locally. The path to it is mentioned here in: ld snapshot written at /tmp/AIChatDoctor-2026-03-10-150254.ld-snapshot Could you please file a feedback report with the snapshot attached, so that we can take a closer look? - Damian

Hello, This is an issue we're aware of, but we're not aware of any recommended workaround so far. If you find something that helps you avoid the issue, please share it with the community by posting it here. Even though we're aware of this issue, we still encourage you to open a bug report, and post the FB number here once you do. The specific info you include your bug report might help our investigation, and filing the bug report you to get notified when it is resolved. Bug Reporting: How and Why? explains how you can open a bug report. Thank you for your patience, Richard Yeh  Developer Technical Support

That’s an amazing question where I would love to invite experts of that implementation here as I know how difficult is to implement that o a URLSession that will match on the server to make it resumable. I’m not an expert but this question requires an expert to go over the documentation you need to have a successful implementation. Because the implementation of IETF draft that was actively evolving, the auto-magic requires your server to perfectly match a frozen-in-time version of that draft, down to the exact HTTP framing looks like as I’m going over the documentation. I was educating myself on the IETF draft is now much further along. However, the implementation is hardcoded to look for the 104 informational response. If you want the OS auto-magic, your server must implement the Draft 03 behavior, if I read it correctly. The resumable upload protocol is currently under development and standardization efforts within the IETF. This protocol enables robust and resumable file transfers, allowing applic

Bug filed: FB22189729

Hello @dustinw1 We are investigating this issue, and will need to determine the impact of the change before deciding to keep the implementation or revert. To that end we need some more information: What 3rd party product is showing this behavior? If you know, what is the Bluetooth Chip Vendor and LMP Version? Are you seeing the issue with EV3, 2-EV3 or both packet types? And at some point, we might need some diagnostic logs from your end as well. To that end, the best would be to file a Bug Report and give as much detail as you can there. Once done, please post the Feedback ID of your report here, and make sure to @mention me so I can route the bug to the team right away. Argun Tekant /  WWDR Engineering / Core Technologies

Based on the above I tried reproducing this with a test project. And lo! it’s trivial to reproduce: I started with Xcode 26.3 without the Metal Toolchain 26.3 component installed. I created a new project from the iOS > App template. In the General tab of the target editor, I removed the Mac (Designed for iPad) destination. And added the Mac (Mac Catalyst) destination. I selected My Mac (Mac Catalyst) as the run destination. I chose Product > Build; the project built without any warning. In Xcode > Settings > Components, I installed the Metal Toolchain 26.3 component. I chose Product > Clean. And then Product > Build. I now see a build warning: ld: warning: search path '/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.7003.10.hJke6J/Metal.xctoolchain/usr/lib/swift/maccatalyst' not found Given the above, I can only conclude that this is a bug. I did some digging and was unable to find any more backstory (for example, I thought that someone might’ve filed

Cool. I consider this to be a problem with Xcode’s build system, but it’s an understandable one. Xcode knows that your tool depends on this library — because it adds an import of it — but, being a command-line tool, it doesn’t have anywhere to embed the library. It should embed it in the container app, but it’s clearly not doing that. I think it’s worth filing a bug against Xcode about that. And if you do, please post your bug number, just for the record. As to a workaround, there’s a couple of ways to approach that. The first is the obvious one we’ve been discussing here: Add a dummy use of Subprocess within your app. Xcode will embed libswiftCompatibilitySpan.dylib, because it knows that your app needs it, and your tool can pick it up from there The other option is to embed the library explicitly. This is complicated by the fact that the library exists within a toolchain, so it’s not clear how to reference it [1]. For the moment I recommend that you go with the first option. I’m going to talk to so

Hi @Engineer , I'm wondering if you know has there been any update on this? I have filed feedback with system diagnoses and BLE packet sniffing data at the following link: FB21147185 Thanks

In the Network framework header file I have found the following doc comment for NWConnection.startDataTransferReport: /// Start a new pending data transfer report on a connection. Multiple /// reports may be created for a single NWConnection. The report begins /// capturing data when the connection moves to the .ready state, or when /// the report is created (whichever occurs last). So it seems that not capturing the TLS handshake is the intended behavior. Too bad! I also noticed that TLS alert messages are not included in the data report.