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.

Usher will be stepping aside

February 14th, 2017 by Rob Griffiths and Peter Maurer

After many long conversations, we have decided to retire Usher, our media management app: Effective March 1st, 2017, Usher will no longer be available for purchase. We will update it to fix issues that arise, but no further development will occur.

If you’ve always wanted to own Usher, you’ve got about two weeks left to make the purchase. (It’s not being abandoned, we’re just retiring it from active development, so you will be supported. However, please read the Q&A before you decide to purchase Usher.)

So what does this mean for you as an Usher user? We figure you might have questions, so we’re going to do our best to answer them here. Anything we don’t address, please feel free to bring it up in the comments, or by emailing us directly.

Why are you retiring Usher?

Usher does its video magic through QuickTime. Not the newer-and-current QuickTime X, but the original QuickTime. This lets Usher do all sorts of neat stuff, but also means it can break due to an event that crashes QuickTime—most Usher crashes are actually QuickTime crashes which then take Usher out, too.

QuickTime is very old, and obviously no longer updated. (It’s so old that it’s not even 64-bit code.) Newer video formats may cause issues, and we can’t resolve those issues in Usher because they’re actually in QuickTime. Given these age-related issues with QuickTime, we’re no longer comfortable selling and supporting Usher to new buyers, so we’ve decided it’s retirement time.

Why not make Usher work with QuickTime X?

As much as we’d love to work on integrating QuickTime X into Usher, the unfortunate reality is that we can’t presently justify the time investment it would require. Even when new, Usher served a niche audience of people who obsessed about their video collections and found iTunes/iPhoto weren’t sufficient for their needs. Unfortunately, this niche started small and has only gotten smaller over the years, and the move to streaming media instead of physical or electronic-but-owned media files has only made it worse.

Beyond the market size, we can’t just delete “old QuickTime” and insert “QuickTime X” and be done with it. The two are very different, so much so that we’d need to totally rewrite the engine that drives Usher. And that’s a huge job…and one that wouldn’t ever be paid back in sales, due to the limited market size.

The double whammy of a lack of potential customers and huge time investment to rewrite Usher mean we can’t presently justify the work required to make Usher use the newer QuickTime X.

What happens to my copy of Usher?

Nothing at all. Like all our apps, Usher is a standalone program, so it will continue to run just fine in macOS Sierra (or whatever release you’re using it in).

Going forward, we’ll work to fix any bugs that crop up, and do our best to keep Usher working with new releases of macOS. We can’t make any promises, of course, but both of us use Usher, and we’d like to keep it working for as long as possible without investing a huge amount of time in the project. (Of course, if Apple breaks “old QuickTime” at some point, that will be the end for Usher. Let’s hope they never do that.)

I bought from the Mac App Store, what happens to my version?

All Mac App Store buyers are encouraged to crossgrade to our direct version—it’s free, and you get a permanent Usher license so you never need use the App Store version again. The App Store version should get any bug fixes we release, but we’ve never tried updating a removed-from-sale app before; migrating to the direct version will ensure you always get these bug fixes. By migrating, you’ll also be able to reinstall at any time by downloading the app again from our server and applying your license file.

Can I get a refund?

If you bought directly from us, you can get a refund within 60 days of purchase. If you bought from the App Store, Apple’s official policy is no refunds, but they’ve been known to offer them if you ask nicely (and rarely).

But again, the app will continue to work fine, so there’s no need for a refund on the basis of non-functionality. But if you’d like your money back and you’re within the 60-day window, just ask.

Why aren’t you open sourcing Usher, instead of retiring it?

We can’t open source Usher because it contains code that we share between many of our apps, and we’re not willing to make that code public at this time.

Why not give it away for free?

In short because we wouldn’t be able to support the users. Yes, we could say “no support included,” but if someone has a problem with Usher and they lose their library, neither of us would be comfortable saying “Sorry, no support, it was free.” That’s not how we work. So we’d wind up with a crush of free support requests for one of our largest, most complex apps. That’s not a sustainable model.


It’s never easy to say goodbye to an application, and Usher is no different. Unfortunately, between the old QuickTime technology and small (but very enthusiastic) audience, we cannot currently justify the work required to make the program into what we know it could be.

Time Sink 2 is on the clock

January 17th, 2017 by Rob Griffiths

Time Sink 2 iconTime Sink 2 is out today—yes, it’s a major update in version numbers, and no, it won’t cost you a cent. That’s right, Time Sink 2.0 is a free new major version, for both direct and App Store buyers.

Why free? Because all though we’ve done a ton of behind-the-scenes work to make Time Sink an even better time tracking app (so it’s indeed a major upgrade to us), the user-visible new features may not feel like typical “oh wow this is a MAJOR update!” material to you. So instead of trying to justify charging for the upgrade, we decided to give it to everyone for free. (But hey, if you want to buy another copy or gift one to a friend, we won’t mind—it’s still just $5.)

