All posts in the ‘Behind the Scenes’ category

Subscribe to the RSS feed for the 'Behind the Scenes' category

How Apple’s security system broke some Mac apps

Thursday, February 23rd, 2017

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.

App Store reviews: Of one-way streets and sidewalks

Wednesday, May 11th, 2011

Yesterday, I had an interesting (to me, that is) discussion about App Store reviews with Smile Software‘s Jean MacDonald (@macgenie) and Unmarked Software‘s Mark Munz (@mmunz) on Twitter (I’m @petermaurer, of course). It started with me trying to reach a user who had left an App Store review, including a suggestion that prompted me to believe he’d be interested in testing a beta build I had just completed.

So I took to Twitter, mentioned the name he had given in the review, and asked him to contact us. No result, as usual. From there, the following conversation unfolded…

petermaurer I really don’t like the App Store’s review system, because its one-way-ness keeps us from supporting users as thoroughly as we’d like to.
macgenie It’s a system in dire need of a makeover, for sure. It makes me crazy to read the reviews and not be able to do anything.
petermaurer And the occasional unjustified rating isn’t even the problem—seeing users seek support and not being able to contact them is. In other words, Apple doesn’t want us to reply in public—fine. I’d gladly settle for forwarding private messages to customers.
mmunz Although to be fair, there is a big link on the upper right of MAS page that says “Product Name” Support.
petermaurer Hehe, it’s a meta support problem that mirrors a typical non-meta problem: users don’t always do things the way they’re supposed to.
mmunz True – Seems like a discovery issue. Perhaps providing a second link at the top of the reviews section might help discovery.
macgenie I think the general low level of discourse in the comments discourages people who would otherwise write thoughtful reviews.
petermaurer OTOH, as a customer, I like the “reviews only, no drama” simplictiy of the current system. (Expansion arrows for replies, maybe?)
mmunz I think providing a way to send a private message to the reviewer or providing developer comments would really help.
macgenie With an opt-in checkbox. “Would you like a response from the developer whose life work you’re trashing?”
mmunz I think I need to put that checkbox on my support request forms. :)
petermaurer Hehe. The trashing doesn’t really bother me. We often get over-the-top praise, so unreasonable critique seems fair… I mean, for every user who alleges you’re the best developer EVER, there should be one who swears you’re the devil.
macgenie No, I think it’s not 1:1. If it is, then I’m very depressed. I think it’s more like 20:1.
mmunz Agreed, it would be very depressing if it were 1:1.

I’ve edited this ever so slightly for brevity and clarity, and to get rid of @mention prefixes that aren’t really necessary in this synopsis. If you’d rather read the original conversation, start with this tweet.

Now, everyone’s expectations for the best ever to devil ratio, which is obviously different from the 5 stars to 1 star ratio, will differ. But the gripe a lot of App Store publishers share is that there’s no way to contact people who offered their opinion via a review — not even the well-meaning ones.

The Problem

Here’s a typical example: You get a review stating that your app is nice and useful, but that it has one or two issues the user would really like addressed. Such a review is typically accompanied by a rating somewhere between 3 and 5 stars, but that’s not important for the topic at hand — we’ve even received 1-star reviews in the past, which were still sensible, and which were sometimes updated with a more favorable rating later.

But there’s that issue the user mentions, be it a suggestion or a question, and you’d like to respond to that. You’d like to excel at what you consider one of your strengths as a small indie developer: building a relationship with your customers. You’d like to say “We can’t do that, because…” or “That’s a great idea! Please try the beta build you can download at…” or even “You can already do that, and here’s how…”, but there’s no reliable way to get in touch as of now. Sure, there are workarounds of sorts — some developers have tried replying to those questions within the app description, and we’ve actually created “Conversations” pages for our App Store products, as described in an earlier blog post. (These conversations have since moved to separate pages that are accessible from the respective App Store product pages via the standard “[Product] support” links, right above the “Information” box.)

