Moom 3.2.11 speeds into existence

May 14th, 2018 by Rob Griffiths

We’ve just released Moom 3.2.11, where the big news is much faster drawing of the full-screen grid when you’re moving and resizing the grid cells. There are a few other changes, including our new in-app log viewer (direct version only), and we squashed a bug related to moving a window to another display then resizing it.

App Store viewers can get the update from the App Store (if not now, then very soon), and direct buyers can update via the in-app updater, or by downloading a new copy from Moom‘s web page.

Witch 4.2 released

April 11th, 2018 by Rob Griffiths

Witch 4.2 is now in the wild, and it contains a lot of goodies for a little “dot one” release. The release notes page has a summary of everything, including some nice new features. Here’s a brief summary on how to use a couple of the new features—the help file has more detail, including screenshots.

See active app’s icon in the menu bar: If you’re using the “Show in menu bar” checkbox to see Witch’s actions in the menu bar, you can now have the icon reflect the frontmost app, in place of the standard Witch icon. Hold down the Option key when selecting the Witch menu item, and the Preferences entry will change to Reflect Frontmost App. Select that to see the frontmost app’s icon in the menu bar (and a checkbox next to the frontmost app in the list).

Control frontmost window’s tab handling: Hold down the Option key while clicking the Mode pop-up in the “List tabs” section of an action, and the pop-up menu changes to indicate that the selection will only affect the frontmost window.

For example, if you want the frontmost window to always treat tabs as windows (i.e. list them separately in the switcher), hold down the Option key, click the Mode pop-up button, then select Frontmost Window: Treat Tabs as Windows from the pop-up menu. You can then select a different behavior (by not holding the Option key) for non-frontmost windows.

On the bug fix front, Witch 4.2 should resolve the occasional crash issue that a small number of users were seeing, gets rid of the annoying phantom Login item some of you were seeing, and greatly—and I do mean greatly—improves the quality of the mini window previews, if you use that feature. There’s lots more goodness in this release, so check for updates and install Witch 4.2 today.

Name Mangler 3.4.1 released

April 9th, 2018 by Rob Griffiths

Name Mangler 3.4.1 has been released, and should be showing in the in-app updater (for direct customers), or in the App Store app (for App Store customers). Direct customers can also download a full copy of the app from our site.

While only a tiny bump in release number, there’s actually a lot of goodness in this update, including…

  • Hold down the Shift key then click to select Files, Folders, and Folder Contents from the “what to rename” pop-up menu—in one click. The clicks you save will help extend the life of your clicking device!
  • Free spacing mode—for regular expression users—can now be toggled off or on in the preferences.
  • You can change Name Mangler’s default action, even setting it up with a series of Actions if you prefer. Set up the Action(s) you’d like to use, then hold down the Option key and select File > Save Default Configuration.
  • Name Mangler’s “traffic light” indicators, which let you know whether a given file was going to be cleanly renamed (green), renamed but with a note (yellow), or not renamed (red) are now distinct in both color and shape.
  • If Name Mangler is scanning a massive (hundreds of thousands of files) folder and you want it to stop, click the Rename button while the scan is in progress, and it will stop.

There are a few other goodies in this release, so check out the release notes for all the details.

Moom 3.2.10 released

October 19th, 2017 by Rob Griffiths

Moom 3.2.10 is out—now for direct customers, and should be very soon (if not already) for App Store customers. What’s new in 3.2.10? Not all that much; the main item is a fix for some users’ crash on launch in High Sierra.

If you’re experiencing this crash, and you use the direct version, you’ll need to download a new copy of the app from the Moom web page—don’t worry, you won’t lose any of your settings. Just copy the new version to /Applications and replace the existing copy of Moom. (Make sure Moom’s not running.)

Beyond that, there were a couple fixes for issues with uBar 4 and Transmit.

Moom 3.2.9 released

August 1st, 2017 by Rob Griffiths

Moom 3.2.9 has been released, and it includes one major change (in addition to some other minor changes) from the prior release: A new full-screen grid option is the default for grid-based resizing; hexagons are still in place, but they’re the non-default choice.

