All posts in the ‘Developer’ category

Subscribe to the RSS feed for the 'Developer' 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.

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.

Displaperture 1.2 supports multiple displays

Friday, August 20th, 2010

Today we released Displaperture 1.2, our free utility to round the corners of your screen. New in this version is support for multi-monitor Macs—you can choose to round the corners on all attached displays, or (the default) just the one with the menu bar. Displaperture now works with Exposé, too, so you won’t lose your nice rounded corners when you activate Exposé.

Finally, for you developers out there, Displaperture is now open source—you can download the source code, and use it as you wish.

MUM’s the word…

Monday, August 16th, 2010

…well, it’s actually an acronym, not a word—it’s Minor Update Monday, and here’s what’s on the plate for today’s minor updates. (As usual, you can get the updated version directly from the app, or by downloading the new version from the product page.)

  • Witch 3.5.3 fixes an issue with displaying triggers that had been assigned in the Additional Actions section of the Triggers tab. In prior versions of Witch, the keys were set, but Witch wouldn’t properly show those values on the Triggers tab. Now it does. Also, for those who use Witch with the ‘Releasing all modifier keys activates the selected window’ option unchecked, Witch now properly respects the delay setting, and won’t show its window if you release the activation keys before the delay time is reached.
  • Leech 2.0.5 adds one new feature, a timestamp indicating at what time a file finished downloading.
  • Name Mangler 2.2.2 now allows renaming of aliases, fixes a bug relating to non-ASCII characters in regular expressions and Advanced Mode, allows you to copy-and-paste files, URLs, and paths to the file list area, and allows dragging-and-dropping of URLs and paths to the file list area (file drag-and-drop was already supported).
  • We’ve got some news about Key Codes, our free tool for Mac developers that displays the key code, Unicode value, and modifier key state for any combination of keys that you press. The news? Key Codes is now open source, so you can download the source to see how it works. We haven’t published this under any official open source license, but feel free to use it in any project you wish as you see fit. It’d be nice if we received an acknowledgment, but it’s neither required nor expected. (Key Codes also received a very minor update to version 1.0.4.)
  • Finally, not related to any of our programs, but if you’re reading this entry on our blog (instead of via RSS), you may notice we have a new handwritten blog header, complete with a bird-like interpretation of our company logo. Peter did the work, and I think the end result is terrific—it adds some color and personalizes the blog section of our site just a bit. But why a running bird? As Peter noted in a comment to another post here, “The Running Bird is really just one of the less obvious motifs I saw in our new logo once we were finished with it. That’s one of the things I like about that logo, by the way: With a little bit of imagination, it can be a lot of things—it’s a Many Tricks logo, as it were.”

In bigger-project news, Usher is approaching a public beta release, and Peter and I are starting to work on an entirely new application, one that I think will be useful to anyone who uses more than one Mac at home or work…but more on that project once we have something worth talking about!

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…

The future looks all Sparkle-y

Wednesday, March 24th, 2010

As I noted in the Name Mangler 2.1 announcement, all future Many Tricks products will include support for in-app updates via Sparkle.

If you’re not aware of Sparkle, the reality is you’re probably aware of Sparkle. If you’ve ever run an app that let you download and install an update directly within the app, chances are good it’s using Sparkle to do that behind-the-scenes magic.

This amazing tool is open source, and supported by donations—and we’ll be doing some stuff in the future to support the project, as we think it’s a great addition to our code base.

Because you do lose some control over your machine in Sparkle-enabled apps (when they automatically download an update you didn’t ask for), all of our apps will include a simple on/off toggle for automatic update checking. If you’d rather check manually, just turn off the automatic updates. Personally, though, I leave Sparkle enabled in all the apps I use that include it; it makes product updates incredibly simple.

I’m thrilled we’re taking this step, as it simplifies what was a too-complex task for our programs—clicking a couple of buttons beats going to your browser, downloading and expanding an archive, quitting the original program, finding the original and new versions on your disk, and replacing old with new. Instead, Sparkle does all the heavy lifting ; you just click a couple of buttons and your app is up to date.

So thanks, Sparkle, for making our users’ lives simpler!

Use CoverFlow in 10.5 while supporting 10.4

Thursday, March 20th, 2008

When implementing coverflow in yFlicks, I was faced with a challenge that made my head ache for a while. I wanted this to be based on CoreAnimation, and I wanted yFlicks to still run on Mac OS X 10.4.

What I’ve eventually come up with is a plug-in bundle named PMFlowView, which is only loaded and used when yFlicks runs on Mac OS X 10.5. It communicates with the actual application by means of a protocol that will sound very familiar to anyone who’s ever used a NSTableView, and since it’s a stand-alone component, it can be used with virtually any application.

If this sounds appealing to you, have a look at PMFlowView’s essential header file; and if you’re interested in using PMFlowView in one of your own projects, feel free to contact us.

Key Codes 1.0.2

Monday, February 18th, 2008

We know most users weren’t exactly dying to get this update, but we’ve been asked for it, so here you go: Key Codes 1.0.2 is still a very, very basic key code explorer application that comes in handy when developing Mac OS X applications. The news is: It’s a universal binary now.

User Interface 101: Snap

Sunday, February 10th, 2008

A lot of applications have little overlay windows that control the application’s behavior when in fullscreen mode. Take, for instance, QuickTime Player’s fullscreen playback controls or the Finder’s slideshow controls. By default, they pop up at the lower center of your screen, but you can move them with your mouse.

The odd thing is: Once you’ve moved them (e.g., by accident), there’s virtually no way to re-center them. And you can move them off screen, at least partially. Sure, there are a lot of reasons that justify moving a standard window partially off screen, and I won’t even discuss them here, because I’m lazy. But I don’t think these reasons apply to little overlay windows with just a few controls — windows that are typically the only visible window of their kind, displayed in front of some kind of fullscreen content.

I may be more obsessive than most users in this respect, but if I want to center a window, I want it centered, not just approximately centered. So to me, it has always been obvious that said overlay windows should snap to the screen’s center (or at least the center of the screen’s abscissa) when moved near there. And it’s equally obvious that they should snap to the screen’s edges. If you do it that way, there’s an additonal benefit: Most of these overlay windows have rounded corners; and if you snap them to the screen edges (or corners, for that matter), you can adjust the window’s corners according to the window’s position, because a rounded lower right window corner doesn’t make much sense if it’s snug against the screen’s lower right corner.

That’s how yFlicks behaves. And Butler‘s little status window — the one you see when pressing a hot key, for instance — has been snapping to certain screen positions for years as well. But the thought that I may be overlooking the elephant in the room keeps haunting me, because I can’t find the answer to one simple question:

Why doesn’t Apple do it?