Trouble is: I’d be surprised if as many as 10% of the users who wrote a review for one of our apps ever clicked that link. In fact, I don’t think we’ve ever received follow-up feedback for these pages. So we feel like being in a phone conversation where only one person can hear what the other is saying.

A Solution?

The ideal review system, speaking as a publisher, would be more like a discussion board. Each review would be a thread, where the developer, the original reviewer, and maybe even other users could chime in.

Speaking as an App Store customer, however, I’m not sure whether I’d find that useful. The best thing about user reviews is that they’re spontaneous — they often are a vivid representation of what users thought (and sometimes even felt) when they first started using the app in question. And if I’m in the middle of considering an app purchase, that’s what I’m most interested in. I know pretty much every issue can be explained away somehow, and I know there sometimes are misunderstandings that turn out to be resolved easily. Nevertheless, the first impression is what makes or breaks an app, and that’s what those undiluted reviews are good at conveying.

So I can see why Apple made this a one-way street, and I’m humble enough to recognize that the people who work at Apple usually think long and hard about what they do. I bet they had additional reasons I haven’t even thought of yet. But this is one of those rare occasions where I do think Apple could improve communication between users and developers/publishers without diluting the abovementioned undiluted reviews too much. There are a couple of ways to do that, and we’ve already touched upon some of them in the Twitter conversation summarized above — pick one:

  • Turn reviews into threads, but make iTunes and the Mac App Store only display the original review initially, along with a button or expansion arrow. Users who are interested in all the details and drama can click that to make the entire thread display. (This would also be nice for tracking updated reviews.)
  • Let us contact our customers in private. Some people, including certain high-profile bloggers and/or journalists, will make the point that we shouldn’t have the customer’s e-mail address, lest we sell those addresses or do other evil things with them, because we’re the devil, remember? But that’s not even necessary: Apple does have the customer’s address, so they could forward messages we enter in a form, for instance.
  • For all I care, Apple could even try and turn Ping into something useful by using it for customer-developer communications. Let us “ping” our customers. From there, the customers can ignore or block us if they want, just like the other two methods should have opt-out or even be opt-in in the first place.

Please note that I’m not asking for an additional way to contest ratings or make unfavorable reviews go away — every customer’s voice should be heard, even if a given customer does believe Many Tricks is run by the devil or simply enjoys being a jerk. Ratings might not be as important with regard to sales as some developers think anyway — after all, there are lots of apps with abysmal ratings that still manage to be top sellers in their respective categories.

And again, I understand that one-way streets have a purpose, namely preventing the head-on crashes that are endless customer vs. developer feuds, as well as minimizing the number of rubbernecks chiming in and thus clogging the system.

But please, Apple, consider giving us a nice and quiet sidewalk where we can step up to those customers who seem willing to talk to us, without affecting the bulk of the review traffic too much. I do believe that would be a win/win/win scenario.

A short year, indeed

Tuesday, March 22nd, 2011

On this day in history, one short year ago, Many Tricks re-opened for business with Rob firmly in control of public relations and the business side of things. Rob already looked back at his first year as an indie software guy recently, and since he usually does things very thoroughly, there’s not a lot I can add to that. That’s a good thing, too, since I’ve been having slight difficulties with typing recently. So I have two excuses to keep this short, but I still want to make a couple of remarks.

Work has never been more fun, and it’s never been more economically sound than during this past year. Although Rob’s and my discussions about both important decisions as well as negligible matters of taste can be exhausting, there hasn’t been a single instance when I wasn’t convinced that the energy spent there would ultimately yield a better result. It’s downright comical how different we are in almost every aspect of daily computer usage, but this helps us keep an open mind and come up with solutions that work not just for us, but for lots of users as well.

Speaking of users, what more could we hope for than customers who consider our support life-affirming? If anyone benefits more from Rob’s work than I do, it’s you, the customers. And you seem to be very aware of it, judging from the amount of positive feedback I see in the occasional support ticket I read.