Moom now uses the entire display as the grid. You can still specify your grid dimensions, but you’ll be selecting regions of the entire display, instead of on a slanted hexagonal window. One advantage of this approach—besides not dealing with hexagons—is that you can drag a grid on any connected display, not just the display where the window currently resides.

App Store users should see the update in the App Store very soon now, and direct users can update via the in-app updater, or by downloading a new copy from our site.

Witch 4.1 released

June 7th, 2017 by Rob Griffiths

Witch 4.1 is out, and the big news here is badges: You can now see Mail’s unread message count on Mail icons in the Witch switcher panel. Witch also has a soon-to-be-public API that other developers can use to make it simple to send badge data to other apps, including Witch—hopefully we’ll see more badges coming to Witch in the future.

In addition to the badges, we did a ton of work to improve Witch’s speed when working with slow-to-respond (to Witch’s queries) apps. We’ve also improved cross-Space window switching, and we found and fixed a memory leak that could make Witch’s RAM usage balloon if you used a lot of window previews.

You can find other goodness in the Witch release notes, and you can update to Witch 4.1 either via the in-app updater, or by downloading a fresh copy from the Witch page (you won’t lose your settings).

Moom 3.2.8 released

May 16th, 2017 by Rob Griffiths

Late yesterday, we released Moom 3.2.8, which has only one change from Moom 3.2.7, released the day before. The update is available directly from us (via in-app updater, or by downloading it from our site), and it should be available in the Mac App Store app shortly, if not already.

The one change was to the grid, which switched from rectangular (with the circles of 3.2.7) to the new hexagonal layout, as seen at right.

Why did we change the design? Late last week, we learned there’s a US patent that covers resizing windows using a rectangular grid in a miniature preview image. We learned this when the patent’s owner told us they believed Moom’s grid was infringing on their patent. For now, we have redesigned the grid in such a way that no infringement claim can be made, and we’re working on further improvements.

Note: Comments are closed on this post, as we wish to inform you as to what happened, not to start a debate on software patents in general, or this patent in particular.

Witch 4 switches out of beta

March 30th, 2017 by Rob Griffiths

As of today, the public beta is over, and Witch 4 is officially released. Witch 4 has been on pre-sale for $10 ($6 for Witch 3 upgraders) since the beta started, and those sale prices will continue through Sunday, April 9th, 2017. After the sale, Witch will be $14 (and $8 for upgraders).

So what’s new in Witch 4? A whole bunch of stuff, but here are the highlights:

There’s a ton of other good stuff in there, but rather than list it all out in boring text form, why not download the demo and give it a try yourself?

Buying Witch 4

Buying Witch 4 is easy, though there are slightly different paths depending on whether you own Witch 3 or not, and where you bought it.

Recent Witch 3 purchaser: If you purchased Witch 3 directly from Many Tricks after October 1st of 2016, you already have a valid license for Witch 4—you can start using it as a fully licensed user with your existing license.

If you bought Witch 3 from the App Store after that date, you too have a direct license waiting: You just need to permanently crossgrade to the direct version.

Less-recent Witch 3 direct customer: Buy a Witch 4 upgrade for $6 ($8 after April 9th).

Less-recent Witch 3 App Store customer: First, permanently crossgrade your App Store license to a direct license. After that, you too can buy a Witch 4 upgrade for $6 ($8 after April 9th).

New Witch customer: Buy the full version for $10 ($14 after April 9th).

If you have any questions on the buying process, please don’t hesitate to contact us via email, or using our ticket system.

Usher 1.1.16 released

March 14th, 2017 by Rob Griffiths

Although Usher is retired, that doesn’t mean it’s being ignored. Today’s update adds two new features (really!), and fixes a couple of bugs.

The new features are an option to auto-size thumbnails, and (mainly for those looking to migrate to another app), a CSV export option. For more details on the export, open Usher’s help, and you’ll find some instructions at the top of the first page. If you’re really bored, you can read the full release notes.

Because Usher is no longer available in the App Store, this update is only available to users of the direct version. Usher App Store users, please crossgrade (it’s free) to the direct version in order to get this update.

