The latest public beta of Default Folder X 5.4 is available, and offers improvements on both Catalina and older versions of macOS. Specifically, it adds support for the version of Path Finder distributed via SetApp, gives AppleScript developers access to applets and droplets in DFX’s Recent Files menu, and fixes a bug in Default Folder X’s handling of tabbed Finder windows.
Version 1.7.3 of Jettison is now available. It fixes a problem when running on Apple’s latest Catalina beta where it would try to eject Catalina’s new system data volume if the system was running from an external drive.
In addition, Jettison 1.7.3 also improves its error reporting and handling, allowing you to quit applications that are preventing a disk from being ejected. This release also addresses an occasional problem with disk images not getting completely cleaned up after being ejected.
More details and download links are available on the Jettison Release page. If you’re already running Jettison, just choose “Check for Updates…” from its menu in your menu bar to update to the new version.
There’s a nice, user-centric review of Go64 at Podfeet.com that provides helpful details on preparing to upgrade to Catalina: https://www.podfeet.com/blog/2019/09/go64/
Version 2.4.7 of App Tamer is out. The new release fixes a bug in its “Hide after X minutes” and “Quit after X minutes” features that could cause it to use unreasonable amounts of processor time when they were turned on for iTunes or Spotify. Not exactly what you want to happen in an app that’s designed to reduce the CPU usage on your Mac 🙂
Details and download links can be found on the App Tamer Release page.
Version 1.0.4 of Go64, our free app for determining which of your apps are macOS 10.15-compatible, is now available.
If you choose to list all the applications that Go64 has found, the new version will highlight all of the 32-bit apps in red. You can then sort the list by application name to see if you also have a 64-bit version of an app. If you do, then you don’t have to worry about finding an upgrade – just delete the 32-bit one shown in red.
It’s clear in the green rectangle that I have two versions of Microsoft Word, one that will run in macOS 10.15 Catalina, and one that won’t.
Go64 1.0.4 also includes corrected website and company information for a number of applications, including those from Ashlar-Vellum, Avid, Slack, Steinberg and Valve.
You can get the latest version of Go64 here, or by choosing “Check for updates” in Go64 if you’ve already downloaded a previous version.
Go64 1.0.3 is available now – you can download it from the Go64 page. If you’re not already aware of it, Go64 is a free application that scans your Mac for 32-bit applications that will no longer work when you upgrade to macOS 10.15 Catalina.
The new version of Go64 will now show you Preference Panes that contain 32-bit code. It also properly skips apps that are built for non-macOS platforms even if they contain code to run on an Intel processor (this is for you, iOS developers).
Most importantly, however, version 1.0.3 provides a preference window where you can tell Go64 not to show apps that are located within specific folders.
In the image above, I’ve got an old copy of Microsoft Database Daemon selected – it’s part of Microsoft Office 2011, which I still have so I can test it with Default Folder X. I know it’s 32-bit but want to keep it around, yet I don’t want it shown in Go64’s search results.
To remove it from the results, I just drag the ‘Microsoft Office 2011’ folder shown in the path control (in the green square) to the ‘ignore list’ in the prefs window. That’ll remove it from the results quickly and easily, even though Office 2011 is still on my Mac.
This should make it easier to clean out your list of 32-bit only apps so you can focus on the ones you need to upgrade. Note that you can also drag a single app into the ‘ignore list’ if you just want to remove one app rather than all apps within a folder.
To prepare, I wrote Go64, a free application that scans your system for 32-bit apps and shows them all in one place, with version and website information to make it easier to assess whether you need to update or look for an alternative.
After Mojave started warning about 32-bit apps needing to be updated, Ronald Leroux, who does all the French localizations of my software, pointed out that there wasn’t really a good way to check for and update 32-bit apps on your system. The built-in System Information app does work, but it’s certainly not the most user-friendly, nor is it necessarily complete.
Over a weekend last fall, I put together a straightforward little app to scan for 32-bit applications and show them in a list. It took a fairly simplistic approach, and worked fine but was no more thorough than what System Information provides. Still, it was much easier to use, so I figured I’d release it in the Mac App Store. Then came the task of trying to get it approved: App Store Review rejected it because it asked for permission for the entire disk so it could scan for apps. That wasn’t something I could fix or work around. So I shelved it – there were higher priorities at St. Clair Software, plus dealing with the App Store always seems to ruin my day.
Fast forward to WWDC 2019, when Apple confirmed that Catalina definitely won’t run 32-bit apps. Howard Oakley at the Eclectic Light Company had been doing some deep-digging and highlighted a number of issues with 32-bit app checking. He wrote his own exhaustive scanner that searches for them, but it’s slow and still not very user-friendly. I dusted off Go64 and figured I’d turn it into a more complete solution.
“It’ll only take a couple of days…” – famous last words uttered by nearly every software developer at some point in their careers.
As they say, the devil’s in the details, and dealing with the vagaries of what goes on inside applications got interesting. Go64 leverages Spotlight to compile a list of executables, but then does a deep dive into each 64-bit application to check for any helper apps, frameworks, services or plugins that might not be 64-bit. While I knew this could be an issue, Howard’s work highlighted just how common it is to have a mix of executables bundled within apps. Most of the time, it’s just for expediency, and developers do the proper juggling to run the correct one, but how’s a user to know? So Go64 does a bunch of checks to look for common methods, and if it still can’t make sense of things, errs on the safe side and flags the app with a little caution icon.
Clicking on “More Info” gives you the whole scoop:
This, of course, led to more complexity. As a developer, I don’t want to be bugged by hoards of people asking whether my app is Catalina-compatible just because some stupid “Go64” app noticed I include a 32-bit helper to deal with ancient Quicktime videos. So Go64 updates its internal “Ignore this warning” list periodically from the St. Clair Software website – that way it can inform users that even though the app contains 32-bit code, it’s compatible.
So developers, if your app contains 32-bit code but is Catalina-compatible, contact me with the bundle ID and version number of the app and I’ll add it to the list so Go64 gives users this message instead:
And to everyone else, I hope Go64 turns out to be useful for you. I certainly had a lot more 32-bit apps sitting on my Mac than I thought!
Version 2.4.6 of App Tamer is available, adding preliminary support for macOS 10.16 Catalina (up to the second developer release, anyway, because that’s what we’ve got at present).
It also fixes a little bug that I personally found really annoying: When Spotlight was indexing files, App Tamer showed all of the Spotlight processes separately, often filling up half of the visible process list with Spotlight stuff. It now does what it’s supposed to do, aggregating all the CPU usage in one “Spotlight Indexer” entry and controlling that as if it’s a single process. That gives you better control over Spotlight’s CPU usage and makes CPU-hogs easier to see (I’m looking at you, Spotlight!).
This release also introduces a new setting in App Tamer’s preferences. In the Control tab, there’s now a way to modify how long it waits before managing processes after it launches or wakes from sleep.
This lets you give all processes a little time to run at full speed to get everything synced up after your Mac wakes up, usually making that happen a little faster.
Version 5.3.7 of Default Folder X introduced a new capability: it can now ask what the default folder for an application should be on the fly using AppleScript. That may sound like a mouthful of jargon, so let me explain, because it can be applied in a lot of situations.
Jason Snell (of Six Colors and The Incomparable fame) has been writing about Macs forever, and is now a prolific podcaster. He emailed to ask if it would be possible to make Default Folder X more flexible. At that time, you could set a default folder for an application so that when you chose Save As, it always offered to save a file in that particular folder. His problem was that you have to set a single folder as the app’s default folder – just one.
Jason creates podcasts – lots of them. His reasoning was that if he could magically tell Default Folder X what podcast he was working on, it would always offer to save the component audio files into the folder for that podcast. Essentially: Wouldn’t it be great if you could edit an audio clip, hit Save, and have it automatically go into the folder for the current podcast folder? No re-configuring a default folder for each new project – it’d just work.
So he hit on this idea (which I think is just brilliant). He uses Apple’s Logic X application to create his podcasts. So for each podcast episode, there’s one master Logic X project file. To find the correct default folder for audio clips, all he has to do is look at all the project files and see which one has been saved most recently. The “Audio Files” folder sitting next to that project is where everything should go for the current project. He wrote an AppleScript to do this, which he shared on the Six Colors blog.
This can obviously translate to all sorts of different workflows. If you have one primary file for each project, it’s easy to tell which one you’re currently working on – it’s the one that’s been saved most recently.
How to set up an AppleScript to specify a default folder
So how do you wire up Default Folder X to do this? It’s pretty simple. Put an AppleScript script in:
or, if you want it to handle only a single application, put it in a sub-folder of the Scripts folder named for the application you want it to serve. To have it queried only for Preview, for example, put an AppleScript in:
The trick is that you need to implement this handler:
on getDefaultFolder(appName, dialogType, firstTime)
which returns the location of the default folder. Open up the sample script file in Script Editor (or your AppleScript editor of choice) and have a look. I’ve tried to explain things clearly in the comment at the top, and the script shows a number of different ways of returning folders to Default Folder X. And of course, you can also use Jason’s complete script as a starting point.
I think Jason’s idea is great – it streamlines work on multiple projects, but most importantly, it reduces the chance for error as you’re trying to meet that pressing deadline. I’d love to hear how others use this feature, so please drop me a line if it works for you too!
Version 2.4.5 of App Tamer is a fairly tame release – it corrects a few nagging bugs, and is now checked for malware by Apple and notarized to indicate so. The menu bar icon shows its disabled state more clearly when running in Dark Mode on Mojave, and some processes were mistakenly listed in the “Managed Processes” list even though App Tamer wasn’t managing them (ironically, because of bookkeeping error, they were included in the list because App Tamer never touched them at all).