So in case any fellow indie developers read this, here’s my advice: If you haven’t done so already, find yourself a Rob. (No, you can’t have mine.) Even though you won’t be able to act quite as spontaneously as you did before, you’ll find that you’ll actually feel more independent. Your customers will be happier. You’ll be able to move faster when confronted with somewhat unexpected events like this year’s pre-Lion Mac App Store opening. You’ll be more efficient, because you can concentrate on things you’re good at. And just in case you like money, you’ll make more of that, too.

Anyway, it’s been a great year. Rob already said so in the anniversary blog post I linked to above, but it bears repeating: Thank you everyone! And thank you Rob, for making a career choice that must have seemed incredibly risky to a family man. As far as I’m concerned, I’ve never felt better about being an indie developer than I do these days, and I can’t wait to see where we go from here.

Happy Anniversary to me!

Tuesday, March 1st, 2011

One year ago today, I started working at Many Tricks. It’s astounding to think a year’s gone by already, as it seems like it was just a few weeks ago that Peter and I were working on getting the web and support sites up and running. But the reality is quite different, and time has been flying due to everything we’ve done in the last year:

  • Relaunched the main site.
  • Added a new support site.
  • Released one entirely new product (Time Sink).
  • Released major updates to four products (Desktop Curtain, Leech, Usher, Witch).
  • Released 47 minor updates across all our apps.
  • Rewrote help in all apps (except Butler, which will happen with Butler 5).
  • Created video walkthroughs for many of our apps, with more in the works.
  • Posted 70 items to our blog.
  • Managed to get six programs in the Mac App Store, with a seventh (a totally new app) pending.
  • Sent 5,057 emails

So much for the numbers…what this post is really about is what the last year has been like for me, personally.

The move from full-time Macworld scribe to member of a two-person company has been eye-opening, to say the least. Not having a corporate paycheck for the first time in my life is scary, but also liberating: Peter and I make decisions based on feedback from customers, and what we want to do, and that’s it.

Not having any sort of set work hours is also very liberating—I was able to take a 30-day trip with the family this summer, and yet not miss any work, thanks to a laptop, internet connectivity, and the ability to do my job whenever and wherever I happened to be.

Another thing I’ve really enjoyed over the last year is the ability to make things happen right away—whether that thing is a bug fix, feature addition, or sometimes even a brand new product. Once we’ve decided we want to do something, it’s not very long at all before the results of that decision are available on our site.

I’ve also enjoyed working with Peter on all aspects of the business. We clearly have a different “eye” for many things, which leads to a lot of back-and-forth as we discuss features, layouts, and color schemes…but those conversations are always productive, and the end result (we think, at least) is something that both of us are proud of, and that hopefully meets the needs of our customers.

Ah yes, the customers…the most important part of the last year of my life. When I decided to join Many Tricks, neither Peter nor I were sure what to expect. The company had been dormant for over 12 months at that point, with no blog posts or product updates during that time. We actually discussed dropping the Many Tricks name entirely, but both of us felt it was worth trying to bring it back to life.

To do that, we had to reestablish trust with our customers and prospects: we needed people to know we were back, we were here to stay, and we would support what we sold. Everything we’ve done over the last year has been in support of those objectives, from creating the support site to posting answers to comments on MacUpdate to responding to every email and trouble ticket in a timely manner.

Now, one year into the effort, things are going well. The Many Tricks name is back, and customers have returned. We still have a ways to go to re-earn everyone’s trust, and I’m sure there are customers who will never forgive the one-year hiatus (which is completely understandable). I can promise, though, that going forward, we’re not going to vanish again (this is my livelihood now!), and that providing excellent customer support is our number one objective.

So a big Thank You to everyone who supported us during our first year “back in business;” without your support for our products (and belief in us!), Many Tricks wouldn’t have survived, and I wouldn’t have made it to this first anniversary.

So now, on to year two…and it’s a big year, as we’ve got major updates planned for many of our programs. This is also the year of the Lion, and we’ll be updating our programs to work well with the latest operating system out of Cupertino. If year two is anywhere near as fun and exciting as year one was, I will be completely thrilled.