So what’s new in Time Sink 2? We won’t bore you with all the many behind-the-scenes changes, other than to mention that Time Sink is now sandboxed, so we can add new features to the App Store version to keep it in sync with the direct version—hooray!

Here’s the stuff you can see and work with as a Time Sink user:

  • Ad-hoc timers can be used to track non-Mac activities, such as phone calls or client meetings.
  • All timers can be paused via an assignable hot key, and can be set to resume automatically when activity resumes.
  • A pop-up menu at the bottom of the Activity Report window lets you easily select time frames like today, this week, this month, or this year.
  • Define the “start of day” time for the “today” Activity Report view. No longer must you start working just after midnight.
  • Use window title filters to merge windows from apps that include always-changing info in their window titles, as when Photoshop appends @50%, @75%, etc.
  • Exported reports can be opened in Time Sink to view historical data.
  • View time usage in the Organizer as percentages of total time instead of hours/minutes.

Finally, there are a couple of new themes for the Activity Report:

Two new Activity Report themes join the original

The original purple (left) is joined by light (center) and dark (right); the blue shown in the dark theme shot will be replaced with whatever you’ve set as your macOS highlight color (System Preferences > General).

How to update

Direct customers can get the update via in-app updating; App Store customers should see the update in the App Store app soon, if not already. (Just one note of caution: Time Sink 2 requires OS X 10.8 or newer; if you’re on OS X 10.7, you’ll want to stay with the original Time Sink. See the museum for links to older versions.)

How-to: Track top-level web site usage with Time Sink

January 2nd, 2017 by Rob Griffiths

Our time-tracking app Time Sink relies on window titles to track your activities. This approach works great for most use cases, as window titles are supplied by the vast majority of apps out there, which means Time Sink is able to keep an eye on nearly everything you do.

But when browsing the web, relying on window titles can sometimes be problematic: Many sites don’t include any site-specific information in their window titles. For instance, a news site may just have the title of the news article as the window title. So if you were interested in finding out how much time you spend on that news site, Time Sink apparently wouldn’t be able to help, because there’s no way to tell which site those news stories came from.

Other sites do include some site-specific data in their window titles, but what that is will vary by site, as well as where it appears within the window title.

The good news is that Time Sink can track site-wide time usage for both types of windows—it’s relatively simple for sites that include site-specific data in their window titles, and it’s somewhat more involved for sites that do not.

The relatively simple way

Some sites include a bit of unique information in each page’s title, which makes tracking them simple. YouTube, for instance, appends ” – YouTube” to every window title:

Any site that does this is easy to track with a pool, regardless of which browser you use. (This example assumes Safari.)

  1. Drag any opened YouTube window (in Time Sink’s Organizer window) to the Pools section of the Organizer window, and drop to create a new pool.
  2. Expand the Safari (assuming you used Safari, of course) folder in the Pools section, then expand Safari (the app within the folder) to reveal the window title.
  3. Select the window title and press Return to edit it. Change the window’s title to * – YouTube and press Return again. The * is Time Sink’s wildcard, and it means “match anything.” In this example, it will match any number of characters that are followed by the ” – YouTube” bit.

That’s it; Time Sink will now add all time spent on any YouTube page (in Safari, at least) to that pool. In general, there are basically three versions of the window title that you could see. Here’s how you’d edit each in a Pool to track the site in aggregate:

  • unique tidbit – words ==> unique tidbit – *
  • words – unique tidbit ==> * – unique tidbit
  • words – unique tidbit – words ==> * – unique tidbit – *

Related tip: If you want to track YouTube usage in any browser (actually, any app that can load web pages and includes page titles), right-click on the Safari application entry in the pool, then select Track Across All Applications:

This will change the application name from Safari to Any Application, and now all your YouTube time will be captured in one pool. (Are you sure you want to do this!?) You can also, as seen in the screenshot, change the name of the pool to reflect that it’s no longer Safari-specific.

So much for the simple sites…

Announcing the Witch 4 public beta

December 22nd, 2016 by Rob Griffiths

It’s been a long time since we released a major update to Witch. How long has it been? It’s been 27 minor updates long, that’s how long (nearly seven years, if you count like a normal human).

But the long wait is (nearly) over…


Hey, are those tabs in Safari or separate windows?

Say hello to Witch 4. You can try it out for yourself, today, via the Witch 4 public beta (with special pre-release pricing, too).

And yes, Witch 4 has learned more than a few new tricks…here’s just one…

If the above images have you convinced you need the beta, well, give it a try! But you should also keep reading, as there are some important details about the new features, the beta itself, and the pre-sale.

