Archive for the ‘Development’ Category
Friday, April 26th, 2019
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.
Friday, January 25th, 2019
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.
Friday, September 7th, 2018
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!
Release notes and a download link are on the Default Folder X beta testing page.
Monday, August 13th, 2018
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.
Get all the details and download your copy from the Default Folder X Beta Testing page.
Monday, December 11th, 2017
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.
Tuesday, November 14th, 2017
This talk by Tim Standing (one of the developers behind SoftRAID) is an excellent analysis of APFS:
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.
Thursday, March 2nd, 2017
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.
Friday, December 30th, 2016
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.
Friday, December 16th, 2016
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.
Go read his whole post for all the details.