-rob.

A Butler named Alfred

Friday, September 24th, 2010

Preface: The following is not strictly company or product news. So if you’re the kind of visitor who feels his time is wasted whenever we show up in your RSS reader without providing cold, hard info, please feel free to skip this rather lengthy blog entry.


There’s a new kid in town, as the Eagles once put it so aptly. A new Mac {hot key/web search/iTunes control/what have you} utility that attempts to make a Mac user’s life easier and more productive. The name is Alfred, and from what I see on its product page, it seems to be a well-designed application.

And in a lot of ways, it’s, shall we say, a tribute to Butler—even more so than You Control, for instance, ever was. Now, I’m not complaining about that. On the contrary, I feel honored, and I can see why a Butler-related theme is a somewhat obvious choice for that kind of application. I wouldn’t even be surprised if the lack of significant Butler updates over the last few years were part of the motivation that brought the aforementioned new kid to fruition, much like a temporary lack of updates for Riccardo Ettore’s otherwise excellent TypeIt4Me was one of the key reasons for me to create Textpander (which, of course, is known as Smile Software’s TextExpander these days).

So despite what people might think, I have no issue whatsoever with their decision to create an application that shares a lot of its functionality with Butler, and outfit that with a name and an icon that remind me of Butler as well. If anything, I consider this new competitor a wake-up call. Yes, it’s high time for Butler to evolve. And trust me, we love the honorable sportsmanship that’s customary in the Mac software world.

But there’s one thing that got to me, and that’s the one thing they couldn’t possibly have been aware of.

The name.

Let me tell you about a man named Alfred Ruck. He was an entrepreneur, he was a free spirit, he was a war hero (and that’s despite the fact that he was a German army officer in World War II), and he was my mom’s oldest brother. He also was a kind of dad to her, because she never knew her father, who had died young. And for us kids, he filled the role that’s occupied by a grandfather in most families. Looking back, and comparing what he did decades ago to what Rob and I try to do now, he’s also been a role model for me.

So I guess it goes without saying that his passing away a few years ago left a hole in the lives of those who knew and loved him, including myself. But even as he went to join his beloved wife, who had died years earlier, he left me something that constitutes a direct connection to Many Tricks—money, plain and simple.

You see, there’s a reason why Many Tricks went offline last winter and generally ceased to exist for a while. I had worked a lot over the years, I felt like I hadn’t always made the best business decisions. Simply put, I was severely burned out. So I needed a break from everything that was even remotely related to the software business, and in typical fashion for this condition, I didn’t even have energy left to let people know I needed that break. Instead, I just vanished to think about what I wanted to do from there on out.

The vanishing obviously confused a lot of people, angered some, but the break was still undoubtedly necessary. It gave me time to develop a new vision both for myself and Many Tricks, and it was during that time that I realized that Rob’s coming on board was paramount for the future of Many Tricks—the future of my “babies”, if you will. There were things I didn’t want to do anymore, there were things I just didn’t know how to do, and what’s more, there was just too much to do for days that could never be coaxed into having more than 24 hours. If I was to continue development work, someone else would have to run the business. It was very obvious to me that I absolutely had to convince Rob to join Many Tricks after years of half-joking about it, because I felt like I knew him well enough, I trusted him more than anyone else in this industry, and I knew we shared the same ideals when it came to software. If you’ve visited this site before, you’re probably well aware of the happy ending that story had.

But it still took me half a year to sort these things out, and if you’re self-employed, it’s far from trivial to just drop out for that amount of time. There were bills to pay, after all, and this was where uncle Alfred’s legacy came into play. He was a clever businessman, he invested wisely, so when he died, he left a surprisingly sizable fortune for his surviving siblings, nieces, and nephews. And my 1/16th share of that legacy helped keep me afloat both while taking that break I so sorely needed and while patching things back up thereafter.

