“file uri scheme”

What makes copies slow isn't the writes; it's the reads, since the data still has to be pulled off the disk so it can be sent back to write. That makes sense and does indeed seem to be the reason for the speed after first import (the developer of LibZip said much the same recently when I was asking for more details about how it takes advantage of file cloning). The initial read of the large file takes a while, but after that saving is fast, even on reopening the file (because it is read on open). Anyway, thanks again - this discussion has lead to some nice optimisations in the way I'm working with LibZip as well as working around the save error.

@voyage11 Please file a code-level support request with your Team ID for assistance.

@SamuelOsondu Did you use the following link to file a code-level support request: https://developer.apple.com/support/technical If not, please use this link to file a code-level support request that includes your Team ID.

It took me a little bit to realize that tapping on the text in the Share to Files interface provided a way to change the file name - when I share one item. In some online tutorials there was a way to set the full filename (like Export.csv) - but maybe that's only when writing to the app's file directory. Would you agree? I can't really think of a clean way to be able to name 2 files in that interface - so I fully understand why that's not available - and therefore I don't plan to proceed to a feedback for this. I should be able to combine elements so that I'm only sharing 1 item in for my original request. Could you clarify how DTS works now relative to these questions answered here on the forum? Since I did ask for a DTS - does this count as one? It doesn't matter to me right now because my dev account will renew soon. Thanks so much!

Thanks Apple, I filed DTS ticket, and get the solution from Apple Engineer. It is resolved.

Hi @hungng Could you try running the Spatial Rendering App template and see if you can reproduce the issue there? To do so: Create a new project in Xcode by choosing File > New > Project. Navigate to the macOS section of the template chooser. Select the Spatial Rendering App template. Let me know if you run into the same issue with the template, thanks!

Hi, If this is still reproducing, could you file a feedback report, and possibly attach a demo Xcode project that is reproducing the issue?

Thank you for your post. I see that you have already submitted those files for the issue and appreciate your efforts. The team is currently experiencing high workloads and only communicates when a fix is released due to company policies. I can assure you that this issue is on the team’s priority list. It has been marked as an existing bug and will be addressed as soon as a fix is available. Once the fix is released, the team will notify you via Feedback Assistant to test the new release. I understand that the process can sometimes be slow, and this bug may have been present for a longer period than anticipated. Albert Pascual
  Worldwide Developer Relations.

Please try again after a restart. I went through this process myself and hit very similar symptoms. I found that fskitd had a bunch of threads stuck like this: 816 _dispatch_call_block_and_release + 32 (libdispatch.dylib + 7004) [0x19b4ceb5c] 816 ??? (fskitd + 132900) [0x100988724] 816 ??? (fskitd + 86796) [0x10097d30c] 816 ??? (fskitd + 87588) [0x10097d624] 816 ??? (fskitd + 50740) [0x100974634] 816 objc_sync_enter + 20 (libobjc.A.dylib + 70452) [0x19b245334] 816 816 __ulock_wait2 + 8 (libsystem_kernel.dylib + 60532) [0x19b656c74] *816 ??? (kernel.release.t6031 + 6477368) [0xfffffe0008ea1638] (blocked by turnstile waiting for fskitd [634] thread 0x30444d) Worse yet, the number of threads kept growing, every time I retried the mount command! I was able to clear this by restarting, after which the mount command worked as expected. I did some spelunking based on internal resources and it seems that these threads are deadlocked due to some previous error starting the extension. Hence my idea to restart, in an a

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