How Apple’s security system broke some Mac apps

February 23rd, 2017 by Rob Griffiths

Feb 28 2017 update

Apple has responded quickly to address this issue. Their Developer ID page, which I believe is brand new, specifically addresses provisioning profiles and their relationship to the Developer ID certificate. Here’s what they say (emphasis added):

For apps that utilize advanced capabilities with a Developer ID provisioning profile
Gatekeeper will evaluate the validity of your Developer ID certificate when your application is installed and will evaluate the validity of your Developer ID provisioning profile at every app launch. As long as your Developer ID certificate was valid when you compiled your app, then users can download and run your app, even after the expiration date of the certificate. However, if your Developer ID provisioning profile expires, the app will no longer launch.

That section addresses the crashes seen in PDFpenPro and 1Password: It is now documented that an expired provisioning profile will prevent your app from launching. That’s not necessarily good news…but the good news is that this will, going forward, be a much rarer event:

To simplify the management of your Developer ID apps and to ensure an uninterrupted experience for your users, Developer ID provisioning profiles generated after February 22, 2017 are valid for 18 years from the creation date, regardless of the expiration date of your Developer ID certificate.

So any app that uses a provisioning profile created after February 22nd of this year will not crash due to an expired provisioning profile—even if the developer does nothing and lets their Developer ID certificate expire—until February 22, 2035. That’s effectively forever in the world of a macOS app (it’s longer than macOS/OS X itself has existed, in fact.)

Thanks, Apple, for the quick response! We’re leaving the original article posted as a non-techie overview of the Developer ID system; keep reading if that’s of interest to you.


Recently, some well-known Mac apps, including 1Password, PDFpenPro, and Soulver, had a big problem: They all failed to launch. Nothing had changed with these apps (i.e. no updates had been released), and yet they simply stopped working.

So what happened? All three of these apps (and probably some others we haven’t heard from yet) contained an expired code signing certificate. That expired certificate prevented the apps from launching, though no developer would have expected that, based on Apple’s own documentation. And an expired code signing certificate can’t just be renewed to extend its expiration date (like you would a driver’s license); it needs to be replaced with a new non-expired certificate, which requires distributing an update to the app.

Follow me now, if you wish, for a somewhat deep dive into the world of code signing, as I attempt to explain—from a consumer’s perspective yet with a developer’s hat on—what is code signing, why these apps broke, why the breakage wasn’t expected, and other related questions and answers.

Update: AgileBits has a very detailed blog post that covers this issue in even more depth—well worth the reading time.

What is code signing?

Code signing is a digital signature for apps, proving that an app was created by the developer who signed the app, and it allows the operating system to check whether a given app’s code has changed since it was created. Here’s how Apple summarizes it for developers:

Code signing is a macOS security technology that you use to certify that an app was created by you. Once an app is signed, the system can detect any change to the app—whether the change is introduced accidentally or by malicious code.

You participate in code signing as a developer when you obtain a signing identity and apply your signature to apps that you ship. A certificate authority (often Apple) vouches for your signing identity.

Signing apps is a reasonable way to add security to a system without overburdening the end user with authorization dialogs—like the infamous User Account Control (UAC) in Windows Vista, which popped up “Allow this?” dialogs seemingly every 10 seconds.

How does macOS work with signed apps?

On macOS, code signing’s visible front-end is Gatekeeper, as seen in the Security & Privacy System Preferences panel:

macOS ships with Gatekeeper set to only allow apps from the Mac App Store or from identified developers, so it’s a big advantage for a developer to register with Apple and sign their apps: Any unsigned apps require additional authorization work by the end user before they can be run. Would you want to do that extra work when presented with a scary dialog like this one?

This is why almost all mainstream apps are signed, as well as small little one-off apps from single coders: Nobody wants their app to generate the above dialog. (The app in my screenshot, Disk Inventory X, was last updated in 2005—long before signed apps came to be a thing. There’s nothing malicious about it; it was just a good example for the screenshot.)

How do signed apps help keep me safe?

Here’s how Apple explains the safety aspect for users on the Gatekeeper page:

