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.

Direct vs. Mac App Store: Where to buy Mac apps?

December 9th, 2016 by Rob Griffiths and Peter Maurer

One of the more-popular questions we receive is “should I buy your app directly from you, or from the Mac App Store?” The factual no-opinion-involved answer to this question is that it’s your money, so you should buy from whichever source you prefer to use. That has been, and will always be, our “corporate” answer to that question.

With that said, if you ask either of us for our opinion on the best place to buy Mac software, here’s our opinionated answer:

We strongly recommend buying direct over using the Mac App Store.

At a personal level, we both always try to buy direct, using the App Store only when there’s no direct alternative.

Why do we think you should buy direct? Because we feel the advantages of buying from the Mac App Store are greatly outweighed by the disadvantages of buying from the Mac App Store.

Here’s a comparison of the two methods of buying, with what we view as some of the pros and cons of each.

Mac App Store – Pros

  • No need to manage serial numbers and/or license files, or disk images containing the apps. Buy from the store, install and reinstall from the store, and never worry about where you saved that last-used-six-years-ago license number or file when you need it again.
  • App updates for all App Store purchases are handled by one app, simplifying update management.
  • You remain anonymous to the developer, as Apple provides no customer information to them. 1Based on emails we receive, many App Store customers believe we do get their info. That is not the case.
  • Apple is collecting your money and credit card information, not some developer and/or a payment processor you’ve never heard of and know nothing about.
  • Apps are sandboxed for your protection. A sandboxed app is limited in the damage it can cause, even if it’s malicious.

In summary, the App Store makes it really easy to install, update, and reinstall apps on one or more Macs. Everything is done through one program, you don’t need to visit developers’ web sites, you don’t have to deal with licensing issues, and the sandbox protects you from dangerous code.

Mac App Store – Cons

That’s a long list of cons, and many of them are onerous. No refunds, when coupled with no trials, means that you’re buying before trying without a chance at getting your money back—and buying solely based on a handful of screenshots and other users’ reviews.

If Apple offered refunds or trial versions, things wouldn’t be quite so bad. But when neither are offered, that’s a possibly expensive hit to your pocketbook.

Note: The data for the following Direct pros and cons is based on Many Tricks’ own policies—although most other indie developers have similar policies, we’re not trying to speak for them here.

Direct – Pros

  • Money back guarantee—our site says 60 days, because that’s what our payment processor offers. But if you’re unhappy beyond that for some reason, talk to us and we’ll work something out.
  • Free trials of all our apps. There’s no need to buy before you try, you can download fully functional versions of every program we sell, so you can give them a good test run before you plunk down your money.
  • Upgrade pricing for existing customers. Generally, if we release a major new version, existing customers will be able to buy it at a discount. (This isn’t true for some of our really inexpensive programs, like Leech at $6.) Existing customers are rewarded for being customers, and save some money on the new version.
  • Developers get more of your money. Apple charges 30% of the list price for each unit sold in their store. Direct sales are notably less expensive, typically in the 8% to 15% range. More money to the developer means they’re more likely to be in business in the future, and if you like their apps, that’s a good thing for you, too.
  • Our apps can be installed on as many Macs as you personally use, with just one purchased license file.
  • We don’t care what country you live in, nor what country you move to, when using our apps. If you own our apps and manage to get on the first Mars colonization flight, you’re welcome to use our apps on Mars, too.
  • The apps we sell direct are not sandboxed, even if (as with Leech and Name Mangler) their App Store counterparts are. And while we do our best to make the two versions functionally equivalent, the sandbox sometimes makes that impossible. For example, there are some differences with Name Mangler that we couldn’t avoid.
  • We have no way to remove or disable an app you’ve purchased from us. Once you’ve bought it, you can use it for as long as it works. Even if we decide to discontinue an app, you’ll still be able to install and use it (assuming it runs on whatever version of macOS is current at that time). Just keep a copy of the download somewhere, and you can use it for a very long time.