It’s fair to say that Many Tricks might not exist anymore without his posthumous help. And that’s why I started to refer to my most precious creation, the little Butler, as “Alfred” in private a while ago. That was my way of commemorating the original Alfred, and thanking him. Prior to today, I never even considered making that public, but now that the new kid is around, I feel like my hand is being forced. If I ever want to tell this story, it’s now or never, because the longer I wait, the more the name Alfred might be affixed to something else, and the more it would seem like I was trying to steal someone else’s thunder.

So there you have it. There are not only two Butlers now, there are actually two Alfreds. Welcome to the club, Alfred.

And most importantly, thank you, Alfred.

Behind the scenes at Many Tricks, Part 2

Thursday, July 1st, 2010

Welcome back to the second part of our behind-the-scenes look at the tools of Many Tricks’ trade. In the first part, we discussed how we create our applications and manage our online activities. In this part, we’ll discuss how we keep the business running and some general Mac applications we use every day.

Running the business

  • iChat (free with Mac OS X): We rely on iChat extensively. Most of our written communication is via iChat (so we both have transcripts enabled, to record what we type), and we use screen sharing (to work through the product design and implementation process) and video chat (so we can occasionally speak instead of type). Without iChat or something like it, our time and distance separation would make running the business much tougher.
  • Dropbox (free): With the distance between us, we needed some easy way to move files back and forth. Dropbox fits the bill perfectly, and makes it super easy for us to share our files back and forth—any changes made to the shared folder are automatically duplicated to all our Macs. It doesn’t get much easier than that. We wonder how they can afford to make it a free service, though.
  • The Hit List ($50): We use The Hit List (THL) to track all of our to dos for current and future apps, and for the business itself. While THL isn’t a true multi-user app, we’ve sort of solved that by using Dropbox: we moved the THL support files into a folder on Dropbox, and now we can both see and work with the same set of data—just not at the same time. So far, this has worked really well. We like THL’s elegant interface, and its support for tagging lets us manage a number of complex mini-projects with ease.
  • E-junkie ($ varies): The provider of our online shopping cart. While Rob thinks they have a less-than-ideal name (Peter of course finds that name hilarious, but then, he also thought “Textpander” was funny), they provide a great service, and their system is very flexible and easy to work with.
  • PayPal and Google Checkout (% commission): These two companies handle payment processing (i.e. credit card approvals) after a user places an order with the E-junkie online store. Most of our customers (over 80%) use PayPal, and it seems they process orders more quickly than does Google Checkout.

From Rob’s point of view:

  • FileMaker Pro 11 ($ varies): One of the issues I faced when joining Many Tricks was incomplete historical customer data. To make sure we better tracked our sales activity going forward, I created a FileMaker Pro customer database. I hadn’t used FileMaker extensively in nearly a decade, but my basic skills came back pretty easily. The database is manually updated (via an automated script) with data I download from E-junkie. (This database does not contain credit card information; it stores only the basic data you provide when purchasing an app. It also resides solely on my machine, and is not stored online anywhere, including Dropbox.)
  • Microsoft Excel 2008 ($ varies): To keep Peter in the loop about our sales activities, we have an online sales report that summarizes activity by day, by product, and by payment processor, and graphs sales activity in each of our main products. This report is created automatically by Excel, using a script in FileMaker Pro that exports the data, then opens and updates the relevant Excel spreadsheets. When the script tells Excel to save the sheets, a setting in Excel also updates the local web page versions of those sheets. (No, we’re not giving you a link for this one.)
  • AppleScript, Folder Actions, and shell scripting: The combination of these tools is used to automatically update the online sales report. A Folder Action watches the folder where I save the sales reports, and runs an AppleScript when it sees a newly-added file. The AppleScript uses a shell script (which, in turn, uses scp) to upload the sales report pages to our web site. When done, the AppleScript deletes the files in the folder, so that it’s ready for the next save. (Folder Actions can’t watch for changes to existing files in a folder, just files being added to a folder. So I keep the folder empty until a new report is ready.)
  • rsync (free with Mac OS X): We use rysnc to back up our online presence. Using rsync and a cron task, our web files (HTML, PHP, etc.) and SQL databases are backed up to my machine three times a day. From there, Time Machine backs them up onto another drive, and they’re copied to a FireWire drive for offsite storage once a week. I feel pretty confident that if we ever suffer a catastrophic hosting failure, we’ll be able to get back up and running quickly with minimal data loss.

