Sorry it’s been so long since I published an update for you guys. Everytime I think about doing one, I want to have something cool or good to tell you about the progress things are making. Since things have slowed down a bit, I kept putting it off, but I decided I can’t just stay radio silent forever.
Since this update is a little dense, I decided to provide a summary for those who don’t want to get into it.
File Buddy is using Swift 5 now and has removed several libraries that weren’t updating or were not longer the preferred way of doing things. Minor fixes and features have been implemented as well as performance and user experience improvements. The Find Window is hitting a lot of blocks and will probably take a while longer to have anything usable added to File Buddy 11.
I don’t have a new alpha build at the moment, there’s a few minor things I’m finishing up and I hope to publish an update in the next week or so.
Swift 5 and Info Window Rewrite
Apple released Swift 5 at the end of March. This is the first truly stable version of Swift. Up to this point, libraries had to be updated to whatever version of Swift the application was using. This was extremely time-consuming and dangerous for application developers. I decided it would be worth the time to upgrade to Swift 5 immediately so I didn’t have to worry about it.
The upgrade to Swift 5 itself wasn’t that bad, although it did break some of my code. The bigger issue was that not all of the libraries I was using are Swift 5 compatible. Some of those libraries were on my list of things to replace and remove anyway. Most of them were libraries I had chosen during my early efforts and have been supplanted by more suitable choices in the last year or so. I had been putting off rewriting the sections of File Buddy already done in those libraries because I wanted to focus on implementing new features. However, since the upgrade to Swift 5 was requiring some housecleaning anyway, I bit the bullet and did it. This effort took over a month and required rewriting a large portion of the Info Window.
During the process, I noticed some performance issues - specifically around large folders. Opening my home directory, for example, took upwards of 90 seconds. This is obviously not acceptable or usable - especially since there wasn’t any kind of loading icon or indication that the window would open eventually. As part of the refactor, I changed the process for calculating directory size (which was the slow part of loading directory info) and now the window opens immediately and says “Calculating…” for the size until that process is done.
While I was doing the rewiring and fixing the performance issues, I noticed a few other little problems with logic or missing features. As an example, I didn’t previously realize that volumes had a special Info Window view. This kind of stuff started to become a rabbit hole and I just kept going deeper. Eventually, I had to just add items to my backlog of work and finish the changes.
I’m happy to say that this work to remove/replace the libraries is done and File Buddy 11 is using Swift 5. What this means for you, the user, is very little. Since File Buddy 11 is still supporting macOS 10.9, the Swift runtime will still be bundled with File Buddy and everything should continue working.
Beyond the large changes to the implementation of the Info Window, I’ve spent a lot of time on small changes. The Info Window and List Window are getting more of their toolbar items filled out - things like copying file attributes in the Info Window. There have also been some improvements and new features on the List Window, but nothing major.
I’ve had multiple users contact me and tell me that the search capabilities of File Buddy are one of the main uses for it and they are excited for File Buddy 11 to add them. On this front, there isn’t a lot of good news. On the UI, the controls the current File Buddy uses no longer exist. I can try to figure out an equivalent solution with different controls or I can try to re-implement the controls used in File Buddy 10. Both are time consuming. The former will take time in design and experimentation to get the new experience right, the latter will take time writing custom controls and making sure all the pieces are done right. Neither is particularly ideal and I haven’t made a decision yet. I’m pushing it off until I have a better understanding of what I can actually get the Find Window to do.
Which brings me to the other part of not-so-good news around the Find Window. The mechanism that File Buddy used for fast searching and filtering has not only been removed from Apple’s Cocoa framework, the underlying mechanism of the file system has been removed from Apple’s new filesystem APFS. I might be able to use the current mechanism on older installations that still use the older macOS file system, but Apple requires APFS on newer installations. This means that I have to find an alternative. The closest thing I’ve found is reported to be significantly slower than the previous mechanism and my efforts at using it haven’t met with a great deal of success. There are a few options going forward.
- Use Spotlight macOS builds an index of files and metadata that can be searched by apps. Larry was not a fan of spotlight and refused to use it. It runs in the background and indexes your files, but it takes CPU from the rest of the system to do so and can make your computer less responsive. While it does provide a quick win for searching files, I’m not sure what kind of performance it will offer, whether it will cause permission problems at some point in the future (ie Apple may decide to restrict which metadata items apps can see), and it’s an optional feature that some users turn off. Since it’s not something I can really rely on and I don’t think it’s reasonable to insist that users enable Spotlight just to use FIle Buddy, this option isn’t a full solution, but would only be part.
- Use Low Level Filesystem Options This would involve using the current mechanism on older installations that still support it and using the newer (and slower) mechanism for APFS volumes. This solution is quite complicated because even if it ends up being technically viable, searches can span multiple volumes and that means aggregating searches that use different mechanisms. This is probably the option with the best experience for the effort because it will provide the best and most consistant user experience when searching while requiring less technical effort than some other solutions.
- Have File Buddy maintain it’s own index This is basically having File Buddy maintain it’s own version of the spotlight indexes. Doing this efficiently and keeping it up to date would require a fair bit of research and experimentation, but could provide similar value to the built-in spotlight, while being less intrusive and more customizable. For example, if File Buddy maintained it’s own index, users could configure which folders and volumes were indexed and which metadata items were important.
Realistically, none of the solutions really do what I’m looking for all by themselves. I suspect I’ll end up with a combination of all of them eventually. To start, I’ll probably try implementing option 1 and seeing if it works well enough. That’s the fastest path to getting the Find Window up and running in File Buddy 11. Option 2 is most likely to follow, using the old mechanism where available, and falling back to Spotlight when it’s not. If that’s not performant enough, I’ll add in the APFS-compatible low-level file system implementation to improve performance. It will probably end up as a configuration option as well, letting the user choose whether to just use Spotlight or rely on file system searching. I’ll also probably eventually (probably not before release unless absolutely necessary) have a custom indexing solution that could be selected by the user.