For apps that are downloaded from places other than the Mac App Store, developers can get a unique Developer ID from Apple and use it to digitally sign their apps. The Developer ID allows Gatekeeper to block apps created by malware developers and verify that apps haven’t been tampered with since they were signed. If an app was developed by an unknown developer—one with no Developer ID—or tampered with, Gatekeeper can block the app from being installed.

There are two key security advantages that come from signed apps. The first, as noted above, is that the system can confirm that the app you’re trying to run hasn’t had its code changed since it was signed. So if a piece of malware did manage to modify the binary for a particular signed app, that app wouldn’t launch because its signature would be found to be invalid.

The second big advantage is that Apple can revoke a certificate if a developer were to do something truly malicious. Once revoked, any apps that were signed with that certificate will stop working. Here’s how Apple explains it to developers

Code signing your app allows the operating system to identify who signed your app and to verify that your app hasn’t been modified since you signed it. Your app’s executable code is protected by its signature because the signature becomes invalid if any of the executable code in the app bundle changes. Note that resources such as images and nib files aren’t signed; therefore, a change to these files doesn’t invalidate the signature.

Code signing is a good thing from the user’s perspective; from a developer’s perspective, it adds to the complexity of the build-and-release process, but the benefits outweigh the added complexity.

One element of this complexity is that the certificates do expire, and an expired certificate must be replaced with a new non-expired certificate, which requires distributing an update to your app. But until recently, this hasn’t been a time-critical item, and an expired certificate wasn’t a big deal.

Wait, an expired certificate isn’t a big deal?

Historically, the answer to that question was “No, it’s not.” In fact, Apple still explicitly tells developers that an expired code signing certificate won’t affect existing apps (added emphasis mine):

If your certificate expires, users can still download, install, and run versions of your Mac applications that were signed with this certificate. However, you will need a new certificate to sign updates and new applications. If your certificate has been revoked, users will no longer be able to install applications that have been signed with this certificate.

This is why developers haven’t viewed an expired certificate as a critical issue: It shouldn’t have any effect on already-released apps. To reiterate the point, Apple states so again on another page, even calling it out with a highlight:

The message can’t be any clearer: There’s nothing inherently bad about an expired signing certificate, at least relative to already-released apps.

In fact, you probably have a number of apps on your Mac—or your iPhone—with expired certificates. For example, an older app from a developer who has since gone out of business. Apps from such developers will run just fine, even though they contain an expired certificate. This is a good thing for users, because you don’t need a developer to still be in business to use their app.

Once the certificate data is embedded in the app, the fact that it’s expired doesn’t remove the safety provided by the signature: If a piece of malware modifies an app with an expired signing certificate, the code signing check will still fail (and the app won’t launch), so the user is protected.

Apple can also revoke an expired certificate (in the case of malware) and the app will fail to launch, so the user is protected.

Neither of these safety valves require the certificate to be current, only that the app contains a valid signature, created at the time it was built.

From a developer’s perspective, it’s also good that expired certificates don’t cause apps to fail to run. For example, we distribute old versions of our apps, for users on older versions of macOS/OS X. At some point, the certificates in those apps will expire. If we had to create new builds for all 50+ versions of the apps we distribute, that would be a nightmare. And if we didn’t do that, we’d have a lot of upset users of older versions, complaining that their apps no longer run.

Still, shouldn’t developers replace their expired certificates?

Yes, they should. But as noted above, Apple explicitly tells developers—in at least two places—that they only need these certificates to build new apps or update existing apps. So if you have a certificate that’s set to expire, but you don’t have an urgent need to update an app or create a new app, it’s supposed to be a non-event.

It’s a bit of speculation, but it’s possible (probable, even) that the affected apps’ developers actually had new, non-expired certificates in hand. But those certificates would only be used to create an update to the app, and they’d been told that an expired certificate in an existing app wasn’t anything to worry about.

Another important fact is that simply getting a new non-expired certificate doesn’t solve the problem: The certificate data is built into the app itself, not stored externally somewhere where a newer version can be retrieved. To get their new certificates into their apps, these developers would have had to push an update to users—and unless they had a minor update ready to go, the sole purpose of the update would be to replace the expired certificate.

