Please Also Change Your Feed URL's Inside Your Apps

In my post about redirecting the DevMate update feed, I missed the opportunity to mention that you should probably also update your app very soon to not rely on DevMate's framework.

Mr Boy van Amstel at Danger Cove picked up the topic and explains how you can change your feed URL inside the app using the Sparkle SUUpdaterDelegate methods. DevMate's closed-source framework wraps this in its DM_SUUpdaterDelegate_DevMateInteraction protocol.

Your battle plan thus should be:

  1. Redirect the remote feed URL to deploy updates to existing customers working with old versions, and
  2. Change the feed URL used inside the app as soon as possible and deploy an update to not rely on the redirect for too long.

I use the SUUpdaterDelegate to switch feed URL's in The Archive and WordCounter, too, in case you wonder if this is a good idea in the first place.

See also:

How Do You Activate Sparkle's XPC Services?

The Sparkle XPC fork is even better than I would've imagined! As I mentioned in the previous post about Sparkle's XPC branch, you can switch to the new framework version and the new types without having to change much else. The new API is very similar to the old one. If you switch to the work-in-progress ui-separation-and-xpc branch, then you can continue to use CocoaPods or Carthage if all you want is the new API.

Continue reading …

How to Migrate to the New Sparkle Updater XPC Branch

This is the first post in a series: The standard solution to provide app updates outside the Mac App Store is to use the amazing Sparkle framework. The releases of Sparkle don't support sandboxed applications well, though, so the core maintainer Kornel Lesiński (@kornelski) is working on a more secure fork of Sparkle next to the existing one. He's maintaining the regular Sparkle, and the fork. The fork features various XPC services to deal with Gatekeeper security configurations and Sandbox entitlements in a proper way. (I have to phrase it in such a vague way because I have no clue about the details, yet. Explanations are very welcome in the comments!)

Continue reading …

Use Shared NSUserDefaults for XPC and Interface Builder Nibs

The default Interface Builder approach of using a "Shared User Defaults Controller" object breaks down if your app preferences are not stored in the standard place. Both my apps The Archive and the Word Counter for Mac are comprised of multiple executable applications. For The Archive, it's the main app and the Quick Entry popup window. They share some settings, like which theme and font size is used. To share these settings, I rely on NSUserDefault (or just UserDefaults in Swift now). I cannot use the UserDefaults.standard, though, because that is tied to the currently running app's bundle ID. In the case of the main app, it's the ID of the main app; but for the Quick Entry helper – or any helper app –, it's the helper's bundle ID. This way, the defaults dictionaries are not shared.

Continue reading …

Don't Build on El Capitan Without Checking App Transport Security

I got burned this week. Pretty bad. I shipped a small bugfix release for my Mac app Word Counter a couple of days ago to prepare for the "big one" coming this week. Naturally, I built that version on my El Capitan dev machine. I pushed the update to my server. Updates using Sparkle worked. – But now users of that version cannot ever update to the next version. Because I haven't thought about ATS.

Continue reading …