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 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!
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!
So I learned an important lesson in user interface design: There are times when you DON’T want a consistent look and feel. The user-confusion resulting from my mistake in Default Folder X 5.3.3 necessitated the release of Default version 5.3.4 yesterday.
First a little background: Due to the increased Privacy controls in Mojave, when you first launch it, Default Folder X has to lead you through several steps to give it permission to access necessary information and API’s. It does so by opening System Preferences and presenting a couple of dialogs that provide steps that you need to follow. Easy, right? These are the dialogs from version 5.3.3.
See a problem there? Well, I didn’t, and neither did my testers. But the dialogs are very similar – same heading text, same buttons – the fine print is different and the Default Folder X icons are in different places, but they’re a lot alike. The first dialog pops up, and after you follow its instructions, it is automatically replaced by the second one. Because they look alike, a lot of people thought that the instructions hadn’t changed and that they were stuck, with no option but to hit the “Quit Without Authorizing” button. And send me a freakin’ email… I got lots of email.
So here are the fixed dialogs. Different overall look, different boldfaced heading, and different buttons. And an important lesson learned: People are busy, and are not necessarily giving your app 100% of their attention. Make sure that when the state changes, the change is noticeable to them. Especially when their only option if they don’t notice the change is to quit your app.
Sooo – get Default Folder X 5.3.4. In addition to the updated Privacy prompts, it contains several bug fixes. You can get it from the Default Folder X release page, where you’ll also find release notes describing the changes.
You’ll want it if you’re running Mojave 18A384a or higher, as the new Mojave builds require “usage statements” built into applications as part of their privacy controls. Previous betas of Default Folder X didn’t have these, resulting in newer iterations of Mojave summarily killing it if it tries to access protected folders, like those containing your contacts or music.
This Default Folder X build also includes a bunch new dialogs to alert you when it hasn’t been given adequate access to things in System Preferences > Security & Privacy > Privacy. The biggest stumbling block is access to Automation — giving DFX permission to use AppleScript to talk to the Finder, Path Finder, ForkLift and System Preferences. DFX uses AppleScript to get lists of open windows and navigate to folders and files in Finder / Path Finder / ForkLift, as well as opening System Preferences to the right preference pane so you can update necessary settings.
While there’s definitely a need for Mojave’s increased security, it’s a bit piecemeal at present. I’d love it if Apple would provide developers with some sort of API to help inform users in one shot of everything that an application needs access to, and to help them configure that access conveniently. As it stands right now, you’ll encounter multiple alerts as you use Default Folder X — they pop up in the middle of whatever you’re doing when Default Folder X first tries to touch something that’s protected. They’re not terrible, but they interrupt what you’re doing and, as such, aren’t presented at a time when you’re likely to devote your full attention to the security choice you’re being asked to make. So be prepared for a few alerts when you first start using Default Folder X in Mojave — it’s now the price we pay for additional security.
Oh, and on top of all the security shenanigans, Default Folder X 5.2.6b7 also tracks your recently used files much more effectively, even if the Recent Items system in macOS misses them. Something I’m happy to have finally sorted out!
The latest public beta of Default Folder X, version 5.2.6b6, supports Dark Mode in Mojave and all changes up through the latest developer build (Mojave developer beta 7).
In addition, this beta release allows you to create separator lines in your Favorites menu to help keep it organized and easier to use. Just choose on “Add Separator Line” when you click the ‘+’ button in Default Folder X > Preferences > Folders > Favorites, then drag the separator to wherever you want it in your list of favorite folders.
5.2.6b6 also addresses a bug when relaunching the Finder, improves the behavior of DFX’s drawer in the Finder, and adds a compatibility fix for Newtek’s LightWave applications.
Prior to El Capitan, I used to sporadically see a few ‘random’ but consistently-repeating tech support issues. The most common were settings not “sticking”, file dialog windows not remembering their sizes, and St. Clair Software applications forgetting that a user had purchased a license. You might say “how are these in any way related?” Well, they all involve data stored using NSUserDefaults or CFPreferences, the built-in preference storage for macOS applications. It appeared that preference files would occasionally get corrupted – most commonly when an application auto-updated or when the user installed a macOS system update. The result was software not being able to retrieve previously-saved information. The incidents would often happen in waves – just after Apple released an OS update, or just after I released an update for one of my products (most noticeably Default Folder X, since it has the largest user base).
After Apple released El Capitan, most of this went away. I knew they’d been working on the application preference system for El Capitan because, in a few of the early developer betas, it was partially broken or changed in interesting ways. But by the release of 10.11.0, everything was working better than it ever had. Hooray for progress! Right?
And then came High Sierra. After two fairly quiet years, the preference-file-related problems started popping up again with increasing frequency. The most recent Default Folder X release seems to have resulted in a bunch of paid users being suddenly told they were running a trial version (the common thread is that they’re all running High Sierra). If you’ve been affected by this, I’m sorry! Unfortunately, nothing in Default Folder X’s license handling code has changed, it just suddenly can’t read your license information from its preference file, forcing you to re-enter it. I’ll be changing how Default Folder X saves its license info in future versions so this doesn’t keep happening because, yes, it’s really annoying.
With the apology done, I’m wondering – if you’re a developer, have you noticed similar issues with High Sierra? I never dismiss the possibility that I’m just doing something stupid, but with NSUserDefaults, there’s really not a whole lot to do wrong (feel free to correct me, of course). This has only happened to a very small percentage of my users, but there is a 100% correlation between the problems and High Sierra.
He has some very interesting points and conclusions – one of which is to never install APFS onto non-SSD (traditional spinning-platter) drives. The revelation that a major change was made to APFS very shortly before its release is also a little troubling, but at least that explains the current lack of documentation :-/
Thanks to Ronald Leroux for bringing this to my attention.
While Jettison and HistoryHound are still supported and sold on the St. Clair Software website, I’ve pulled them from the Mac App Store. The versions that were in the Mac App Store were older revisions, and it just didn’t make business sense to rearchitect the apps to meet Apple’s current requirements for approval so they could be kept up-to-date.
For both applications, complying with Apple’s sandboxing and feature constraints to get them approved for sale would have required significant rewrites. And in Jettison’s case, it would also require that buyers download a separate helper app to enable its full functionality. I realize that some people will be put off or inconvenienced by the fact that these apps are no longer in the Mac App Store – my apologies if you’re one of those folks, but it just doesn’t make sense for Jettison and HistoryHound.
Without going into a full-on rant about the Mac App Store (I could ramble on for days), let’s just say that while the Mac App Store is convenient for consumers, it doesn’t really serve the needs of some developers. Much has been written about it already (here, here, here, here and here, for example) so I won’t rehash it all – and despite years of “constructive criticism” from developers, Apple hasn’t fixed some major problems.
I hope you’ll continue to purchase our applications, as well as those from other independent developers selling outside the Mac App Store. While it’s a little less convenient than the Mac App Store, it allows us to bring you the best software we can, and also gives us the opportunity to foster a two-way relationship with you – both of which really matter to us.