The pre-sale? Glad you asked: During the public beta, new users can buy Witch 4 for just $10 (normally $14); users of prior versions of Witch can upgrade for only $6 (normally $8). And yes, this includes App Store buyers. There are more details on the pre-sale at the end of this post.

What’s new?

Horizontal switcher

Obviously, Witch now has a horizontal mode. And anything you can do with “vertical Witch” you can also do with “Horizontal Witch.” But more on that in a bit…

Switch to tabs

That’s right, tab support! Witch can now switch directly to any tab in many apps, including the biggie, Safari…

Switch between tabs

“What other apps’s tabs will work?,” I can already hear you asking. Any app that uses the built-in support for tabs in macOS should work just fine. So all of Apple’s apps work, obviously, but so do Chrome and Opera. (Firefox, iCab, OmniWeb, and Vivaldi don’t use the system-provided tab feature, so their tabs won’t show in Witch. If you want browser tabs with Witch, use Safari, Chrome, or Opera.)

Switch to non-standard windows

If you’re like me, your toolbar is full of useful add-ons, things like Moom and Keymo, and maybe even some stuff from other developers.

The windows that open from these menu bar apps aren’t normal—they don’t show in the Command-Tab switcher, for instance. But they do show in Witch 4:

No more window shuffling to find that one settings window!

Multiple switchers

Witch 4 lets you have many switchers—one vertical and one horizontal, for instance:

Each switcher can be set to show windows or just apps. Each can have a different sort order. Each can separately list tabs or not. You get the idea. There are many actions to choose from, too:

These were all choices in the old version of Witch…except for that first one, which when used with a horizontal switcher, gives you a nicer-looking alternative to the built-in Command-Tab switcher. And now you can easily add and remove any of these actions from your collection of active switchers.

Search window titles

Even with Witch, switching between many open windows can be time consuming—you have to find that one particular window in a potentially huge list of windows. But with Witch 4, it’s easy…

It doesn’t get much easier than that!

Switch via the menu bar

Witch 4 includes an optional menu bar mode that can be added to any and/or all actions you create.

Switch apps via the menu bar. Switch windows and tabs via the menu bar. Switch just the frontmost app’s non-minimized windows and tabs via the menu bar. The possibilites are endless…well, no, that’s a cliche, they aren’t endless. But they are many!

Lots more

There are other new things, too, but we’ll leave them for you to discover during your explorations of the beta. Speaking of the beta…

About the beta

Please download the beta and put it to use, and send us feedback. We’d prefer it if you could use the Witch Talk Google group (so everyone can see what’s being discussed), but feel free to use any of the other support methods. We welcome all feedback—bugs, feature requests, and how-do-I questions are all fair game.

Note that Witch 4 will only be available directly from us, because it cannot be sandboxed, which is a requirement for the App Store. (We have a migration process for App Store customers…keep reading.)

About the pre-sale

Witch 4 will be available at the same price as Witch 3—$14 for new customers, $8 for upgraders.

During the public beta period, however, the price is just $10 for new customers and $6 for upgraders from older versions of Witch—including App Store users.

Also, anyone who purchased Witch 3 after October 1st already has a valid license for Witch 4 —you can start using it as a fully licensed user with your existing license.

App Store buyers

Because Witch 4 cannot be sold in the Mac App Store, you’ll have to purchase directly from us in order to use Witch 4. The good news is that as an existing customer, we’ve figured out a way to get you the upgrade pricing, too. Here’s how:

  1. Permanently migrate to the direct version of Witch 3 by following these instructions.
  2. Purchase an upgrade license for Witch 4.

If you purchased Witch 3 from the App Store after October 1st, you only need to do step one—the license you’ll receive will work with Witch 4.

If you have any questions on the beta or the pre-sale, let us know! Otherwise, enjoy the beta, and please, send us your feedback!

Three minor updates have escaped into the wild…

December 22nd, 2016 by Rob Griffiths

…and while you’d think that’d be enough for one day for us, we are Many Tricks, after all. So a bit later today, stay tuned for an announcement witchwhich you may find of interest.

As for the escapees, they are…

  • Butler 4.1.23, which includes some comestic improvements and a couple of bug fixes. [release notes]
  • Resolutionator 1.1.1 fixes a color depth issue on newer laptops that could cause Resolutionator to not show any resolutions. [release notes]
  • Usher 1.1.15 has a ton of changes, most of which aren’t directly visible. But we’ve improved memory usage, speed of previews, crawler performance, and more. [release notes]

Butler and Resolutionator are direct-only apps, so you should get notified by each app that there’s an update available, if you haven’t disabled that setting in Preferences. Or you can just download the full app from our site again; you won’t lose your settings if you update that way.

Usher is available both direct and in the App Store, and the App Store update should be showing up any minute now, if it’s not out already.