How-to: Give Moom extra room to work in El Capitan

June 30th, 2015 by Rob Griffiths

If you’re a developer (or public beta tester) using El Capitan, you’ve probably discovered that you can hide the menu bar (via System Preferences > General > Automatically show and hide the menu bar).

If you use this feature, and you’d like Moom to use the extra pixels afforded by the hidden bar, here’s how. Open Terminal (no need to quit Moom first), paste the following text, and press Return:

defaults write com.manytricks.Moom "Ignore Menu Bar" -bool YES

From now on, Moom will freely place windows in the top portion of the screen. This change will affect everything Moom does—those 23-ish pixels at the top of your display are now part of Moom’s real estate.

Later on, if you decide you don’t like the auto-hiding menu bar and disable it, you’ll want to also disable Moom’s use of that space—lest you find windows partially hiding behind the menu bar. To do that, go back to Terminal (again, no need to quit Moom), paste this text, and press Return:

defaults write com.manytricks.Moom "Ignore Menu Bar" -bool NO

With that command done, Moom will once again respect the menu bar’s real estate.

Avoid download issues with App Store purchases

June 22nd, 2015 by Rob Griffiths

Over the last few days, several users let me know they were unable to download our apps from the Mac App Store. They reported that they were receiving this error message when trying to purchase or update:

App Store Error: Failed to verify the preflight file. It is not signed by Apple.

Emails like this are frustrating, because we have absolutely no official way to help such users—Apple handles everything related to the store after we submit our app. They test the app, hopefully approve the app, and then host it for downloading. If the app makes it through this process, it’s pretty clear the code itself is good, and any download issues are related to the user’s system.

In theory, Apple (in exchange for their 30% cut of our revenue) should be helping these users solve such problems. But based on what I’ve heard, that’s not usually the case, so they end up writing to me. After a bit of web searching, I found the cause and solution to the problem: Keychain Access.

In particular, the settings for OCSP and CRL in Keychain Access > Preferences > Certificates. For some apps, and for some users (but not for all apps, and not for all users; I don’t know why), these values must be set to “Best Attempt:”

Keychain Access' Certificates prefs

If these two values are set to anything else, it’s possible that some apps and/or updates will fail to download with the above-noted error message. I’ve never personally touched those settings, and I was curious why others might; a friend pointed out this thread, which recommends changing the settings to reduce background bandwidth usage by the ocsp process.

In any event, if you’re having troubles downloading apps and updates—not just ours, but from any developer—from the App Store, check these settings in your Keychain Access app.

The Yosemite, the Witch, and the App Store

June 11th, 2015 by Rob Griffiths

Many moons ago, we were alerted to a glitch in Witch‘s functionality in Yosemite (and in Mavericks 10.9.5 before that): The inability to properly switch windows across displays when those displays are in separate Desktops (nee Spaces). What would happen is that the app would switch, but the window would not gain focus.

We found a workaround for the problem back in November, posted a beta for users affected by this issue, and submitted an update to the App Store. And that’s where the troubles began…

Apple rejected the update, objecting to some code we’ve had in there since day one. Unfortunately, that code is pretty critical to how Witch works, and we’ve been unable to find another way of doing what we need to do.

So after months of trying, and talking to Apple about the issue, we’ve decided to release the update for our direct users, as we’re uncertain when (or if) we’ll be able to update the App Store version. So direct users, check for updates, or just download the full version of Witch.

If you’re using OS X 10.9.5, please do not update at this time! We’re trying to track down an issue that’s causing Witch to not activate on some users’ systems. If you’ve already updated, you can reinstall Witch 3.9.4.

But what about App Store users, you ask? If you’re affected by this problem, we suggest you switch to the direct version of Witch by following these instructions. This isn’t a full “direct sales” license, but it works just like one. The only difference is that it’s not portable between Macs; if you use Witch on more than one Mac, you’ll need to follow the instructions in the blog post to use the direct version on each of those Macs.

We don’t like having two different versions of Witch out at the same time, but in this case, it’s the best course of action for you, our users. If you have any questions about this, or the App Store licensing process, you can comment here, or use the Witch Support Page to ask for additional help.

