“file uri scheme”

Same error, for ~2hrs now. But curl returns successful, confusingly. curl -v https://ppq.apple.com Host ppq.apple.com:443 was resolved. IPv6: (none) IPv4: 17.33.192.136, 17.33.193.105, 17.33.194.109 Trying 17.33.192.136:443... Connected to ppq.apple.com (17.33.192.136) port 443 ALPN: curl offers h2,http/1.1 (304) (OUT), TLS handshake, Client hello (1): CAfile: /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/certifi/cacert.pem CApath: none (304) (IN), TLS handshake, Server hello (2): (304) (IN), TLS handshake, Unknown (8): (304) (IN), TLS handshake, Certificate (11): (304) (IN), TLS handshake, CERT verify (15): (304) (IN), TLS handshake, Finished (20): (304) (OUT), TLS handshake, Finished (20): SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF ALPN: server accepted h2 Server certificate: subject: CN=ppq.apple.com; O=Apple Inc.; ST=California; C=US start date: Jan 21 17:47:41 2026 GMT expire date: Feb 17 18:28:16 2027 GMT subjectAltName: host ppq.apple.com m

Perhaps I didn't explain myself well. I wasn't making assumptions about how the the APIs operate - the only thing I was claiming (well trying to) was that paths provide the concept of file location and in certain contexts that concept matters to GUI apps (with the NSBrowser example being an obvious one). Sure. And, to be clear, I don't mean that paths don't EVER have a place and/or aren't a good solution. However, I do think those use case are more limited then they seem and that most interactions with files are better handled through object references (which are tied to a specific file system object), NOT paths (which describe a location in the hierarchy). Our APIs don't do a very good job of expressing that idea, but APIs like reference URLs and bookmarks are actually object reference APIs, not just weird ways of storing paths. Very interesting. Yeah I use that (watch root) With the watch root flag set it does seem to just track whatever is at the path. Ahh... Yes, you're right. I

This has been happening an awful lot for me lately as well. Here's an example error message: + rustup show Default host: x86_64-apple-darwin rustup home: /Users/local/.rustup info: syncing channel updates for 'stable-x86_64-apple-darwin' error: failed to download file error=Reqwest(reqwest::Error { kind: Request, url: https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256, source: hyper_util::client::legacy::Error(Connect, ConnectError(dns error, Custom { kind: Uncategorized, error: failed to lookup address information: nodename nor servname provided, or not known })) }) To debug I've tried hitting that same URL from Xcode Cloud using curl as well and get a similar DNS error, so it seems the error is with the Xcode Cloud DNS setup rather than rustup

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