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?
Indeed.
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.
Houdah Software released a major upgrade of their excellent Spotlight search utility, HoudahSpot 5, last week. Among a ton of useful new features, HoudahSpot now also integrates with Default Folder X, giving you a much more powerful way to search for files and folders in Open and Save dialogs.
Just select “Search with HoudahSpot” from Default Folder X’s Utility menu
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.
And use HoudahSpot’s “Default Folder X” menu to send a search result to a waiting file dialog
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.
There’s a new public beta version of Default Folder X available – it’s Default Folder X 5.2.6b7.
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.
So I’ve noticed in Sierra that some of its “helper processes” (apps that run in the background to do various tasks) will occasionally start using 100% CPU for no reason. In particular, I’ve seen the com.apple.appkit.xpc.openAndSavePanelService process stay pegged after a file dialog is done – it just sits there and consumes CPU while doing nothing. Quitting the app that was showing the file dialog will stop the CPU-hogging, but it otherwise continues indefinitely.
I’ve been wondering if this might actually be the source of the much-talked about Consumer Reports findings that the new MacBook Pros have very inconsistent battery life. Their results varied widely from test to test (on the same computer) – maybe one of the WebKit helper processes was just flipping out once in a while due to some underlying bug in Sierra’s interprocess communication or process management services.
While that’s just my own random speculation, the issue of processes running amok seems to be a recurring annoyance to some folks. To help you detect this sort of stuff, I’m adding an option in App Tamer to notify you if a process starts consuming excessive CPU time. If it does, it gives you the options shown in the screenshot.
Can’t hurt, right? Shoot me an email (AppTamer at stclairsoft dot com) if you’re interested in trying it out and doing a little testing for me.
So I’ve run into this issue both as a user and as a developer – on MacBook Pros that have both a discrete and integrated GPU, fancy animations will cause the system to switch to the more powerful discrete GPU, reducing battery life. Chris Liscio wrote a great post explaining what’s going on and what to do about it (from a developer’s perspective). The key takeaway for most developers:
This whole problem can be very easy to solve. You just have to set NSSupportsAutomaticGraphicsSwitching key to YES in your application’s Info.plist. The trouble is that an OpenGL context is being created, which defaults to switching the dGPU on. Enabling this flag in the plist will very likely fix the problem on its own, as the frameworks should Do the Right Thing (more details below) if they need access to OpenGL.