Our apps and El Capitan compatibility

June 10th, 2015 by Rob Griffiths

As you surely know by now, Apple announced OS X El Capitan (aka Mac OS X 10.11) this week, with general availability this fall. They also released a developer beta, so we were able to give our suite of apps a quick test on the new system.

Given El Capitan’s focus on improving Yosemite, not implementing wholesale changes to the system’s fundamentals, we were hopeful that things would just work.

And that’s what we found: all of our apps appear to work fine. We have not done extensive testing of 100% of the features in 100% of the apps, but they all launch and run, and we tested a number of functions in each app. Even older versions of our apps, such as Name Mangler 2, appear to run fine.

We may have some minor tweaking to do, due to the change in the system font, but the apps themselves are all running under El Capitan. Yes, this includes Butler. Yes, this includes Usher. And Time Sink. And everything else, including Displaperture and the beta Resolutionator. Even our two Safari extensions appear to work.

So if you’re a developer using the preview, or you’re planning on installing the public beta when it’s released, our apps should work as expected. Of course, please let us know if you run into any issues—it’s very difficult for us to test every feature in every app by ourselves.

Moom and Usher updates released

January 13th, 2015 by Rob Griffiths

Today we updated Moom (to 3.2.1) and Usher (to 1.1.10). Moom gains a Yosemiteized interface, and full support for Yosemite’s dark mode. Usher’s got some behind-the-scenes changes, along with a fix for a search field glitch in Yosemite.

App Store versions have been released, and will trickle into the App Store over the next hour or so. Direct customers can update via in-app updates, or by downloading a new version from the respective web page.

Something different: The Many Tricks holiday sale

December 15th, 2014 by Rob Griffiths

As promised, today we’re announcing both something new and something different … and the something different is our holiday sale. We’ve tried to keep it as simple as possible:



From now through end-of-day (USA Pacific time) on December 31st, 2014, all of our applications are 50% off—whether you buy them from us or from the App Store.



Note: App Store prices are 50% off, except in cases where the price would wind up on a $.50 split (because the App Store forces all prices to end in $.99). So for those “fifty cent split” apps, the App Store versions of each app will be $0.49 more expensive than buying directly from us.

Also note: Upgrades are not on sale. If you’re an existing user of an old version of one of our apps, just buy the full version at the sale price. It will be cheaper than the upgrade!

Finally note: If you want to save even more, just buy four or more of our apps, and you’ll save another 20%. This deal only works on purchases from our site; the App Store doesn’t allow us to create multi-item discounts.

No coupon code, no secret handshake, no treasure hunt … everything’s just half off for the next couple of weeks.

Gift purchases: If you’d like to give one or more apps as a gift, here’s how to do it:

  1. Load the Gift Our Apps web page.
  2. Select which product you’d like to gift, enter the recipient’s name and email address, then click Add to Cart.
  3. Buy whatever else you want for yourself, or proceed to checkout if it’s just a gift. (To give more than one gift, click Continue Shopping on the pop-up cart window, then change the information on the gift page and click Add to Cart again.)

When you complete your purchase transaction, you’ll receive the usual confirmation about payment, but you’ll also receive license files for the gift recipients. The email will read “Hello [your name]: Here is your license file for [product], made out to:,” followed by the recipient’s name and email address and the rest of the license email (and attached license file, of course).

You can then copy and paste the license file email (make sure you include the attachment, and probably exclude the first line with your name in it) in a new email to the recipient, and they’ll get the gifted app directly from you.

Something new: Resolutionator

December 15th, 2014 by Rob Griffiths

resolutionator_iconThe “something new” portion of today’s promised “something different, something new” is a public beta of Resolutionator. And what is Resolutionator? As noted in our teaser last week, it’s a tool to help you with your resolutions in the new year.

resolutions1No, not those resolutions, but resolutions like those seen at right. That’s right; Resolutionator brings back the menu bar resolution switching feature that Apple saw fit to remove at some point in the past.

