Clarification on Disk Write Limits (bug_type 145) and Cross-Volume Write Amplification

Hello Apple Developer Support and Community,

I am a senior software engineer investigating a Disk Writes Resource Violation (bug_type 145) for a photo-management application (BeePhotos v2.3.0). We observed a violation where the app dirtied approximately 1GB of file-backed memory in just 48 seconds, triggering a resource report.

[Core Diagnostic Data]

The following data is extracted from the .crash report:

  • Event: disk writes
  • Action taken: none
  • Writes caused: 1073.96 MB over 48.28s (Average: 22.24 MB/second)
  • System Limit: 1073.74 MB over 86,400 seconds (Daily limit)
  • Device: iPhone 15 Pro (iPhone16,2)
  • OS Version: iOS 26.4 (Build 23E244)
  • Free Space: 3852.25 MB (Approx. 3.8 GB)

[Implementation Details]

Our application performs the following sequence for a 1GB video download:

  1. Download: Uses NSURLSessionDownloadTask to download the file to the system-provided location URL (in the /tmp or com.apple.nsurlsessiond directory).
  2. Move: In didFinishDownloadingToURL, we move the file to the App’s sandbox Library/Caches directory using FileManager.default.moveItem(at:to:).
  3. Save: We then add the file to the Photo Library via PHAssetCreationRequest.addResource(with:fileURL:options:) using the local URL in Library/Caches.

[Technical Questions]

I suspect the 1GB download is being "amplified" into ~3GB of total physical writes, and I would like to confirm the following:

  1. Cross-Volume Move: Does moving a file from the nsurlsessiond managed temporary directory to the App’s sandbox Library/Caches constitute a Cross-Volume Move on APFS? If so, does this effectively double the write count (1GB download + 1GB copy-on-move)?
  2. PHPhotoLibrary Ingestion: When using PHAssetCreationRequest, does the system perform another 1:1 data copy of the source file into the assets database? Would this result in a 3rd GB of writing?
  3. Low Disk Space Impact: Given the device only had 3.85 GB free, does the system’s "low disk space" state (near the 150MB threshold) increase the overhead for metadata updates or physical write amplification that counts towards this limit?
  4. Best Practices: To stay within the daily 1GB budget for high-resolution media, is it recommended to call PHAssetCreationRequest directly using the location URL from didFinishDownloadingToURL to avoid intermediary copies? Are there any permission or lifecycle risks with this approach?

Any insights from the Apple engineering team or the community on how to minimize the write footprint during high-speed ingestion would be highly appreciated.

Best regards

Clarification on Disk Write Limits (bug_type 145) and Cross-Volume Write Amplification
 
 
Q