Category Archives: Xcode

Remote Codesign Trust

iOS, Mac, Worfklow, Xcode

It’s common to use a remote, headless build server to perform iOS or Mac builds for which the “codesign” tool must be run to sign either the resulting binary, the installer package, or both.

My friend Mitch Cohen raised a concern on our local CocoaHeads that, since 10.11.1 was released, there is a problem with such setups. The dialog that pops up when using a code signing identity for the first time ignores clicks to the “Allow” and “Always Allow” buttons:

Panel prompting to allow permission to use codesign tool with private key.

If you look in the system Console, you see a line along the lines of this, correlated to each attempted click of an “Allow” button:

3/15/16 8:51:55.303 AM SecurityAgent[65532]: Ignoring user action since the dialog has received events from an untrusted source

The changes are apparently rooted in a legitimate security update made by Apple, but the end result for us developers is pretty bleak. It’s seemingly impossible to authorize use of a code signing identity on a remote server. As my friend Mitch put it, he has to call IT and “get someone to go into the data closet” every time this happens. What a drag!

I’m also affected by this issue, since I use a headless Mac Mini as a build server. Lucky for me the server is in my house, but it’s still a drag to have to go log in and control the computer with an attached keyboard.

I poked around for a solution to this problem, and found it lurking in the answers and comments of a Stack Overflow question. The basic idea is you can convince OS X to trust codesign to use the tool, just as if you had clicked the “Allow” button in that UI prompt. Here is a recipe for doing just that, logged in as a remote user over say Screen Sharing:

  1. Open Keychain Access and locate the pertinent private key. You may have to click on the “Certificates” section and then type in part of the name of the identity in question, e.g. “iPhone Distribution”:

    Screenshot of Keychain Access showing the private key

  2. Click the private key and then select File -> Export Items from the menu bar. Save the item anywhere on your server, for example the Desktop. Give it a password e.g. “hardpassword”.
  3. Now stop. Think real hard before you continue. You should have a backup of that private key somewhere. If you don’t? Don’t continue. Did you just make a backup to the Desktop? Yes, in theory. But if these are the only two copies of this private key you need to think long and hard before you continue with the next step, which I absolutely do not advise you to do.
  4. Delete the private key from your keychain. This is the scary (see above), but necessary step to get the Keychain to respect the new permissions you’re going to grant the key in a minute.
  5. Switch to the Terminal and issue a command like the following: 
    security import ~/Desktop/Certificates.p12 -k ~/Library/Keychains/login.keychain -P hardpassword -t priv -T /usr/bin/codesign -T /Applications/Utilities/Keychain\ Access.app

    It may be important to specify the path to the specific keychain, and to belabor the point you’re importing a private key with the “-t priv” parameter. It seemed like maybe things weren’t working for me until I deigned to include these. In any case, the goal here after running this command is that the private key shown in the screenshot above should now be back in your keychain, but if you double-click it to examine its permissions, you’ll find that codesign is listed among the approved apps. If you need to provide access to other tools than codesign, list them as shown above with multiple -T parameters to the “security import” command.

In my tests that seems to address the issue. After following the recipe above carefully, I can remotely “codesign” with the specified identity to my heart’s content, without a UI prompt of any kind.

It strikes me that this trick probably shouldn’t work, at least in light of Apple’s clamping down on the ability to change authorizations through the UI of Keychain Access. So I won’t be surprised if this series of tricks doesn’t stand the test of time. For now though? No need to call IT and have them go into the data closet.

Update: Erik Schwiebert reports that Apple has addressed this problem in 10.11.4 betas:

That’s great news!

Supercharged Search Scopes

Xcode

Xcode’s search facility is pretty robust, offering the ability to add custom scopes that can restrict with some precision the focus of your search:

Xcode custom search scope editor