But as with all our apps, Resolutionator is capable of many additional tricks. You can…

  • Use more resolutions than those available in the Displays System Preferences panel.
  • Switch resolutions via an onscreen menu, accessed via a user-defined hot key.
  • On some Macs, use resolutions greater than the available pixels. For instance, you can set a 13″ Retina MacBook Pro to display at 2880×1800 pixels, greater than its 2560×1600 true resolution. It sounds like magic, but it’s real, and it works.
  • Set resolutions for any attached displays via either the menu bar or floating resolution switcher.

Who might find Resolutionator useful? Owners of Retina Macs who find themselves switching between “OMG it’s stunning!” retina mode and “I need to see more data” more space modes. Users with multiple displays who change resolutions on one or more of the connected displays. Users of Macs with smaller screens (11″ MacBook Air, anyone?) who occasionally wished they could see more data on their screen. And probably many other people who have usage scenarios we haven’t even thought of yet.

We’ve been using Resolutionator internally for a few months, and we think it’s nearly ready to go. But before we release version 1.0, we’d like to get some feedback from the real world…and that’s where you come in: If you’d like to help beta test Resolutionator, drop us a line and we’ll provide a download link and some “getting started” instructions.

Note: Resolutionator is just an app that uses APIs provided by OS X to get and set display resolutions; it can’t harm your display by putting it into a mode it can’t support (because the monitor tells OS X what it can do, and Resolutionator uses those values for its list of available resolutions).

So if you’d like to help us test, drop us a line and we’ll get you set up.

Coming Monday: Something new, something different

December 12th, 2014 by Rob Griffiths

The holiday season is in full swing, and come Monday (December 15th), we’ll be joining the festivities. How, exactly? Tune in Monday for the full details!

For now, let’s just say that the “something new” will help you with your resolutions in the new year, and the “something different” will directly affect your wallet this holiday season.

In other words, if you’re thinking of buying something from us soon, you may want to wait until Monday to see what we’ve got to say!

Witch switching glitch ditched—help us test the fix!

November 16th, 2014 by Rob Griffiths

Our apologies for the lyrical headline, but after fighting OS X’s Spaces feature for a few months, we couldn’t resist a bit of humor…

Excellent news, multi-display Witch users: we believe we have worked around the most-annoying Witch issue in OS X 10.9.5 and Yosemite (OS X 10.10): The inability to activate a window on another display when switching via Witch. The window would pop to the front, but not activate.

Apple changed something in OS X 10.9.5, and left it changed in OS X 10.10…and whatever it was they changed, it broke Witch’s ability to properly switch windows across displays. You’d only see this problem if you had “Displays have separate Spaces” enabled in System Preferences > Mission Control. But as this is the default setting, most users were experiencing the problem.

If you’d like to help us confirm the fix, read on for the instructions.

Read the rest of this entry »

Change Moom’s keyboard/grid bezel timeout delay

October 30th, 2014 by Rob Griffiths

One of Moom’s tricks is the ability to move and zoom windows via an onscreen bezel—this feature is enabled in Moom’s Keyboard preferences; assign a hot key to display the keyboard controller, and optionally show a cheat sheet (to help remember the commands you’ve assigned). You can also optionally repeat the same keystroke to have Moom display an onscreen grid.

As an example, here’s the onscreen grid with cheat sheet:

Moom's onscreen grid

Moom’s onscreen bezels automatically disappear after either three seconds (no cheat sheet visible) or nine seconds (cheat sheet visible)—either after taking an action (if you haven’t marked any of the “auto-dismiss” boxes in the Keyboard section of Moom’s prefs) or after doing nothing.

If you’d like to change this, you can. Open Terminal—in Applications > Utilities—then paste the following into Terminal. (Note that if you’re on OS X 10.8 or earlier, you need to quit Moom first.)

defaults write com.manytricks.Moom "Auto-Deactivate Interval" -float 1.0

The 1.0 is the default timeout in seconds; replace that with whatever time interval you’d like to use, then press Return. You won’t see any output, but relaunch Moom, and the bezels should follow your chosen auto-dismiss interval. If you ever want to reverse this, quit Moom, paste the following in Terminal, and press Return:

defaults delete com.manytricks.Moom "Auto-Deactivate Interval"

Moom should now be back to its default timeout settings.