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.
“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).
A change in Safari combined with a bug in HistoryHound meant that previous versions of HistoryHound would often wait much longer than they should have to update the index of your browsing history. Version 2.0.2 fixes this problem, and is also notarized by Apple to ensure its security (and compatibility with macOS 10.15 when the time comes).
Default Folder X 5.3.7 is now available, and it displays a couple of additional pieces of metadata in the Info panel below Open dialogs, most notably the “last opened” date. It also addresses a number of issues, including problems with LaunchBar, sub-par behavior when file dialogs are very large or lie partially off-screen, keyboard shortcuts not working after using a menu bar app, and drag-and-drop problems with the Finder drawer. A full list of changes is available on the Default Folder X Release page or in the Version History.
This version also works around bugs in Mojave that have been affecting Default Folder X’s ability to list open Finder windows when those windows contain multiple tabs. It will now list those windows reliably, but may still get confused and show some tabs as being in their own, separate windows – but hey, at least they’re all there, right? Unfortunately, a complete solution requires that Apple fix the bugs that I’ve submitted.
And one very important note about Finder windows: The behavior of Default Folder X’s Finder-click feature has changed a bit. Most people won’t be affected by this, but if you have been relying on the fact that Finder-click showed windows that weren’t actually visible (because they’re in another Space or because the Finder’s hidden), you’ll find that they’re no longer appearing. They’re still in the Finder Windows menu in Default Folder X’s toolbar, or you can revert to the old behavior by following these instructions.
Finally, on the truly geeky side, you can now create an AppleScript to supply Default Folder X with a default folder for an application on the fly. When a file dialog comes up, DFX will run your AppleScript, and if it returns a folder, that’ll be used as the default folder for that file dialog. It works seamlessly and can really simplify things if you work in a project-based manner with a consistent way of determining where your project folder is. Look for a blog post about this shortly.
Brent Simmons has a great post over at inessential.com on the genius of Apple events. As one of the people behind the ground-breaking Userland Frontier, Brent is uniquely qualified to espouse on the significance and power of Apple events. Frontier, and later AppleScript, leveraged Apple events to let Mac users tie together applications to make workflows that got real things done, even when no single application existed that would do what they needed. I used Frontier for years to automate the back-end of my software business – it was invaluable.
As Brent says:
Picture Jane in her office. She gets an email from Bob every month with the latest WidgetX numbers. With that email in front of her, she double-clicks a script (or chooses one from a scripts menu)… [which] updates and saves (on a shared folder) a Keynote presentation with the new numbers.
This used to take hours, and it was prone to errors. Now it takes a minute or less — and it’s error-free
With Marzipan reportedly coming in macOS 10.15 this year, Apple is further de-emphasizing the cooperative nature of macOS apps, and will most likely not support Apple events in the “iPad apps adapted to run on the Mac” context of Marzipan. Again, from Brent:
What happens to Jane if Mail is a Marzipan app that doesn’t respond to Apple events?
And as Brent says (and as I detailed in an earlier post), many Mac apps use Apple events to directly integrate with other applications. They tie everything together for you, taking your Mac experience from ‘good’ to ‘great’. Just in my own apps, Default Folder X communicates this way with the Finder, Path Finder, ForkLift, Terminal and iTerm2 to give you seamless access to folders no matter where you need them. App Tamer uses Apple events to make sure it doesn’t interrupt iTunes and Spotify when they’re streaming music for you. And there are numerous other examples throughout the Mac ecosystem (and probably on your Mac right now).
Losing Apple event support in Mac applications would be a bigger loss than a lot of people realize – and one I’m not sure Apple is completely cognizant of. My hope is that there’s someone back there minding the proverbial store, but my feeling is that Apple is rushing headlong to open up macOS to UIKit applications to get more apps on the Mac, without regard for some important underpinnings.
When you’re in a file dialog, Default Folder X provides a menu command to quickly search the currently displayed folder in HoudahSpot. This gives you the flexibility to search by file type, tags, content, modification date, or any other parameter you can think of.
Once you’ve located the file you want in HoudahSpot, Control-click on that file and use the “Default Folder X” menu to finish the round trip and send it back to the waiting file dialog (in Preview, in this case).
I’m happy to have had the chance to collaborate with Pierre Bernard, HoudahSpot’s developer, on this workflow. It delivers more convenience and time-savings to all the folks that use both HoudahSpot and Default Folder X.
If you have ideas for similar connections between your favorite indie applications, let the developers know – many of us are very receptive to your suggestions. Default Folder X also integrates with ForkLift and Path Finder, for example, because lots of people asked for it!
Version 5.3.6 of Default Folder X delivers fixes for a few problems that have cropped since the last release. The most significant is a bug that caused the mouse cursor to disappear when using an Open or Save dialog, resulting in things appearing “stuck”. This occurred if you were using SteerMouse or any other utility that modified mouse behavior on the fly.
A change that I made in 5.3.5 also resulted in Default Folder X’s Finder-click feature being disabled if there was a Keyboard Maestro floating palette showing anywhere on-screen. That’s now fixed in 5.3.6 – my apologies to all of you joint Default Folder X / Keyboard Maestro users out there!
This release also includes a number of bug fixes for crashes, startup hangs, user interface issues, and a problem with the Finder-click feature not switching its list of Finder windows when you switch Spaces.
You can see the release notes and grab the latest version from the Default Folder X Release Page, or by choosing “Check for Updates” from Default Folder X’s menu if you’re running it now.
Some users of App Tamer have noticed that version 2.4.3 unexpectedly disappeared from their menu bar. There was a library shared across all of St. Clair Software’s apps that didn’t work correctly in App Tamer, causing it to crash when it received certain system notifications. That’s now been fixed.
Equally important, App Tamer was using more CPU than it had to, which isn’t really what you want in an app that’s supposed to be saving CPU cycles. It primarily affected Google Chrome users, but was actually a problem with all web browsers. App Tamer periodically “rebalances” the CPU usage of browsers’ helper processes, and was actually re-checking to see if the browser was downloading anything every time it did that rebalancing. That was completely unnecessary, and the download check is one of the more CPU-intensive things that App Tamer does, so it really shouldn’t have been doing that more than it absolutely had to.
So, those two issues are fixed – my apologies for the problems. You can grab version 2.4.4 from the App Tamer Release Page.