Articles index

App Translocation and Safari App Extensions

May 21, 2018

By Jeff Johnson

First, the good news: my Safari app extension StopTheMadness is now compatible with macOS 10.12 Sierra!

With that taken care of, I'll spend the rest of this blog post telling the story of why my extension didn't originally ship with Sierra support. The story begins two years ago, when Apple introduced Sierra at WWDC. Sierra added a new security feature officially named Gatekeeper Path Randomization, though it's also become known as App Translocation from the (non-random) name of the file path under which apps are run. The feature was carried over to High Sierra, and we'll find out in two weeks whether it still remains in … Higher Sierra? App Translocation has caused a number of problems for apps, most notably with software updates.

For the past year or so I've been shipping apps mainly on the App Store, so during that time I haven't had to deal personally as a developer with App Translocation. It only affects apps that you download directly from third party developers. When you launch an app downloaded with a web browser, the macOS Gatekeeper technology is triggered. Under certain circumstances — for example, if you unzip an app and launch it from your Downloads folder — the app is subject to Gatekeeper Path Randomization.

For App Store developers, testing our apps can be a big hassle. The iOS App Store has TestFlight, which allows you to distribute your app for testing both to internal team members and to external beta testers. Unfortunately, the Mac App Store doesn't have TestFlight. (Yet. Perhaps in two weeks???) The best alternative is usually to codesign your app with a Developer ID certificate, as if you were distributing outside the Mac App Store, and then send the app directly to testers. I just zip up my apps, because compressing files is trivial in Finder.

When I was testing StopTheMadness before App Store release, that's what I did: signed with Developer ID and posted a .zip file for download. On High Sierra, everything worked fine. On Sierra, however, I was seeing problems. Safari app extensions use Apple's SafariServices framework, and when my app called SafariServices API, it got mysterious "no extension found" errors. I found a post on the Apple Developer Forums from another developer experiencing the same problems on Sierra, but there was no solution. Then I submitted an Apple Developer Technical Support Incident. They told me they believed the issue is a bug. And of course, file a Radar. Facing the unpleasant prospect of trying to work around a system bug on Sierra, I decided to just require High Sierra for StopTheMadness version 1.0.

I took another look at Sierra the other day, because I received some email requests for Sierra support. I wondered whether the "no extension found" errors meant that the system was only looking in certain locations for the extension, so in testing I made sure to put the app in the Applications folder, where the App Store would install it. Then, lo and behold, it worked! That's when I had the realization: when you move an app from Downloads to Applications in Finder, it turns off App Translocation. Could that be it? To check, in my next test I left the app in the Downloads folder, but I deleted the "com.apple.quarantine" extended attribute that indicates to Gatekeeper that the app was downloaded from the internet. Again, it worked! It appears that the "no extension found" errors occurred because the app was undergoing Gatekeeper Path Randomization. With that off, and no App Translocation, the SafariServices calls worked fine.

The kicker is that this App Translocation issue only occurred on Sierra. On High Sierra, the SafariServices API calls work even when the app is running from the Downloads folder and undergoing App Translocation. So it appears that SafariServices on Sierra was failing to account for App Translocation, and that bug was fixed in High Sierra. If this issue had occurred on High Sierra too, I probably would have figured it out before shipping StopTheMadness. But since running from Downloads worked on High Sierra, it didn't occur to me originally that it could have been an App Translocation problem. It just seemed to be a strange Sierra bug.

App Translocation is so messed up that not only does it mess up third party developers, it also messes up Apple's own engineers.

Articles index