Direct – Cons

  • License management. No doubt about it, this is the biggie. We send you a license file for our apps, and you need to keep track of it. You need to copy it to other Macs you use. You need to back it up. You need to restore it when you get a new Mac. You need to be able to find it when you rebuild your hard drive, and you’re hard up against a work deadline. If you bought an upgrade, you need to track both the original and the upgrade license.

    It’s a complex-enough task that we have a blog post that deals just with the subject of saving license files. The App Store definitely wins this one.

  • Updates are per-app, not all-in-one-app. Granted, our apps will check for updates and inform you of when they’re out, but you still have to update them each separately.

    Add in a handful of other non-App Store apps, and suddenly it seems like all you’re doing is updating apps. So yes, the App Store makes this simpler, too. (The good news is that our updates aren’t a rapid-fire affair, so it’s not like updating is a non-stop project.)

  • Anonymity lost. When you buy direct, we know who you are. We have your name, email, and other data. (We do not have any of your financial data; that’s all handled by our cart provider.)

    In the six years I’ve worked here, though, we have never contacted our customers en masse for any reason. We’ve never even emailed the customer base to inform them of a new major release. Should we? We probably should; it would probably help sales. But we both dislike direct email marketing, so we don’t do any of it.

  • Possible exposure to payment fraud. Indie developers need to have a system for collecting payment for their apps. We use FastSpring, which in turn lets buyers use a credit card, PayPal, Amazon, and a few other sources. But other developers may try to host this process themselves, or use a provider you’ve never heard of an know nothing about … and that’s scary, as you’re trusting the developer’s processor with your financial data.
  • Unknown security issues with the developers’ apps. When you buy direct from a developer, there’s usually no third party who has reviewed the app to make sure it does what it says it does, and that it doesn’t do anything malicious.

    In theory, you do get that protection in the App Store, as every app must pass Apple’s review. Yet we’ve still seen some undesirable apps make it into the App Store, because it’s possible to hide malicious behavior quite deeply. But when buying direct, you’re almost always on your own.

To help mitigate these risks before you buy (or even try) an indie developer’s apps, find public reviews of the developers’ apps. See how long they’ve been in business, and what other apps they sell. See how much they reveal of themselves and their company on their web site. Check out their payment processor—how long have they been in business, and what partners (i.e. PayPal, etc.) do they work with? Do the developers disclose their names, company mailing address and/or phone number on their web site? Do they tell you anything of their background, or the company’s background? After finding answers to these questions, if you’re not comfortable with what you’ve discovered, then don’t try or buy the app.

By buying direct, you’re taking a more active role in your software: You’re responsible for the license, and for installing updates for each app. You’re also responsible for doing your homework before you purchase. In exchange for these tasks, most developers offer free trials, money back guarantees, discounted upgrades, and fewer restrictions on where you use your purchased apps.

In the long run, buying direct helps developers stay in business, which is good for you and good for them. It gives you more control over your software, which is good for you. But it does require more work than does the App Store. In this case, though, it’s our opinion that buying direct is worth the extra hassles involved.

Name Mangler 3.4 is at your service

November 22nd, 2016 by Rob Griffiths

Name Mangler 3.4 is out now, and though there are only three changes in this version, we felt one of them was major enough to merit a full dot increase in the release number. You can read the details on the release notes page; two of the three changes are fixes, but the third…

The third is a nifty new feature best summarized with a screenshot:

That’s right, Name Mangler can now create Services out of your renaming actions. Services are available either via the Services menu in Finder, or (more usefully) via the contextual menu you get if you right-click on a selection of files. You can read all about this in the Menus (File) section of Name Mangler’s help, but the basics are, well, basic:

  1. Create your renaming action
  2. Choose File > Create Context Menu Service
  3. Enter a name, but do not change the save location in the dialog that appears
  4. Select some files in Finder, right-click, and choose your service from the contextual menu. (Or as above, go old school and use the Services entry in the Finder menu.)

When activated, what happens next depends on whether Name Mangler is running or not. If it’s running, Name Mangler will activate with the files populated, showing the effect of the Service you applied. All you need to do is click Rename, and you’re done.

If Name Mangler isn’t running, the service just does its thing on the selected files: They will be renamed without any interaction on your part. Easy!

To make your renaming Services even easier to use, you can assign them keyboard shortcuts, in System Preferences > Keyboard > Shortcuts > Services. Once assigned, you can rename files with a quick press of a hot key. We think this feature makes Name Mangler even better, and hope you find it useful as well.

Direct users can get the update via the in-app updater, or by downloading the full app from our site. App Store users should see the update in the App Store app—if not already, then very shortly.