Binarynights
Folder icon support on macOS Tahoe and performance improvements
Finder on macOS Tahoe introduced a big change by allowing users to customize folder icons. The last applied color tag now determines the folder color, and it is also possible to add icons to folders to make them stand out.
With ForkLift 4.6.1, we have updated how folder icons are handled. ForkLift now inherits folder colors from Finder, and when you assign a color tag in ForkLift, the folder color updates accordingly. ForkLift also displays custom icons that were added in Finder. However, due to missing system APIs, adding custom folder icons directly in ForkLift is not possible at this time.
We have also fixed multiple possible memory leaks and improved overall memory usage. This results in a more stable and efficient experience.
PDF preview fixes and iCloud tag improvements
In addition, this version includes several smaller improvements. You can now edit file favorites directly from the sidebar, use the Tab key to autocomplete tags more reliably, and benefit from improved information display in the Status bar and in the Preview pane.
We were also able to restore the full functionality of the PDF viewer in the Preview pane. It is now again possible to customize preview options through the right-click context menu, and text selection inside PDF previews has been re-enabled.
It is now also possible to remove the last remaining tag on iCloud Drive, and we have resolved an issue where pressing the Tab key during tag autocompletion could cause the tag to disappear.
Full list of changes:
New
- ForkLift now colorizes folder icons on macOS Tahoe the same way as Finder, inheriting and applying the assigned colors
- ForkLift displays customized folder icons set in Finder, however, customizing folder icons directly in ForkLift is not supported
Improvements
- Improves the display of aggregated date information in the Preview pane when multiple files are selected
- Adds an alert when iCloud Drive is busy and interaction is not possible, to clarify why an action cannot be executed
- Adds an option to edit file favorites from the context menu in the Sidebar
- Improves memory usage
Fixes
- Fixes an issue that made the file view jump in List View after renaming or deleting files when Group by was enabled
- Fixes multiple possible memory leaks
- Fixes an issue that didn’t show the lock icon on locked folders when icon preview is enabled (the lock icon doesn’t show up on files starting from this version)
- Fixes an issue in the Status bar, which didn’t update the displayed info correctly after folders were expanded and collapsed
- Fixes an issue of the preview of PDF file in the Preview Pane introduced in version 4.3.5, which made it impossible to select text inside the preview and to use the right-click context menu to customize the preview options. This version restores the previous functionality
- Fixes an issue that made it impossible to remove the last tag on iCloud Drive when there was only one tag remaining
- Fixes an issue where pressing the Tab key while autocompleting a tag made the tag disappear
On Sequoia my folder icon no longer shows with this update.
In fact all folder icons don’t display on Sequoia with this update. If I click Cmd-R to refresh in Columns view they briefly appear and then disappear.
What macOS version do you use exactly? Please also write us at support [at] binarynights [dot] com and send us the macOS version and also a screen recording if possible
Mac Sequioa 15.7.5 (24G624).
Folders like “~/Documents”, ~/Downloads”, “~/Library””, “~/Music” etc don’t have the folder icon. If a user folder has a custom icon as set in Finder Properties that does not show either.
Seems to be OK in Tahoe.
Thank you for clarifying. So, when you said “all folder icons don’t display on Sequoia” you meant that these special icons disappear from the folders? The folder icons are there?
Actually all file and folder special icons are not displayed in this version of FL on Sequoia.
In “View As Icons” on your home folder press Cmd-R to refresh and the icons briefly appear then disappear again.
So, the folders are there but not the icons on them. Right? What file specific icons do you mean exactly? If possible, please send us a screen recording. You can also compare the previous version and the new version with each other in the video. `you can download the previous version from here: https://download.binarynights.com/ForkLift/ForkLift4.6.zip
Yes, the icons are not there.
All you have to do is test this yourself on Sequoia!
Unfortunately, that is not all we have to do. But this issue will be fixed on Sequoia with the next version. Unfortunately, the API that we have switched to has some bugs, so it has issues on Tahoe as well but we won’t use the API if the user is still on Sequoia.
Unfortunately, immediately after the update, some icons stopped displaying correctly. For example, a Premiere project file is now shown simply with a blank white document icon. What is interesting is that when ForkLift launches, during the first second all icons display correctly, and the folders also look slightly different (apparently as they did before), but then suddenly the file icons switch to blank white sheets, and the folders change to new, slightly modified icons.
The macOS version is up to date: 26.4.1
If I click Cmd-R to refresh in Columns view they briefly appear and then disappear.
Does this happen with other file types as well?
Differently. The .xmp files now have no icons at all. Honestly, I actually wouldn’t want to have Preview instead of icons in “as List” view. Or at least it would be cool to have an option to disable Preview in this mode.
If some icons aren’t displayed as expected, then that is an issue with the new API, and we can’t fix that. You see the correct icon for a short time because the old and the new APIs are both in ForkLift, and first the old one runs, which most likely displays the icons correctly. That is a fallback option if the new API doesn’t find an icon to display, but since it does, it replaces the first icon.
Also, you can turn off icon preview in all views, icon view included. You can do that under View > Show View options (or Command-J keyboard shortcut). Deselect Show icon preview. You should do that in all tabs.
The PDF preview fix sounds handy. Did you notice any performance changes after the update?
Did you notice any performance changes?
This is first version of Forklift that introduced crashes and bugs.
What I mentioned before rolling back:
1. It doesn ‘t show the corresponding icon for the file type
2. It crashes when I exctracted the file from Dropbox. I sent those crashes to the developers.
I’m sorry to hear that. The issue with the icons is related to the new preview API that we switched to in this new version to be able to display the colors and custom icons of folders on Tahoe.
It seems that the API has several bugs, that Apple hasn’t fixed (yet), especially on Sequoia where these features weren’t available. The new API has issues with those older style icons that are displayed on some system folders on previous macOS versions as well.
In the next ForkLift version we will remove the new API for users that are still on Sequoia, so these new issues should go away on Sequoia.
Please send the crash reports at support [at] binarynights [dot] com as well. That way we will make sure to look at it. You can find the reports in the Console app. If you don’t have them, then please try to trigger the crash. You can have multiple versions of ForkLift on your Mac, so you can download the new version and then delete it without deleting the version you are using.
You can download older versions here: https://binarynights.com/downloads
It’s happening on Tahoe
Please contact us via email and send us the crash reports and let us know what file types are not displayed correctly.
Hi,
I’m experiencing repeated crashes with ForkLift 4.6.1 (470) on macOS 26.3 (25D125).
I asked ChatGPT to analyze the crash log, and it pointed to a few specific areas in the report:
– The crash is `EXC_BAD_ACCESS (SIGSEGV)` / `KERN_INVALID_ADDRESS at 0x0000000000000004`.
– The crashed thread is the main thread: `Thread 0 Crashed`.
– The stack trace points into SwiftUI/AppKit layout rendering, especially:
– `swift_getObjectType`
– `swift_task_isMainExecutorImpl`
– `SwiftUICore`
– `HStack.init(alignment:spacing:content:)`
– `ViewBodyAccessor.updateBody(of:changed:)`
– `NSViewLayout`
– Other ForkLift-related frames present around the crash include:
– `UpdateOperation.main()`
– `BaseViewMode.doUpdateItem(_)`
Based on that, it looks like ForkLift may be crashing while updating or redrawing the file list / UI, possibly when refreshing a folder or connection.
Crash details:
– ForkLift version: 4.6.1 (470)
– macOS version: macOS 26.3 (25D125)
Please let me know if I should provide the full crash log or try a specific debug build.
Thanks!
Please send us the crash report at support [at] binarynights [dot] com and if you know what you did in ForkLift when the crash happened, then please let us know.
Not too happy with the new icon “feature” (not a drama, Forklift remains my favorite file manager 😉 ).
Each time I open a directory:
Forklift first shows icons in the default icons (orange in my case) and then about 1 or 2 seconds later updates all folder icons to a different color (blue in my case).
Note that I’m using the default icons and am not setting any tags, colors or anything like that.
I’m sorry to hear this. We have looked into the issue, and unfortunately the new API we switched to does not handle this correctly.
On Tahoe, Apple has changed a lot of things related to folder icons. It is now possible to change folder colors in System Settings, and folder appearance can also change when you add a tag. In addition, folders can be customized with icons or emoticons. These were not supported in the past, and the older API we previously used to generate folder and file icon previews did not support any of these new features. Because of that, we were unable to display customized icons when using the old API.
Since a newer API is now available that supports these features, we switched to it. However, it appears that this new API is missing support for some functionality that the old API handled, and which is still needed on the latest macOS. One example is the newly introduced folder color setting in System Settings, which the new API does not currently support properly.
The folders briefly appear with the correct colors. This happens because ForkLift currently includes both APIs. In some cases where the new API cannot generate a preview, the old API is used as a fallback. As a result, the old API initially displays the folders correctly, but this is then overwritten once the new API takes over.
We have reported the issue to Apple, and we hope it will be addressed in a future update.
I feel your pain (being a developer myself) when Apple changes or introduces a “feature” 😉
Reverting back to 4.6 fixed it for me for now.
When opening a file on an SFTP server, there are some issues.
* Opening a remote (e.g. zip) file opens in a different app than a local zip file. Obviously, it should be the same app.
* Remote editing is heavily cached which results in older versions of the file in the local tmp folder not always automatically to be uploaded to the server when saved.
* When re-opening an existing remote folder, it loads it contents from the local cache rather than from the remote server, also a too aggressive cache issue. I have always to click ‘Refresh’ to see its actual contents.
* Path to local tmp folder do not contain same paths (at least the last folder name) as on the server, but only an unintelligable hexstring.
Point 1, 3 and and 4 are better handled by e.g. Double Commander, so why can a commercial app not handle this.
A little but annoying problem:
when folders on the remote server have a name with a dot, it is treated like a file with an extension, and an apparently according icon is showed.
That should not happen, because it is a folder, not a file or a package.
For instance, on my server I have folders that contains a website, with names like fantasymagazine.it, and instead of the folder icon it is shown with a VLC icon as “Impulse Tracker Module File”, whatever that is.
ForkLift checks if an item is a file or a folder by checking the “extension”, in this case .it. We will try to change that.
I noticed that 4.6.1 introduced a small problem with folder color.
Basically, up until 4.6 version, folders in both Finder and ForkLift used “Folder Color” that we selected in “Theme” section of “Appearance” tab in OS settings (so for example, if red color was selected, folder icons in both Finder and ForkLift were red).
In 4.6.1 version, folders now display selected “Folder Color” only for the first 1-2 seconds, and then automatically switch to light blue color. This folder color switch happens each time we open any folder for the first time after launching the application. Additionally when we create new folder, it displays in selected “Folder Color” during naming, but automatically switch to light blue after accepting its name (so if we have for example red color set as “Folder Color” in OS, folder icon will be red while typing its name, and then immediately switch to light blue when we finish naming it).
Personally I don’t like this folder color switching each time I enter or create new folder. Could it be somehow improved in the future versions please?
Which macOS version do you use?
Sorry, I have realized that that feature is only available on the latest macOS version. These issues are all happening because the new API doesn’t handle these cases correctly, which is funny because the API comes from Apple. We will try to find a workaround. – Edited: Unfortunately, the workaround doesn’t work.
I have the same problem on macOS 26.4.1: missing the folder colours which I picked in the System Settings → Appearance. After 1–2 seconds my folders turn blue instead of the colour I picked 😢
But I still love ForkLift as a FileManager, really great application 😀
Will there be a fix to get back the old behaviour?
Thanks!
We can’t fix this issue, the new API doesn’t handle that setting correctly. We have reported this issue to Apple, hopefully they will fix it.
Same problem here – reverted back to Forklift 4.6.
Forgot to mention: macOS 26.4.1 (Apple Silicon)
Unfortunately, this is not something that we can fix. Apple needs to fix the API. We have reported the issue to them.
Sometimes background task are stuck. I don’t know what is that mean but at that time the panel is unresponsive, cannot change directory, hotkeys don’t working. Hard te reproduce directly. It happend when connected to network share, sometimes when new file created the current directory, … When I try to quit a window appear: “If you quit now, those activities will be aborted”.
That probably happens because the NAS is not responding. When that happens, you should take a sample and send it to us at support [at] binarynights [dot] com
Take a Sample when ForkLift is not responding. Open Activity Monitor, select ForkLift and choose Sample Process from the View menu, or click the Three Dots icon in the toolbar and choose Sample Process. Save it as a text file and send it to us.
At that time I cant open the activity window. It happens on local filesystem too
it happened when I search file cmd+f on local filesystem
Please contact us via email about this issue.
Is there a way to rollback to 4.6 for SetApp Users?
Thanks!
Unfortunately, that is not possible. There is only one Setapp version. We will make changes in the next version, which will fix the issues on Sequoia. The issues related to the new API itself can’t be fixed by us. We have reported the issues to Apple.
When I copy many files, they appear in the transfer list on the right side, but they are copied one by one in a queue. I would like to copy several files simultaneously, without waiting for each file to finish before the next one starts.
Right now, the only way I found to copy files without using the queue is to start each file transfer manually one by one, but this takes a lot of time when working with many files.
I also tried changing the option for simultaneous transfers and set it to 30 files at the same time, but it does not seem to work as expected. The files are still copied one after another.
Could you please explain how this should be configured? Is there a way to make ForkLift copy multiple files at the same time automatically?
The simultaneous transfers setting applies to remote transfers only (FTP, SFTP, etc.). Local file transfers on macOS or network drives are handled differently and are copied one by one in ForkLift.
This is actually similar to how Finder works. When you start copying a large number of files in Finder, they are also copied using a single transfer process. If you later start another copy operation manually, Finder runs that separately in parallel.
In ForkLift, there is no setting that enables automatic simultaneous local transfers.
In practice, running many simultaneous local transfers usually does not provide a significant speed improvement, so we are not planning to enable that behavior.
The folder colors on my system (Tahoe 26.4.1 (25E253)) were working correctly until the update. Now, when I enter a directory, the folders briefly appear in the selected color for a fraction of a second and then switch back to blue.
I have changed the color multiple times in the system settings, but the only thing that changes is the color displayed during the first few hundred milliseconds.
(M.)
Unfortunately, this is a limitation of the API at the moment. Hopefully, Apple will fix it. You see the right color first because first the old API loads as a fallback, but then the new API loads, which doesn’t handle the settings in the System Settings correctly, and it displays the default color. We can’t fix this issue ourselves.