Keymou 1.2.9 is now a universal app built for both Apple Silicon and Intel Macs. It’s also got a shiny new icon, and its interface now feels more at home on Big Sur.
Key Codes 2.2.1 also has a new icon, which is really all that’s changed in this update.
Direct users can update in-app, or by downloading a new copy of the app(s) from our site; App Store users should see the updates in the Mac App Store app, if not yet then very shortly.
Oh wait, did I say something about a birthday?! Yes, I did. No, not a person’s birthday, an app’s birthday: Moom is 10 years old today!
In celebration of this milestone, Moom is on sale for 50% off (just $5.00 in US currency) for the next five days. So if you or someone you know has been thinking about buying Moom, these next five days would be an excellent time to do so.
So happy birthday, Moom…and many more!
Key Codes 2.2 is out, and it’s now a Universal app that runs natively on both Intel and Apple silicon Macs. We’ve also improved its support for Dark Mode.
Direct users can update via the in-app updater, or by downloading a new copy of the app from our site. App Store users will see the update in the App Store app, either now or very shortly.
With Big Sur’s release, here’s an update on our apps’ compatibility…
All of our apps run in Big Sur, and almost all of them run 100% perfectly.
We’ve tested them all many times, and they all seem to be working as we’d expect them to, with one minor exception (and a “check your version” warning about one of our baubleries). We also have a general heads-up on a permissions request you may or may not see from some of our apps.
Although we’ve tested extensively, some of our apps have lots of features and can be used in many different ways, and we probably didn’t test all of those cases—many of you seem to find ways to use our apps that we never anticipated! So if you do find something that’s not working right in Big Sur, please let us know by opening a support ticket.
Permissions request
In our testing with Big Sur’s release candidate, we were surprised to find that some of our apps ask for permission to write to the Documents and/or Desktop folders. We’ll be completely honest here and say that we have no idea why this is happening. We have some guesses, but they’re just guesses at this point.
This issue did not appear in any of the prior betas (nor did it happen with every app), so we just discovered it yesterday when we installed the final version. As a general rule, our apps—unless you’re doing something that explicitly uses one of those folders, like saving Leech downloads to your Desktop—do not write to those locations.
We’re trying to get an answer as to why this dialog is appearing, but until we do, you can safely say “Yes” when macOS asks if it’s OK to use those folders—becausedo we’re not using them.
App-specific items
Displaperture: Please update to the current version (1.5.2) of Displaperture before you try using it in Big Sur. There’s no in-app updater, so you’ll have to download the new version from our site.
If you launch an older version, you may find yourself staring at a blank whiteish screen with rounded corners, and nothing else on it at all. Unfortunately, this screen sits above everything, including the Force Quit dialog. If you have remote login enabled and access to another Mac, you can connect and kill the Displaperture process, but if you don’t…well, the only way out is a forced reboot.
So please, make sure your copy of Displaperture is up to date before you launch it.
Witch: As a general statement, Witch is working fine. However, you will notice at least a few additional windows, mainly related to things in the menu bar. We’re working to get rid of these spurious entries, but for now, here’s the best workaround…
On the Advanced tab in Witch’s preferences, in the Do not list apps text box, enter this:
Control Center, SystemUIServer
If you have existing entries there, put a comma at the end and add the two new entries. Next, in the Do not list windows, enter this:
Item-0
Again, if you have existing entries, add a comma then that text.
These two changes should make Witch look mostly as it did in pre-Big Sur systems.
We’re working on the Witch issues, and we’ll keep you updated on our progress.
Again, if you notice anything askew in Big Sur, please do open a support ticket and let us know.
Ever since Peter and I relaunched Many Tricks in 2010, we’ve never had an official software license agreement. The closest thing we’ve had is this blog post, which explains limits on the use of our apps across multiple Macs (tl;dr: Use them on as many Macs as you personally use). However, we’ve never had an actual end user license agreement (EULA) that spells out the legal license you agree to when you purchase one of our apps.
Well, we have one now—it’s also permanently linked in the sidebar here, and will be accessible from within our apps. And a really big thanks to Rich Siegel at Bare Bones Software, who generously agreed to let us use his document as a starting point. I found the Bare Bones EULA to be well written, brief, and easily understood; hopefully our version, which has only minor changes, is still all of those things.
After six years, why did we suddenly need an EULA? The truth is we probably should have had one from day one, but never really felt the need. Recently, however, we’ve received inquiries from government agencies and larger companies interested in buying our apps … and many of these customers aren’t allowed to purchase our apps unless we have an actual legal license agreement. So now we do.
Note that this doesn’t change anything relative to the usage of our apps; we still allow you to use one license to install our apps on as many Macs as you personally use. We just needed to have a formal legal software license for larger customers and government agencies.
Yes, that’s right, we’ve updated the updater in our direct apps. Our direct apps rely on Sparkle to inform you when there are new versions available. Over the weekend, we were made aware of a potential vulnerability in how we implemented Sparkle. Basically, if your network is already compromised by what’s called a Man in the Middle attack, then it’s possible an attacker could use the Sparkle update mechanism in our apps to remotely execute code on your Mac. That’s bad.
Although this is a relatively small exposure (as you must already be on a compromised network), we felt it was important to act on it right away, so we’ve updated all of our apps to use Sparkle over secure HTTP (HTTPS). Please update any directly-purchased Many Tricks apps immediately.
Important: There’s a bit of a Catch-22 here … in order to get you this update, it must come over insecure HTTP, because that’s how Sparkle in the app you’re using is configured. If you are concerned that you might be on a compromised network, please do not update using the in-app updater. Instead, just download the relevant app(s) directly from our site, which uses HTTPS.
If you have any questions on this update, please leave a comment or email us directly, and we’ll do our best to address your questions.
Note: Although our App Store apps don’t use Sparkle, we know they’re out of date with some of the other minor bug fixes that came with these releases. We’ll be submitting updates to the App Store next week to get App Store users current.
There are a couple of changes in the soon-to-be-released El Capitan that required us to update our direct-sales app update mechanism—an incredible open-source framework known as Sparkle. (App Store versions don’t have this update mechanism, because the App Store app handles app updates.)
Because of how we implemented Sparkle, we found that the updater wasn’t working properly in El Capitan. So we needed to fix this prior to El Capitan’s release. As a result, today we have updated every single direct app we sell (and even one we give away):
Butler, Desktop Curtain, Key Codes, Keymo, Leech, Moom, Name Mangler, Time Sink, Usher, and Witch
We have pushed all these updates live, so you should see them automatically (if you have our apps set to auto-update), or you can look in the Preferences > Updates section of a given app and manually check for updates. You can also download the complete new version from our site, if you prefer (just delete the old one and replace with the new; you won’t lose your settings.)
Over the last few days, several users let me know they were unable to download our apps from the Mac App Store. They reported that they were receiving this error message when trying to purchase or update:
App Store Error: Failed to verify the preflight file. It is not signed by Apple.
Emails like this are frustrating, because we have absolutely no official way to help such users—Apple handles everything related to the store after we submit our app. They test the app, hopefully approve the app, and then host it for downloading. If the app makes it through this process, it’s pretty clear the code itself is good, and any download issues are related to the user’s system.
In theory, Apple (in exchange for their 30% cut of our revenue) should be helping these users solve such problems. But based on what I’ve heard, that’s not usually the case, so they end up writing to me. After a bit of web searching, I found the cause and solution to the problem: Keychain Access.
In particular, the settings for OCSP and CRL in Keychain Access > Preferences > Certificates. For some apps, and for some users (but not for all apps, and not for all users; I don’t know why), these values must be set to “Best Attempt:”
If these two values are set to anything else, it’s possible that some apps and/or updates will fail to download with the above-noted error message. I’ve never personally touched those settings, and I was curious why others might; a friend pointed out this thread, which recommends changing the settings to reduce background bandwidth usage by the ocsp process.
In any event, if you’re having troubles downloading apps and updates—not just ours, but from any developer—from the App Store, check these settings in your Keychain Access app.
As you surely know by now, Apple announced OS X El Capitan (aka Mac OS X 10.11) this week, with general availability this fall. They also released a developer beta, so we were able to give our suite of apps a quick test on the new system.
Given El Capitan’s focus on improving Yosemite, not implementing wholesale changes to the system’s fundamentals, we were hopeful that things would just work.
And that’s what we found: all of our apps appear to work fine. We have not done extensive testing of 100% of the features in 100% of the apps, but they all launch and run, and we tested a number of functions in each app. Even older versions of our apps, such as Name Mangler 2, appear to run fine.
We may have some minor tweaking to do, due to the change in the system font, but the apps themselves are all running under El Capitan. Yes, this includes Butler. Yes, this includes Usher. And Time Sink. And everything else, including Displaperture and the beta Resolutionator. Even our two Safari extensions appear to work.
So if you’re a developer using the preview, or you’re planning on installing the public beta when it’s released, our apps should work as expected. Of course, please let us know if you run into any issues—it’s very difficult for us to test every feature in every app by ourselves.
Now that OS X 10.10 (aka Yosemite) is officially out, here’s a status report on our apps. The short version: they all work fine, with some minor visual oddities here and there.
Our primary apps—Butler, Desktop Curtain, Keymo, Leech, Moom, Name Mangler, Time Sink, Usher, and Witch—are all compatible with Yosemite.
Some of these apps have some cosmetic issues we’ll be addressing via updates in the near future, but they’re relatively minor adjustments. We’re also working on finding a solution for a Yosemite issue that’s affecting some Witch users.
The following run without any issues: Key Codes, as well as our two Safari extension (⌘-Click Avenger and Unread→Tabs).
We do not recommend the use of Open-With Manager, Safari Guardian, or Service Scrubber on Yosemite (or more generally, any release newer than Mac OS X 10.5).
Displaperture and Menu Bar Tint: Both of these apps need to be re-signed for Yosemite, and we will do so in a future update. Until then, to run them you’ll need to manually allow each to run in the Security & Privacy System Preferences panel—on the General tab.
You can either change the “Allow apps downloaded from” pop-up to Anywhere, or click the button you’ll see that asks you if it’s OK to run the apps, even though they’re from unidentified developers. (You’ll see this button after trying to run the app once.)
Overall, the upgrade to Yosemite should be a fairly painless one for users of any of our applications.
Many Tricks