#1624 Hang opening iCloud PDFs: recentDocuments alias resolution

[Jean Peuplus]

Hello,
Below is a report generated by my good friend Claude regarding hangs when opening new pdf files. I used Claude in order to solve the issue and since my english is catastrophic, I asked for a report too.

Overview:
Opening a PDF in iCloud Drive that Skim has never opened before blocks the main thread for several seconds before the window appears. Re-opening the same file afterwards is instant. Preview opens the same files instantly. Deleting the recentDocuments array from Skim’s bookmarks preferences fixes it.

Steps to reproduce:

1. Keep the Documents folder in iCloud Drive (“Optimize Mac Storage” is off).
2. Use Skim normally for several weeks until recentDocuments in net.sourceforge.skim-app.skim.bookmarks.plist holds 50 entries, many of them iCloud Drive files.
3. In the Finder, double-click a PDF in iCloud Drive that has never been opened in Skim.

Actual results:
The document window takes about 5 seconds to appear, and Skim is unresponsive meanwhile. It happens with every new file in iCloud Drive, but not when re-opening a file that was opened recently.

Expected results:
The window opens immediately, as it does in Preview.

Workaround:
Quit Skim, then run defaults delete net.sourceforge.skim-app.skim.bookmarks recentDocuments. New files open instantly afterwards.

Configuration:

Skim 1.7.17 (169)
macOS 26.7.1 (25G241)
Apple Silicon, MacBook Air M3 2024
Regression range: unknown. The slowdown appeared gradually over weeks of use, which is consistent with the recent documents list filling up.
Localization: French

Sample (attached, taken during the hang):
For 2429 of 2443 samples, the main thread is blocked in:
-[SKMainWindowController windowDidLoad] → -[SKBookmarkController recentDocumentAtURL:] → -[SKAlias fileURLAllowingUI:] → URLByResolvingBookmarkData → DownloadCloudDocumentSync → _dispatch_group_wait_slow
The sample covers only part of the hang.

Hypothesis (not verified):
recentDocumentAtURL: seems to resolve the alias of each recent document to compare it with the file being opened. When an entry points to an iCloud file that has been moved, deleted or evicted, the resolution triggers a synchronous iCloud download on the main thread. Comparing paths or file IDs first, or resolving off the main thread with options that avoid cloud downloads, might avoid the hang.

Additional information:
I didn’t capture Console logs, but I can reproduce the hang again and send them if needed.
I can provide my backed-up recentDocuments preferences off-list if that helps reproduce the issue.

[Christiaan Hofman]

Weird, we already do pass the withoutMounting option to avoid actually downloading cloud documents when finding a URL (as Claud apparently suggested). (the other suggestions would not help, when the file was not known before we always will have to end up checking every bookmark.) So I am surprised that this happens, iCloud apparently does not honor this. As iCloud does not do what it is supposed to do, and there is not other option available, I really don't see how we can fix this issue,

For you it is probably a better idea to not remember the last viewed page or snapshots. In that case, Skim will not look up the recent documents on opening. These feature are apparently not compatible with iCloud.

[Christiaan Hofman]

Reconsidering my last comment, remembering last pages or snapshots may not be the only access point, so without it you may still see delays.

Still, the documentation says that resolving the bookmark data should not download iCloud documents, especially with the options we gave them. So this report is truly strange. As we do everything we can possibly do, following Apple's documentation, I can only conclude that Apple is lying and buggy. We cannot do anything about this, and dropping the features for every user will not be an option.

For you, the option you have is to set the SKMaximumDocumentPageHistoryCount hidden preference to 0. See the Wiki for details. I see no other way around this.

[Jean Peuplus]

Thank you for your help!

[Christiaan Hofman]

I wonder whether just not remembering the viewed page or snapshots already does the trick.

You may also just reduce the page history count from 50 (e.g. 10) using the hidden preference to reduce the wait.

I still have no idea why it would download the iCloud files, it really shouldn't.

[Christiaan Hofman]

I may have found a way top avoid this slowdown. However, I am unable to check whether this works myself. I uploaded a test version to try this out at https://skim-app.sourceforge.io/Skim.zip. Could you download this and tryit out to see whether this fixes this? Make sure you don't have the hidden preference for the maximum document count set to zero. (See the Wiki on how to reset this).

[Jean Peuplus]

Thanks for the test build! Unfortunately I can’t reproduce the hang anymore: I had already deleted my recentDocuments (with no backup), and removing the local copies of iCloud files that are in the history doesn’t trigger it. I also filled the history with a bunch of new PDFs, but that didn’t trigger it either, so I can’t confirm the fix in practice.

Here is a comment by Claude about a possible remaining case:
Looking at the build, I see fileURLAllowingUI: now checks the stored NSURLPathKey first and only resolves the bookmark when that path is unreachable. That should cover evicted iCloud files. For entries whose file was moved or deleted, it still falls back to URLByResolvingBookmarkData, which may be what triggered the original hang.

I’ll keep using the test build and will report back with a new sample if the delay comes back.