General Mac tools

  • TextExpander ($35): We use TextExpander to auto-expand various snippets of text, including stock replies to certain email inquiries and inserting HTML snippets in our web files. If you do much writing at all, a text expansion tool is highly recommended. If you need help choosing one, some guy named Rob Griffiths, who used to write for Macworld, recently reviewed and compared four such apps. (Peter is somewhat emotionally attached to TextExpander, so it should be obvious what his favorite among these is.)
  • TextWrangler (free): When either of us is not working on something in Coda, and we just want to edit some text, we’ll usually fire up TextWrangler. Rob’s text processing needs are relatively simple now, and Peter’s text processing needs have always been that way, so TextWrangler supports everything we need out of a text editor.

From Rob’s point of view:

  • Data Backup ($59) and Time Machine (free with Mac OS X): I use Data Backup to run the weekly backups to my offsite FireWire drive (it comes home once a week for copying), and use Time Machine for near-real-time backups of Many Tricks’ data.
  • Growl (donations welcome): While we include Growl support in some of our apps, I also personally use Growl to notify me of activities in key capps. Transmit, Coda, Dropbox, and iChat (via the Chax plug-in), for instance, all support Growl. So when Peter updates the files in our Dropbox folder, my Growl alert pops up and lets me know there are new files there. Growl is so good I keep expecting Apple to bundle something like it directly with the OS.

From Peter’s point of view:

  • Finder (free with Mac OS X): Every Mac user is a Finder user, too, of course (except for the Path Finder orthodox, that is), so why am I mentioning the Finder explicitly? I’m using the Finder for a host of things Rob tends to do in a more automated fashion. For instance, I currently do most of my backups manually, because even after years of testing, I just haven’t ever been able to find a backup solution that felt as reliable as copying something by hand. See next paragraph for the exception that proves the rule.
  • SuperDuper! ($27.95): This little utility is incredibly useful for backing up entire drives. It’s a pity it doesn’t do folder-to-folder synchronizing, too.

Beyond the tools we’ve listed here, there are many other programs (screenshot tools, screen movie tools, image creation and editing tools, etc.) we use, but the ones we’ve chosen to list here are the biggies. We hope you enjoyed this behind-the-scenes tour, and maybe you found an app or two that might fit your needs, too.

Behind the scenes at Many Tricks, Part 1

Wednesday, June 30th, 2010

By most any measure, Many Tricks is not a big company—there are only two of us, and we’ve only got a handful of products. Complicating this relatively-simple small business, though, is the fact that we are separated by 5,327 miles (according to Google Earth), and nine clock hours.

Given our small size and geographic separation, we need to work efficiently individually, and doubly so during those few hours each day when our schedules overlap (typically from about 5:00am to 12:00pm, west coast USA time). So what tools do we use to keep in touch, to manage our web site, and to run the business? Keep reading for a behind-the-scenes look at the apps that keep Many Tricks humming.

As this post turned out much longer than either of us expected, we’ve broken it into two parts. This first part covers the tools we use to create our apps and handle our online activities; the second part will discuss running the business side of the company and general Mac tools that aren’t directly related to any of the prior categories.


Here’s a look at the key programs we use to create our apps and manage our online presence. (Note that we don’t include our own apps on these lists, but both of us use them extensively, as you might guess.)

Creating our applications