However, if you browse the list of options in the popup menu for some of these items, there are frustrating omissions. For example, in the screenshot above you can see that I’m searching files that are within a folder “RSCommon” but whose path is not “YuckySources”. Unfortunately this search is not very useful, because none of my files has a path exactly equal to “YuckySources”. What I really want is an option to specify that the path does not contain “YuckySources”, but the option is not made available to me. Similarly, Xcode offers no choice for “is not within folder.” Generally, there are glaring omissions for negating conditions. (Radar #24510002).

Frustrated by this limitation, I went poking around in Xcode’s configuration files, and was pleased to discover that search scopes are saved in plain text in a file called SearchScopes.xcsclist, for example in Xcode’s configuration folder:

[Home] -> Library -> Xcode -> UserData -> SearchScopes.xcsclist

Update: As of Xcode 9 the search scopes are stored in a file called IDEFindNavigatorScopes.plist.

If you open this up in a text editor, you’ll see that in fact each search scope definition is substantially defined by a standard NSPredicate style expression:

<Scope
  name = "Yummy Sources"
  predicate = "path != &quot;YuckySources&quot; AND location_filesystem == &quot;/Users/daniel/Sources/RSCommon&quot;"
  uuid = "F5110DAA-5DE7-4DD8-A4B1-6D7CB4A2DF1E">
</Scope>

Do I dare to dream that fine-tuning this predicate in a text editor will lead to the desired search results in Xcode? I do! I quit Xcode and edited the predicate in the file so it reads:

(NOT path CONTAINS "YuckySources") AND location_filesystem == "/Volumes/Data/daniel/Sources-Modern/RSCommon"

This expresses the predicate for what I really wanted my search scope to be, but which Xcode wouldn’t allow me to configure. Opening Xcode and selecting the “Yummy Sources” search now allows me to search for results in RSCommon, but NOT in YuckySources. We’re golden!

So I think the limitation here is in Xcode’s predicate editor, which is apparently not robust enough to specify the variety of options afforded by predicate syntax. In fact a caveat here is if I now attempt to edit the hand-tuned predicate above, Xcode crashes with an exception:

comparisonPredicate should be an instance inheriting from NSComparisonPredicate, but it is <NSCompoundPredicate: 0x7fedcff19ff0>

Lucky for us, the code that applies the predicate seems perfectly happy with the hand-tuned, robust predicate. So I’ll be contented to continue using my fancy, supercharged search scopes, but I’ll remember to edit them in BBEdit when necessary.

By the way, the search scopes you create in Xcode are saved by default to the home folder relative path described above, but Xcode will also search for and load any search scopes configured within a workspace’s xcuserdata folder. For example, if you want to configure search scopes that are only meaningful to your “Delicious” project, you could store the configurations in this file:

/Delicious.xcworkspace/xcuserdata/[yourname].xcuserdatad/SearchScopes.xcsclist

I hope this understanding of Xcode’s search scopes helps you transform its already powerful search capability into an even better, finer-tuned resource for navigating your source files.

Unsteady Platform

Debugging, iOS, OS X, Xcode

I ran into a vexing build failure with one of my iOS integration builds. The vast majority of everything in my complex project, consisting of dozens of dependencies, has built fine, but at link time things blow up because one of the dependencies is not of the expected architecture.

Undefined symbols for architecture armv7:
"_RSIsEmpty", referenced from:
-[RSFormattingMacro emptyMarkupPlaceholders] in RSFormattingMacro.o
ld: symbol(s) not found for architecture armv7

Ugh, huh, wha? How is this happening? It turns out the library in which “RSIsEmpty” resides, RSFoundation, is being linked to, but it’s opting for an OS X version of the library instead of an iOS one. Because this is an integration build that performs a number of related builds for both Mac and iOS, it makes some sense that I would have both an iOS and OS X build result in the build folder. But even if I have built copies for either architecture, why is it opting for the OS X version on an iOS build?

I decided to blow away all the built versions of RSFoundation and try the build again. This time, I got an even more perplexing failure:

clang: error: no such file or directory: '[...]/build-Integration/Release/RSFoundation.framework/RSFoundation'

I’m scratching my head. Did it somehow get removed as a dependency? But then I notice something subtle. It’s looking for the framework in the “Release” build folder, but for my iOS build it should be looking in “Release-iphoneos”. What the heck is going on?

In spite of the sole build target in this scheme being an iOS app, Xcode (actually xcodebuild) is opting to build this scheme with a default destination of OS X. I don’t know of a direct way to get xcodebuild to list the available destinations for a scheme, but I know that if you pass a bogus destination platform, it will do the honor of listing its impressions:

xcodebuild -destination "platform=xx" -scheme MyIPhoneApp

The requested device could not be found because no platform could be found for the requested platform name.

Available destinations for the "MyIPhoneApp" scheme:
		{ platform:OS X, arch:x86_64 }
		{ platform:iOS Simulator, id:6DF04FFC-1C8A-4745-8F8C-7369E9CBF8DB, OS:9.3, name:iPad 2 }
		[... every other iOS simulator on my Mac ...]

Aha! So it thinks my iPhone app is suitable for OS X. But why? After a great deal of experimentation and poking around, I discovered the root of the problem is summarized by this true statement:

If any target in a Scheme’s dependency tree targets OS X, then the scheme itself will also be considered to target OS X.

In retrospect, this explains the problem perfectly. I had recently added a subproject to my dependency tree that builds both an iOS and a Mac version of a library. That’s fine: it works pretty well these days to allow targets for differing platforms to coexist in the same project file. But each of these targets also shares a dependency on a single, legitimate OS X target: a helper tool used in the process of generating that project’s own source files.

This must be at least a relatively common scenario for iOS builds of certain complexity. Because the platform on which all iOS builds run is OS X, any helper tools that are compiled and used in the process of generating sources or otherwise processing build materials, must be built for OS X.

The workaround to my specific problem is to specify a platform explicitly on the command line. I can’t assume that because the scheme targets iOS, it will necessarily default to an iOS platform target. I consider this a bug, not only because it led to this difficult to diagnose build error, but because it has other ramifications such as the presentation in Xcode’s scheme popup for these projects a useless, distracting “My Mac” target which should never be selected for the schemes in question.

I filed this as Radar #24247701: A scheme whose target has dependencies on another platform shouldn’t “support” that platform.

Not Available On tvOS

tvOS, Xcode

Along with many other Mac and iOS developers, I’m digging into Apple’s SDK for tvOS development. As announced in the special event yesterday, the SDK is based on iOS and will be very familiar to most Apple platform developers. There are, however, some differences: functionality from iOS frameworks that is not available on tvOS, as well as a handful of new frameworks specifically suited to the needs of “TV apps.”

A very notable absence is UIWebView. Black Pixel’s Daniel Pasco points out on Twitter that this will be a significant impediment to porting many iOS apps:

When I say UIWebView is absent, I should clarify that the class name is still present in the UIKit headers on the tvOS SDK, but it is marked with a new compiler availability attribute, __TVOS_PROHIBITED. This is handy because at least when you run up against the problem, you don’t have to fret about whether you simply neglected to link against the right framework. It’s there, it may or may not work, you just can’t use it.

In case it’s not obvious, you can use a massive search of the SDK’s header files to zero in on other such classes and methods that may be prohibited from use in TV apps:

grep -r TVOS_PROHIBITED UIKit.framework/Headers/*

(Note: it was brought to my attention that this search is purely academic because Apple has published a browsable list of API changes from iOS to tvOS.)

The results are a doozy! But many of the marked items simply wouldn’t make sense on Apple TV, like mucking with the UIStatusBar, are marked as prohibited. There are other tags too, such as __TVOS_UNAVAILABLE, which presumably denotes that technologies that Apple would like to provide but hasn’t yet, and __TVOS_DEPRECATED, which blessedly does not yet match any API provided in the tvOS SDK.

Take a look in the Availability.h header file for this and other interesting attribute definitions, including counterparts for OSX, iOS, and watchOS.

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!

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.

Right Storyboard, Wrong Platform

iOS, Mac, Xcode

If, in haste, you inadvertently add a storyboard file to your Mac or iOS project from the wrong platform palette, you’ll end up with a storyboard that compiles and installs into the app bundle, but which products cryptic errors upon building and running. For example, a Mac storyboard lost in an iOS world:

*** Assertion failure in -[UIStoryboard initWithBundle:storyboardFileName:identifierToNibNameMap:designatedEntryPointIdentifier:], /SourceCache/UIKit_Sim/UIKit-3347.44.1/UIStoryboard.m:52

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: nibNameMap != nil'

The assertion above occurs when, internally to UIStoryboard, the Info.plist for your compiled “.storyboardc” file is consulted to determine its constituent “.nib” files. In the Mac case, the keys for storyboard Info.plist entries have an “NS” prefix, e.g. NSViewControllerIdentifiersToNibNames, whereas on iOS, it goes hunting for a UI-prefixed key: UIViewControllerIdentifiersToNibNames.

Granted, as soon as you proceeded to the next step, trying to populate the storyboard with UI elements that make sense for the platform, you would probably figure out your mistake. But if you’re just trying to get the ball rolling and end up immediately scratching your head over the failure, hopefully this blog post will have helped you figure out more quickly what was wrong.

I don’t think there’s any official way to change a created storyboard’s platform target. Best bet if you run into this is to delete the storyboard and recreate it from scratch, taking care to select the file template from the appropriate platform in Xcode’s “New File” panel.

Storyboard To Nib And Back

Apple, Xcode

At some point along the way Xcode has consolidated the “Main Storyboard” and “Main Interface” fields pertaining to storyboard and nib files into a single “Main Interface” field that simply updates whichever of the pertinent Info.plist fields Xcode thinks you are working with.

The problem is that if you switch from storyboard to nib or back, then the value of the Info.plist entry is changed, but the key is not updated to reflect whether the new value is either a storyboard or a nib.

I’ve reported Radar 20954053 to Apple, requesting that Xcode should intuit from the file extension of the file named by “Main Interface” whether the Info.plist should advertise a storyboard or a nib.

In the mean time, if you switch from storyboard to nib or back, you need to manually update the Info.plist key to match: UIMainStoryboardFile if you’re using storyboards, or NSMainNibFile if you’re using nibs.

Auto Layout: Copy First, Then Edit

Worfklow, Xcode

Here’s a possibly-too-obvious tip for folks who are adapting older iOS and Mac UI from traditional “springs and struts” to Auto Layout: always make a copy of the nib content you are working on before you start hacking away.

Because Auto Layout requires you to flip the switch for e.g. a whole window at once, and because the various adjustments to frames you make while adapting to Auto Layout may affect views in unwanted and unexpected ways, it’s extremely convenient to have at hand the UI layout as it was before surgery, so to speak.

Sure, because everybody in their right mind these days uses version control software, it’s easy enough to check out a previous iteration of a xib file and open it up for comparison, but it’s become such a certainty that I will find value in the reference, I usually just make a redundant copy in the xib itself while I’m working:

1. Select the window element in Xcode’s Interface Builder.
2. Copy and paste to make a new copy.
3. Adjust the original’s Auto Layout information until satisfied.
4. Delete the copy.

Having the reference copy is very handy as well for trying to isolate layout behaviors to just specific parts for the UI. For example, a deeply nested view seems to behave unexpectedly and you can’t get the layout right. Copy just the original from your “backup window”, and paste the view in isolation. Now see if you can get the layout right in terms of itself, without respect to the larger window. This can help you figure out the “aha!” constraint that you need to go back and add to the “real window.”

Reordering Xcode’s Products Group

Xcode

In my last post I alluded to the problem of Xcode showing multiple products with the same name without differentiation in the UI:

Screenshot of Xcode project navigator with unorganized product items.

It’s bad enough to have two items there with exactly the same description, but it’s particularly annoying (especially when the products list is quite long) that the ordering of items in this section apparently cannot be customized at all.

If memory serves correctly, the Products folder used to just be an ordinary group in Xcode, where you might happen to organize your “product items.” It’s only recently that Apple has barred reordering of the items in the group.

It occurred to me that I could probably hand-edit the project.pbxproj file inside the Xcode project. Sure enough, rearranging the lines of the file such that the “children” of the “Products” PBXGroup item are in the desired order does the trick.

However, I won’t be hand-editing Xcode project files for this purpose anytime soon, because If found another glitch in Xcode that makes it even simpler. Just rename the “Products” group to anything but Products, then rearrange at will:

Screenshot of the products group with contents reorganized

Change the name back to “Products” when you’re done, and you’re done.