“file uri scheme”

The only way out of it was to create a build post-action script to generate the missing dsym file. Here is the gist of the script: set -euo pipefail if [ -z ${ARCHIVE_PATH:-} ]; then exit 0 fi APP_PATH=$ARCHIVE_PATH/Products/Applications/App_Product_Name.app if [ ! -d $APP_PATH/Contents ]; then exit 0 fi BIN=$APP_PATH/Contents/Frameworks/Framework_Name.framework/Framework_Name OUT=$ARCHIVE_PATH/dSYMs/Framework_Name.framework.dSYM OUT_DWARF=$OUT/Contents/Resources/DWARF/Framework_Name if [ ! -f $BIN ]; then exit 0 fi if [ ! -f $OUT_DWARF ]; then mkdir -p $ARCHIVE_PATH/dSYMs rm -rf $OUT xcrun dsymutil $BIN -o $OUT fi if [ ! -f $OUT_DWARF ]; then exit 1 fi BIN_UUIDS=$(xcrun dwarfdump --uuid $BIN | awk '{print $2}' | sort) DSYM_UUIDS=$(xcrun dwarfdump --uuid $OUT_DWARF | awk '{print $2}' | sort) if [ $BIN_UUIDS != $DSYM_UUIDS ]; then exit 1 fi

Which bit? I was unaware that I could simply run both mitmproxy as well as rvictl and tcpdump at the same time. However I did just that; inspecting the trace file (in Wireshark) revealed the following (bundle name redacted): [Process Information: com.apple.WebKit(1114) [(1111)]] [Id: 1114] [Name: com.apple.WebKit] But I guess you are right in that this does not tell me anything I did not already know. Furthermore I do not see any TLS handshake messages after the server sent its certificate along with the Finished message which confirms that there might be some sort of pinning going on.

I've been working with SpeechAnalyzer.start(inputSequence:) on macOS 26 and got streaming transcription working. A few things that might help: Make sure the AVAudioFormat you use to create AnalyzerInput buffers exactly matches what bestAvailableAudioFormat() returns. Even subtle mismatches (e.g., interleaved vs non-interleaved, different channel layouts) can cause the nilError without a descriptive message. I found that feeding buffers that are too small (< 4096 frames) occasionally triggers this error. Try using larger chunks â I settled on 8192 frames per buffer. The bufferStartTime parameter needs to be monotonically increasing and consistent with the actual audio duration. If there are gaps or overlaps in the timestamps, the stream mode can fail silently or throw nilError. Instead of replaying a WAV file as chunked buffers, I'd suggest testing with live audio from AVCaptureSession first. In my experience, live capture â AnalyzerInput works more reliably than simulated streaming from a file

Mystery (partially) solved. I just took a sneak peak at the extended attributes of the .DS_Store file and some have a resource fork (probably the ones that were failing to copy I BET!). So appears to be the same failure we are talking about here: https://developer.apple.com/forums/thread/814076 .DS_Stores on the NAS's with resource forks.. maybe that will help you figure out leaky compression

Interesting and really good information to know! IF this is in fact a compressed file, then just copying the resource fork won't actually work. There's an additional UF_COMPRESSED file flag that needs to be set, which then marks the file as compressed so that the system knows to retrieve and decompress the file contents when the file itself is opened. If you read through the previous threads, you can see that this flag is what ends up hiding the presence of the resource fork from the rest of the system. However, if it was a compressed file then it should never have been written to the NAS device as a compressed file. All of our copy engines would have either automatically decompressed it (this is what happens if you copy the file without knowing about file compression) or noticed that the target DIDN'T support compression... and decompressed the file. Blame is definitely the critical factor here. The worst-case scenario

Filed here: FB22276321 (Xcode Cloud build encountering persistent Connection Refused error)

Your code that wraps UIActivityViewController with UIViewControllerRepresentable and presents it in SwiftUI looks good to me. I've tried running the code on my iOS simulator (iOS 26.2 23C54) and here is the behavior I see: When sharing one single item, the code demonstrates the behavior as I described. When sharing two items (by using var shareItems: [Any] { [textItem1, textItem1] }), the Save as field isn't editable, and so there is indeed no way to specify the file names. Also, two files are generated, one for each item. So it's not that the way you present UIActivityViewController has anything wrong; it's that UIActivityViewController doesn't allow you to specify the file names when sharing multiple items. I don't see any way that can change the behavior because the UI of UIActivityViewController is system-provided. Please feel free to file a feedback report to request the feature you would like to have. For now, you might consider sharing one single item, if that is app

If you consistently see this, please file a bug report with a link to a build, and details of the URL that is unavailable during the build. Please post the FB number here for the record. — Ed Ford,  DTS Engineer

I think the idea you're getting at here is that you should be able to point your copy engine at any point in the file system, have it do the right thing based only on the information it's provided by copyfile, not external knowledge (like the full source path). [...] That's a lovely idea, but for better or worse, macOS just does not work that way. [...] but if you want to work with the full system... Well, I don't think there's any way to do without grappling with a whole bunch of edge cases. Well I did not directly point copyfile at .DS_Store and tell it to do the thing. I started a recursive copy on a folder, which happens to have a .DS_Store file in it. And on macOS just about every folder the user views in Finder will have one of those hidden in there, unfortunately. The folder I was copying was on a NAS, has like 24 videos in it. I'm doing this intentional slow copy to test everything out. So the copy gets like 98% done and then it needs a diaper change on the .DS_Store file! I

[quote='880540022, DTS Engineer, /thread/807771?answerId=880540022#880540022'] I think you're seeing #2, but I want to confirm that. [/quote] AFAICT it seems to be #1. There was a small issue in the test project I submitted to FB22267894 [1], but when that is changed, if I set a breakpoint at createItem(named:type:inDirectory:attributes:) (for example) and then touch /Volumes/Sample/hi, I will reach the breakpoint in createItem and see the error that function outputted in Terminal. For example if I change createItem to return EIO, the touch command in Terminal then shows an input/output error. [1] Namely, my lookupItem sample implementation returned ENOSYS for any lookup other than the single static file implemented in the test file system. If it is changed to return ENOENT instead, then I can reach the createItem breakpoint.

I attach this log to the FB. Thanks for investigating. Failed to request default share mode for fileURL:file:///var/mobile/Containers/Data/Application/453B6EDB-3C76-4D2D-8355-702D4BD0263A/Documents/name%20accentue%CC%81.pdf error:Error Domain=NSOSStatusErrorDomain Code=-10814 (null) UserInfo={_LSLine=1796, _LSFunction=runEvaluator} Only support loading options for CKShare and SWY types. error fetching item for URL:file:///var/mobile/Containers/Data/Application/453B6EDB-3C76-4D2D-8355-702D4BD0263A/Documents/name%20accentue%CC%81.pdf : Error Domain=NSCocoaErrorDomain Code=256 The file couldn’t be opened. error fetching item for URL:file:///var/mobile/Containers/Data/Application/453B6EDB-3C76-4D2D-8355-702D4BD0263A/Documents/name%20accentue%CC%81.pdf : Error Domain=NSCocoaErrorDomain Code=256 The file couldn’t be opened. Received port for identifier response: <(null)> with error:Error Domain=RBSServiceErrorDomain Code=1 Client not entitled UserInfo={RBSEntitlement=com.apple.runningboard.p

Please file a Feedback report using Feedback Assistance, then post the ID here.

@lateef Please file a code-level support request including your Team ID for assistance.