From Peter’s point of view:

  • Xcode (free): Write code, compile it, and tear your hair out because of errors you don’t understand—Xcode lets you do all of that, and it’s the development environment the vast majority of Mac/iPhone developers uses. I haven’t worked with any other IDE in years, so I don’t really know how it stacks up against other contemporary environments, but one thing I can say is that I really, honestly like Xcode. It’s quite successful at making a developer’s life as easy as possible, and Apple has improved Xcode steadily ever since Mac OS X saw the light of day. In my opinion, Xcode is an archetypical example of what’s great about Apple.
  • Canvas (discontinued for Mac OS X): I try not to create icons anymore, because I’m just not that good at it, but whenever there’s an immediate need for doing vector graphics, I still fire up Canvas, which helped create the Butler and Name Mangler app icons, among others, in the past. This is the only major graphics application I ever really learnt to use, so it’s a pity they don’t make it for the Mac anymore. Like so many successful pieces of software, Canvas was first created for the Mac, and I remember the times when most of the Mac users I knew worked with Canvas on a daily basis. Eventually, though, Canvas’ original maker, Deneba, was acquired by ACD systems, and those guys just didn’t like the Mac that much, I guess. So I’ll have to switch to another app one day, but for now, I’m just glad Canvas X still runs on Mac OS X 10.6.
  • GraphicConverter ($34.95): GraphicConverter is the swiss army knife of editing and converting image files on the Mac. It was the first Mac shareware app I became aware of when I started working on a Mac regularly during the Mac OS 8 days, and to this day, I find myself using it all the time, be it for quickly optimizing a scaled-down version of an icon, converting a PNG to a favicon, or any other of those minor graphics tasks one faces every day.
  • DropDMG ($24) and DMGCanvas ($15): Both of these let you create those spiffy DMG disk image files that are the quasi-standard for distributing Mac software these days. Conceptually, they are quite different, and I’m an avid user of both of them, enjoying the fact that I have tailor-made tools for different tasks—such as packaging software for release (DMGCanvas) and archiving stuff (DropDMG)—at my disposal.
  • Time (invaluable): While a solid Mac computer (or several of those, to be on the safe side) and some pieces of software are indispensable for developing, you’ll find that developers often just sit there, seemingly doing nothing while thinking about possible solutions to a problem, and possibly getting a little philosophical about it. So yes, state-of-the-art equipment is very important, but so is taking the time to come up with solutions you feel confident in.

Online activities

  • Coda ($99): The Many Tricks web site is implemented on top of a very basic homebrewn content management system written in PHP, and it’s primarily coded and managed with Coda these days, after having been a Finder plus TextWrangler (see General Mac tools) plus Cyberduck (see below) project for years. We particularly like Coda’s ability to edit files on the server, its live previews, and the tabbed editing interface. Rob also uses Coda to create and edit all the help files for our apps.
  • Safari and Firefox (both free): Peter prefers Safari, and Rob prefers Firefox, which is a pretty good combination—because we use the two dominant browsers on the Mac, we both work hard to make sure our web site works well in both of them. (We also test our site in the other major browsers, to make sure there aren’t any major issues.)

From Rob’s point of view:

  • Trellis (free): Our support site, where you can submit requests for help, ask for new features, and browse our knowledge base, is powered by Trellis. While it’s not quite the perfect system (email submission/management of tickets would be great, and Peter is pretty much incompatible with its message editor) for our needs, it does about 80% of what I’d like it to do, and seems to be working relatively well.
  • Transmit ($34): Sometimes I just need to get a bunch of files on the server. For those times, Transmit is my tool of choice. (For now, I’m sticking with Transmit 3.x, as I really dislike the interface in 4.x.)
  • WordPress (free): Our blog is powered by WordPress, and I can’t say enough good things about it—from extensions to the most brain-dead-simple updates I’ve ever seen in a web app, WordPress makes it super easy to create and maintain a blog.

From Peter’s point of view:

  • Cyberduck (donations welcome): Transferring files to and from our server after having edited them offline used to be Cyberduck’s job, and it did it both reliably and with a sense of user interface style that was unmatched by any other Mac FTP client for years. We don’t currently use Cyberduck for the reasons outlined above, but it is undoubtedly an important part of Many Tricks’ history.

Stay tuned for Part 2 tomorrow…