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.


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.

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.

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?