Post

Replies

Boosts

Views

Activity

Reply to Supported read/write handoff of a sandbox-container PNG to Preview using NSWorkspace
Hi Quinn, I completed the TextEdit comparison on macOS 26.6.2. Both tests used the same Apple Development-signed sandboxed app and the same NSWorkspace opening method. A (temporaryDirectory): The original text file was updated successfully after editing and pressing Command-S. Its size changed from 33 to 40 bytes. B (container Documents): The original text file was also updated successfully. Its size changed from 33 to 39 bytes. In both cases, the original file's content, SHA-256, and modification time changed. The one-byte difference is due to a trailing newline in A. Unlike the earlier PNG/Preview tests, TextEdit successfully saved changes to the original files in both locations. The earlier Preview test used Rotate Left without explicitly pressing Command-S, whereas this TextEdit test used Command-S. This suggests that the temporary directory alone does not explain the issue, although the file type, application, and save behavior also differ. What would you recommend investigating next? Thank you!
Topic: App & System Services SubTopic: Core OS Tags:
3d
Reply to Supported read/write handoff of a sandbox-container PNG to Preview using NSWorkspace
Hi Quinn, I tested both locations with synthetic PNGs on macOS 26.6.2 (25G83), using Preview 11.0 (1113.5.3). A used FileManager.default.temporaryDirectory. B used FileManager.default.url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true). I confirmed that B resolved to the app container's Documents directory, not the user's ordinary Documents folder. Both cases used the same Apple Development-signed sandboxed app, identical initial PNG bytes, atomic writing, and the same NSWorkspace open call. The storage root, distinguishing A/B filename labels, and creation times differed. For each PNG, I selected Rotate Left once in Preview without pressing Command-S, waited at least 10 seconds, and inspected the original file. In both cases, Preview changed the document title to a copy. Both originals remained 640 × 360 pixels and 10,684 bytes, with unchanged SHA-256 and modification timestamps. When closing B, Preview asked whether to keep the new copy and stated that the original document would not be changed. I cancelled without saving a separate copy. The signed app has these three entitlements, all set to true: com.apple.security.app-sandbox com.apple.security.files.user-selected.read-write com.apple.security.files.bookmarks.app-scope Moving the PNG to the container's Documents directory did not change the observed behavior. What would you recommend checking next? Thank you!
Topic: App & System Services SubTopic: Core OS Tags:
6d
Reply to Supported read/write handoff of a sandbox-container PNG to Preview using NSWorkspace
Hi Quinn, Thank you for looking into this. It is A: FileManager.default.temporaryDirectory. The app creates a subdirectory beneath the URL returned by that API: FileManager.default.temporaryDirectory .appendingPathComponent("ShelfDragPoC/Captures", isDirectory: true)The captured image is saved as a PNG using Data.write(to:options: .atomic), and the resulting URL is passed to Preview via NSWorkspace.open(_:withApplicationAt:configuration:completionHandler:). The minimal reproduction project uses the same API and write method, with a different subdirectory (PreviewSandboxRepro/Captures) and a synthetic PNG. Neither implementation explicitly calls NSTemporaryDirectory() or uses a separately chosen temporary-directory root. Thank you!
Topic: App & System Services SubTopic: Core OS Tags:
1w
Reply to Supported read/write handoff of a sandbox-container PNG to Preview using NSWorkspace
Hi Quinn, I completed the TextEdit comparison on macOS 26.6.2. Both tests used the same Apple Development-signed sandboxed app and the same NSWorkspace opening method. A (temporaryDirectory): The original text file was updated successfully after editing and pressing Command-S. Its size changed from 33 to 40 bytes. B (container Documents): The original text file was also updated successfully. Its size changed from 33 to 39 bytes. In both cases, the original file's content, SHA-256, and modification time changed. The one-byte difference is due to a trailing newline in A. Unlike the earlier PNG/Preview tests, TextEdit successfully saved changes to the original files in both locations. The earlier Preview test used Rotate Left without explicitly pressing Command-S, whereas this TextEdit test used Command-S. This suggests that the temporary directory alone does not explain the issue, although the file type, application, and save behavior also differ. What would you recommend investigating next? Thank you!
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
3d
Reply to Supported read/write handoff of a sandbox-container PNG to Preview using NSWorkspace
Hi Quinn, I tested both locations with synthetic PNGs on macOS 26.6.2 (25G83), using Preview 11.0 (1113.5.3). A used FileManager.default.temporaryDirectory. B used FileManager.default.url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true). I confirmed that B resolved to the app container's Documents directory, not the user's ordinary Documents folder. Both cases used the same Apple Development-signed sandboxed app, identical initial PNG bytes, atomic writing, and the same NSWorkspace open call. The storage root, distinguishing A/B filename labels, and creation times differed. For each PNG, I selected Rotate Left once in Preview without pressing Command-S, waited at least 10 seconds, and inspected the original file. In both cases, Preview changed the document title to a copy. Both originals remained 640 × 360 pixels and 10,684 bytes, with unchanged SHA-256 and modification timestamps. When closing B, Preview asked whether to keep the new copy and stated that the original document would not be changed. I cancelled without saving a separate copy. The signed app has these three entitlements, all set to true: com.apple.security.app-sandbox com.apple.security.files.user-selected.read-write com.apple.security.files.bookmarks.app-scope Moving the PNG to the container's Documents directory did not change the observed behavior. What would you recommend checking next? Thank you!
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
6d
Reply to Supported read/write handoff of a sandbox-container PNG to Preview using NSWorkspace
Hi Quinn, Thank you for looking into this. It is A: FileManager.default.temporaryDirectory. The app creates a subdirectory beneath the URL returned by that API: FileManager.default.temporaryDirectory .appendingPathComponent("ShelfDragPoC/Captures", isDirectory: true)The captured image is saved as a PNG using Data.write(to:options: .atomic), and the resulting URL is passed to Preview via NSWorkspace.open(_:withApplicationAt:configuration:completionHandler:). The minimal reproduction project uses the same API and write method, with a different subdirectory (PreviewSandboxRepro/Captures) and a synthetic PNG. Neither implementation explicitly calls NSTemporaryDirectory() or uses a separately chosen temporary-directory root. Thank you!
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
1w