Most developers dislike releasing numerous updates, especially updates with only one change (assuming it’s not a critical bug fix), and again, Apple tells developers that an expired certificate isn’t a big deal. A normal business approach to this situation would be…

  1. Set up the new certificates, so they’re ready for the next update.
  2. When the time comes for the next update, the build will contain the new non-expired certificate data.

But because the expired certificates broke these apps, the developers had to release an update just to refresh the certificate data. That’s not good for developers or users.

Why exactly did these apps break?

Given Apple’s position that an expired certificate should have no impact on an app’s ability to run, there’s no doubt that Smile and AgileBits and others were very surprised by reports of their apps failing to launch. So really, why did these apps fail?

The common thread in all three of these apps is that they included support for using iCloud for sync or storage. Access to iCloud was originally restricted to App Store apps, but that changed with the release of Yosemite: Now any registered developer can include iCloud support in their apps.

To do so, a developer needs to flip a switch in Xcode to add iCloud support:

Flipping the toggle from Off to On creates something called a provisioning profile. This profile says “It’s OK for this app to use iCloud, even though it’s not in the App Store.” This was best explained by Smile’s Greg Scown to Adam Engst in this tidBITS article:

What’s new with PDFpen 8 is that, in addition to being code signed, it has a provisioning profile, which is essentially a permission slip from Apple that’s checked against an online database in order to allow the app to perform certain actions, called entitlements. For PDFpen, the entitlement that’s being granted is the capability to access iCloud despite being sold directly, rather than through the Mac App Store, a feature that wasn’t possible until about a year ago.

The only apps that crashed due to expired certificates (so far, at any rate) were those that used this iCloud provisioning profile outside of the Mac App Store. What happened with PDFpenPro and the other apps is that the expired signing certificate rendered the iCloud provisioning profile invalid. The invalid provisioning profile, in turn, prevented the app from ever launching.

According to everything Apple has told developers, this should not happen. To the best of my knowledge, developers were never given any warnings about expired certificates and iCloud provisioning profiles. If they had been told, it’s a fair certainty that they all would have updated their apps with new certificates before the expiration date. Of course, this wouldn’t help any user who didn’t update their copy of the app before the certificate’s expiration date.

What made the situation even worse is that the provisioning profiles are checked by the system itself, before the app even runs. As a result, the app can’t tell the user something is wrong, because the app didn’t actually launch. Again, from tidBITS:

An app called taskgated-helper determines this even before PDFpen’s code runs, so there’s no way for Smile to detect the error condition and present an error to the user.

So the app can’t tell the user what’s going on, and even worse, the OS doesn’t tell the user what’s going on: The app just seemingly dies in an instant. That’s bad for the user, and bad for the developer, because they’re blamed for something they didn’t even know was occurring (because their app never loads, and no crash reports are generated). If the OS is going to kill the app, the OS should tell the user why it did so, so the user has some understanding about the problem.

Will this happen again in the future?

First, from our perspective: As we currently don’t use iCloud (or other) provisioning profiles, our behavior won’t change: An expired certificate is not reason alone to update an app. And as discussed above, doing so for all old apps with (eventually to be) expired certificates would be a nightmare.

For developers who do use iCloud (or other) provisioning profiles, it appears that unless Apple fixes something, they will have to pay very close attention to their certificate expiration dates, and make sure they push out app updates (and hope all their customers update) before the certificates expire.

How can I find out more about code signing in apps I use?

As a user, if you’re really interested in this stuff for some reason, there’s an app called RB App Checker Lite that can take a look inside any application and see its certificates (and a bunch of other data).

The output is definitely way up on the geek scale; here’s what it shows for Flying Meat’s Acorn image editor:

Here I’ve clicked the arrow next to “The signature contains 3 certificates” in order to view the Flying Meat code signing certificate. As you can see, it appears their certificate was recently replaced, given the nearly-five-years-from-now expiration date.


Code signing is a complex topic; hopefully this article made the subject a bit clearer, and you gained an understanding of how it works, and for how seemingly-irrelevant expired certificates brought down a number of Mac apps.