Monthly Archives: July 2015

The Curious Case Of Xcode’s Commit Message

Debugging, Xcode

Xcode has a behavior with its source code integration, wherein the pending commit message is persisted so that if you cancel a commit, and then go back to commit again later, the text you already typed is preserved.

This is a nice feature.

However, my friend Seth Dillingham lamented on Twitter that for some reason the persisted commit text on his Mac was crashing Xcode. Yikes. No problem, he just needed to find the persisted text and delete it. It should be in some Xcode preferences file, or maybe in ~/Library/Developer, or somewhere else sane like that, right? Right?

Wrong. A little snooping on my part reveals that Xcode saves this bit of text in just about the least likely place I would expect…

Most people consider the OS X pasteboard pretty monolithic, especially since it’s so easy by default to obliterate the contents of the default pasteboard by e.g. copying new text to overwrite the old. But there are in fact multiple default pasteboards in OS X. For example there is a general pasteboard for typical copy and paste, but a different pasteboard for dragging content from one place to another. This is a good thing, because we wouldn’t want a drag to obliterate the copied text we were about to paste.

Have you ever noticed that on OS X, when you search for some text in one app, and then switch to another app to use its “Find” functionality, the same search text is already present in the search field? Thank, or blame, the system standard “Find” pasteboard, which makes this possible.

There are also an endless number of possible custom pasteboards, named by the creator and used for whatever purpose they see fit. Usually this is to accommodate the movement of data within an app in such a way that it doesn’t muck up the standard system pasteboards. But Xcode uses it for something more akin to the “Find” pasteboard described above. They declare and use a whole custom pasteboard to store … drum roll please … the commit message.

If you use Xcode for Source Control, select “Commit…”, type something into the commit message text area, then cancel the commit. Now, from the Terminal:

echo "from AppKit import NSPasteboard\nprint NSPasteboard.pasteboardWithName_(\"IDESourceControlCommitMessagePasteboard\").stringForType_(\"IDESourceControlCommitMessagePboardType\")" | /usr/bin/python

There’s your commit message!

Now, let’s suppose you have run into the same bad luck as Seth, and need to clear out that commit message text to prevent Xcode crashing? NSPasteboard’s “releaseGlobally” method should do the trick:

echo "from AppKit import NSPasteboard\nNSPasteboard.pasteboardWithName_(\"IDESourceControlCommitMessagePasteboard\").releaseGlobally()" | /usr/bin/python

Now you know possibly a bit more about NSPasteboard on the Mac and probably a lot more about how Xcode persists its commit message text. I know I sure do!

NSURLSession Authentication Challenge Disparity

Apple, Bug Reports

Thanks to a bunch of my networking-related unit tests failing on 10.11, I came to the conclusion that NSURLSession’s authentication challenge mechanism changed from 10.11 with respect to the way HTTP Basic Auth challenges are handled.

In 10.10 a data task that is created for a resource protected by HTTP Basic Auth will result in a callback whose protection space method is identified as “NSURLAuthenticationMethodDefault”, while in 10.11 the same code accessing the same resource yields a protection space method “NSURLAuthenticationMethodHTTPBasic”.

The problem here is that existing challenge-handling code may have been written to handle the 10.10 behavior, looking for HTTP Basic Auth challenges like this:

if ([[challenge protectionSpace] authenticationMethod] == NSURLAuthenticationMethodDefault)
{
	// Handle the challenge
	...
}

While on 10.11 the “Handle the challenge” code will never be reached, so this shipping code will fail to function.

I think a robust workaround (that unfortunately requires re-compiling and re-shipping) is to test HTTP authentication challenges for either NSURLAuthenticationMethodDefault or NSURLAuthenticationMethodHTTPBasic, and treat them both as equivalent.

I filed this as Radar #21918904, and wrote a message in the developer forums in case people want to discuss the issue or the merits of various workarounds.

Swift Libraries Code Signing

Bug Reports, Xcode

I wrote last year about problems arising from Developer ID signed apps and their dependence upon an Apple “timestamp server” during the code signing phase. In the article, I describe a workaround for scenarios where the timestamp server is either down or there is no internet connection: disable the functionality by adding “–timestamp=none” to the OTHER_CODE_SIGN_FLAGS Xcode build setting.

Swift based apps currently install a complete copy of the Swift standard libraries in the built app’s bundle, and during this phase, Xcode implicitly signs the Swift libraries with whatever code signing identity is defined by the project and/or target. Unfortunately in doing so, it ignores the OTHER_CODE_SIGN_FLAGS build setting, removing the opportunity to finesse code signing of the Swift libraries in the way I described.

The long and short of it? You can’t build a Developer ID based Swift application when you’re offline. I discovered this recently when I dug into a Swift application in a jet, high above the Pacific. Hours of uninterrupted, focused development time lay before me, but I was met with this annoying build failure:

The timestamp service is not available.
*** error: Couldn't codesign [...]/My.app/Contents/Frameworks/libswiftCore.dylib: codesign failed with exit code 1
Command [...]/XcodeDefault.xctoolchain/usr/bin/swift-stdlib-tool failed with exit code 1

The workaround is to turn off code signing completely, or to switch to a Mac App Store code signing identity (which doesn’t rely upon the timestamp service feature of the code sign tool). I filed this bug as a Radar #21891588.

WebKit Hacking From The Bleeding Edge

Apple, Open Source, OS X, WebKit

As the developer of an app that depends heavily upon Apple’s WebKit technologies, I have often been grateful that the software is open source. It is by no means easy to wrap one’s head around, but when faced with a vexing problem, I can browse, even build and run a custom copy of WebKit on my system, to step through code and try to reason more clearly about its behavior. I’ve even filed my share of bug reports and patches.

While I am very interested in the evolution of WebKit, I am even more concerned with the evolution of OS X. For this reason, I typically install OS X beta releases far earlier than many of my colleagues. This gives me the opportunity to work day to day with the latest changes coming from Apple, and makes it that much more likely I will spot issues with my apps, concerns with the OS, etc., before my customers do.

As an open source project, I initially believed I could build and run WebKit wherever I choose. After all, isn’t that what “open source” is supposed to be all about? But ah, there’s a catch. At least when it comes to building and running WebKit on OS X releases, there is a dependency on a small, binary-only static library which provides key system-specific linkages to WebKit. Usually this binary is added to the open source project around the time the system release goes public, but not much sooner.

The long and short of it? If you want to build WebKit and you don’t work at Apple, you need to do so from publicly released versions of OS X.

For years, I have found this personally annoying, but also philosophically distasteful. It seems like a problem for Apple, too: it’s in their best interest to have as many WebKit developers as possible staying up to date, building the latest versions, testing, submitting patches, etc. And it’s in their interest to have as many OS X developers running the latest betas of the OS, providing feedback, preparing their apps for the public, etc.

A single developer, with a single Mac, running a single installation of OS X cannot simultaneously be a diligent, interested WebKit developer and a dedicated OS X beta tester. This seems like a problem to me, so I finally reported a bug. Radar 21703162: “Beta OS X releases should facilicate building/running WebKit from source.”