Code Signing and Mavericks

The Change

Very simply put, you can no longer sign a bundle (like your .app) if any nested bundle in that package is unsigned. These nested bundles are things like helper executables, embedded frameworks, plug-ins and XPC services.

The result is that you’ll need to update your Xcode projects as soon as you start building on 10.9. It’s taken me several days to understand what these changes are, and with the help of Perry Kiehtreiber on the developer forums, I’d like to share what I’ve learned.

(Yes, I realize this essay is going to break the NDA, but since Apple is asking us to submit apps for Mavericks, I want as many developers as possible to avoid the utter confusion I faced earlier this week.)

The Effect

So what happens when you do your first app build on 10.9 using Xcode 5.0.1? If you embed a framework that’s unsigned, like the very popular Sparkle.framework, you’ll see a message during the final CodeSign build phase:

CodeSign build/Release/
    cd /Users/craig/Projects/Mac/xScope
    setenv CODESIGN_ALLOCATE /Applications/
    Using code signing identity "Developer ID Application: The Iconfactory"
    /usr/bin/codesign --force --sign D2A3FE1814B0BA31B1924F1C3C3B5C89643FBED5 --requirements =designated\ =>\ anchor\ apple\ generic\ \ and\ identifier\ \"xScope\"\ and\ ((cert\ leaf[field.1.2.840.113635.]\ exists)\ or\ (\ certificate\ 1[field.1.2.840.113635.]\ exists\ and\ certificate\ leaf[field.1.2.840.113635.]\ exists\ \ and\ certificate\ leaf[subject.OU]\ =\ \"RYQWBTQRPT\"\ )) /Users/craig/Projects/Mac/xScope/build/Release/
/Users/craig/Projects/Mac/xScope/build/Release/ code object is not signed at all
In subcomponent: /Users/craig/Projects/Mac/xScope/build/Release/
Command /usr/bin/codesign failed with exit code 1


The codesign command is reporting that “code object is not signed at all” and Xcode is adding the “In subcomponent” to tell you which framework is at fault (it could just have easily been HockeyApp or any other third-party framework you use.)

So how do you go about fixing this?

The Wrong Way

In the past, many developers have relied on codesign‘s --deep option to make sure the entire bundle is signed. Specifying this option in “Other Code Signing Flags” will get rid of the error during the build, but all you’re doing is just postponing the pain.

The reason is that --deep recursively signs the nested bundles. As it does this, it applies the parameters for the top-level bundle to all the nested bundles. Things like your app’s entitlements will cause the resulting bundles to not be valid.

In fact, if you try to download and install the resulting app, Gatekeeper will notify your customers that your app is damaged and can’t be opened, with a default button to move it to the Trash:

You’ll see the same thing if you check the binary using the command line:

$ spctl --verbose=4 --assess --type execute build/Release/
build/Release/ a sealed resource is missing or invalid

The Right Way

What’s the right way to make sure the embedded framework is correctly signed? The answer is to add another Build Phase to your target.

If you’re embedding frameworks, you’ll have a “Copy Files” phase that moves things like Sparkle.framework into the Frameworks destination. Just after this Build Phase, add a Run Script with the following shell commands:

IDENTITY="Developer ID Application: The Iconfactory"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/Sparkle.framework/Versions/A"

This short script tells Xcode to sign the framework that’s just been copied into the build product. In this case, it’s using the Developer ID for Gatekeeper. If you were doing a build for the Mac App Store you’d use your “3rd Party Mac Developer Application” identity. Add a codesign command for every framework you use.

If you have other embedded code, such as helper executables, plug-ins or XPC services, you’ll need to sign them appropriately after copying them into your app bundle.

Updated October 18th, 2013: Another alternative is to set the code signing identity in the Build Settings of the frameworks you’re building from source. The trick here is that the identity of the framework needs to match the identity of the app itself. You can’t have have an App Store distribution identity for the framework and a Developer ID for the app. I found it much easier to explicitly re-sign the frameworks than to pass configuration settings from MyApp.xcodeproj to MyFramework.xcodeproj. It’s also easier to manage because the project changes are the same for binary-only frameworks (like Sparkle) and frameworks we build from source (like Chameleon).

The Checks

You’ll want to do a quick check of the build product before uploading it to either your website or iTunes Connect. The first thing you’ll want to do is check the signed bundle meets its designated requirement:

$ codesign --verify --verbose=4 build/Release/
build/Release/ valid on disk
build/Release/ satisfies its Designated Requirement

If there’s a problem, you’ll see a message that the app “does not satisfy its designated Requirement”. To view information about the signed code or the designated requirements, you can use these commands:

$ codesign --display --verbose=4 build/Release/
$ codesign --display --verbose=4 build/Release/
$ codesign --display --requirements - --verbose=4 build/Release/
$ codesign --display --requirements - --verbose=4 build/Release/

If this is a build you’ll be uploading to your website, you’ll want to make sure it will be accepted by Gatekeeper (and not display the “damaged” dialog.) Use spctl to do this:

$ spctl --verbose=4 --assess --type execute build/Release/
build/Release/ accepted
source=Developer ID

If this is an App Store build, you MUST check the .pkg file that gets uploaded to iTunes Connect (see the next section and you’ll see why I say MUST.) If you use productbuild to create the package manually, you’ll already have a .pkg file to test.

For those of you who submit archives directly from Xcode, you can generate the .pkg file using the command line:

$ xcodebuild -exportArchive -exportFormat PKG -archivePath /path/to/your.xcarchive -exportPath /tmp/CHOCKS -exportSigningIdentity "3rd Party Mac Developer Application: CHOCK LOCK INK” -exportInstallerIdentity "3rd Party Mac Developer Installer:  CHOCK LOCK INK"

You can find the path to your .xcarchive by selecting it in the Organizer and then using the Editor > Show in Finder menu item. The command above will create a /tmp/CHOCKS.pkg. Yes, you now have CHOCKS PACKAGE IF YOU KNOW WHAT I MEAN

(A quick side note, if you use xcodebuild, it got a lot of love in Mavericks. Make sure to check out the man page.)

To check out CHOCKS.pkg, run the installer with the -store option:

$ sudo installer -store -pkg /tmp/CHOCKS.pkg -target /
installer: Note: running installer as an admin user (instead of root) gives better Mac App Store fidelity
installer: CHOCKS.pkg has valid signature for submission: 3rd Party Mac Developer Installer: The Iconfactory
installer: Installation Check: Passed
installer: Volume Check: Passed
installer: Bundle com.artissoftware.mac.xScope will be installed to /Applications/
installer: Starting install
installer: Install 0.0% complete
installer: Install 13.8% complete
installer: Install 22.2% complete
installer: Install 47.6% complete
installer: Install 88.3% complete
installer: Install 100.0% complete
installer: Finished install

Now, sign out of the App Store and launch the app that was just installed in your Applications folder. If everything is OK, you’ll see the prompt for your Apple ID and a receipt will be written in the app’s _MASReceipt folder.

But not always.

(For more information on testing installer packages, check out the Testing section in my Mac App Store Guide.)

The Suckage

After being installed for the first time, some apps never get a receipt when they are launched on Mavericks. The app starts up, sees that there’s no receipt in /Contents/_MASReceipt and signals that it’s missing by exiting with a 173 code. Normally, storeagent will recognize this and prompt for an Apple ID. After valid credentials are provided, the receipt is written and the app is launched again.

Several developers, myself included, have noticed that after exiting with a 173, only the following is logged in the console:

Oct 17 11:59:03 Myrtle.local storeagent[72031]: Unsigned app (/Applications/

If this happens to you, it seems your only course of action is to not validate the receipt. Your code will launch fine if you never return a 173. Which, of course, sucks because it’s then trivial to pirate your the app.

For any Apple folks that might be reading this, check out the Radar: rdar://problem/15254213

Updated October 18th, 2013: Developers that are doing their builds on 10.8 also need to watch out for this problem. As a workaround, I tried building the product on 10.8.4 using Xcode 5.0. The resulting .pkg exhibited the same behavior at launch time as the one created with the Xcode GM on Mavericks.

The Workarounds

Xcode sometimes has problems generating a valid designated requirement. When you check the designated requirement, you might see this:

$ codesign --verify --verbose=1 build/Release/
build/Release/ valid on disk
build/Release/ does not satisfy its designated Requirement

$ codesign --display --requirements - build/Release/
designated => anchor apple generic and identifier Twitterrific and (certificate leaf[field.1.2.840.113635.] /* exists */ or certificate 1[field.1.2.840.113635.] /* exists */ and certificate leaf[field.1.2.840.113635.] /* exists */ and certificate leaf[subject.OU] = RYQWBTQRPT)

If you look closely, you’ll see that the identifier used for the requirement is incorrect: it should be com.iconfactory.Twitterrific, not just Twitterrific. The workaround for this bug is simply to set the identifier explicitly in your Build Settings. In our case, we added --identifier com.iconfactory.Twitterrific to Other Code Signing Flags.

Updated October 18th, 2013: It looks like this bug happens when you precompile your Info.plist. Thanks to Chris Liscio for verifying that problem. Make sure to dupe it, if you’re affected!

As to why you’d want to precompile your Info.plist, there are two good reasons.

The End

There you have it: a short summary of my last three days of confusion caused by new Gatekeeper requirements, issues with Xcode and bugs in Mavericks. Hopefully, this essay will save you some of that same agony.


Let’s talk about cars for a second.

If you’re driving a car manufactured in the past five years, it’s likely it has anti-lock brakes. A standard feature at this point in time, but who came up with it first?

Mercedes-Benz first introduced it on the S-Class line back in 1978. It was a revolutionary technology and the first hint of how digital electronics would change the course of the automotive industry.

The S-Class pioneered many other safety innovations: crash crumple zones, air bags and traction control are a few of the most notable. This line has also become synonymous with comfort and luxury: it was the first Mercedes to be available with an automatic transmission. There’s even an armored version with a customized crocodile, gold and birch interior!

It’s clear this car is in a class by itself: “Sonderklasse”

“S-Class” is an anglicisation of “”S-Klasse,” a German abbreviation of “Sonderklasse,” which means “special class” (in the sense of “a class of its own”). In automotive terms thus refers to “a specially outfitted car”.

The current S600 model sports a 5.5L twin turbo V12 motor with a 7-speed automatic transmission. Enough power to propel a 4,950 lb vehicle from 0 to 60 mph in just 4.5 seconds. And that’s before AMG gets their hands on it. Impressive automotive technology, to be sure.

More importantly, these special cars have been recognized as a driving force behind the company’s success.

And now…

Another premium technology brand has an S-Class product: iPhone 5s.

“Craftsmanship”, “Power”, “Safety & Security”, “Ahead of its time”. Are we talking about a car or a phone?

Look at the words that dominate the iPhone 5s features page: Forward thinking. That’s a strategy that’s worked superbly at Mercedes-Benz for almost 60 years. I suspect Apple will get a pretty good run out of it, too.


It looks like my hunch about the iPhone invite was right: new phones are likely to have “silver rings” that are fingerprint sensors embedded into the home button.

So what does this mean? Most people assume that it’s just going to be easier to access your home screen (without entering a passcode.) But I think it goes much deeper than that.

iCloud services are a huge part of Apple’s next decade. Everything the company is doing these days has some kind of connection to data that is stored remotely. They’re investing heavily in new data centers.

And anytime you want to access this data, you’re logging into iCloud. Wouldn’t it be great if you could skip the part where you have to type in your Apple ID?

It’s clear to me that your unique fingerprint will be tied to your unique Apple ID. Once this connection between your physical and online presences is established, some very interesting things become possible. Let’s take a look at a few things I think might happen:

Protecting access to apps

From the beginning, I’ve wanted a way to protect my personal information when sharing a device with friends and family. But any secure solution to that problem would be a pain in the butt. Typing a password before launching an app? No thanks!

But imagine if opening your favorite Twitter app only required a fingerprint scan before proceeding. Everyone’s favorite Twitter prank would thankfully die. And more importantly, we’d all feel a lot better about using things like online banking apps.

Corporate security

Most corporate networks are protected by VPN. The profiles that enable this network configuration often specify that a user must use a passcode lock. And it’s rarely a simple passcode. And it kicks in immediately.

Imagine needing to type in a eight character password with letters and numerals just to check the current weather. That’s a reality for millions of people who use their device for both personal and business tasks.

A fingerprint scanner that avoids this complex password will sell a lot of devices.

Multiple accounts

There are many scenarios where you want to let someone do whatever they want with your personal device: a partner providing directions while you drive, a kid playing games in a waiting room, your parents looking at vacation photos. All these people have something different than you: a fingerprint.

Entering a login and password has always seemed out of place in the simplified world of iOS. But detecting which account to use when tapping on the home button actually makes it easier for members of your family to use your personal device: they don’t even have to slide to unlock.

And once everyone has their own personal space on the device, no one can mess with it. This is important in many contexts: even something simple like a game has sensitive information as soon as a sibling comes along and screws up high scores or play position.

Borrowing devices

Most of us backup our data to iCloud. That data is restored to a device when it’s first put into service or if something goes wrong.

Now imagine if you had the ability to restore your data onto any device with the touch of your finger. Borrow an iPad and make it yours instantly. Businesses that strive to make a customer feel at home, like hotels and airlines, would love this capability.

Personal identification

If you think Apple is going to give developers access to this biometric information, think again. Google would love this data, so you know it’s not going to happen.

Slowly but surely

Don’t expect all these things to appear on September 10th. Apple will start out simply and continue to improve the software that uses this new sensor. That’s how they roll.

Acknowledgments: The genesis of these ideas came from a conversation with my colleague Sean Heber. He’s the one that first made the connection between iCloud and your finger. Thanks also go to Ryan Jones for the links about the sensor.

It’s the Production Line, Stupid

“Apple Absolutely Has To Make An iPhone With A Bigger Screen”

(Warning: Business Insider link)

While that may be true, take a look at what happened at the end of last year: 47.8 Million iPhones Sold.

That’s a shitload of iPhones. But how many is a shitload?

47.8M iPhones
/ 90 days = 530K per day
/ 24 hours = 22K per hour
/ 60 minutes = 369 per hour
/ 60 seconds = 6 per second

That means that every second of every day you need six cases, six headphone jacks, six LCD screens, six batteries, six CPUs, six 10µf capacitors, six 10kΩ surface mount resistors, and thousands of other components.

Look at where all the leaks about new products come from: it’s always the supply chain that produces all these components. This should give you an idea of how many partners are involved.

Basically, Apple creates a pipeline that produces devices at an amazing rate. And it’s a finely tuned machine with a lot of inertia. You don’t just walk in and say, “Hey, let’s change the screen!” Doing so would throw that machine out of balance: a new screen means that some of the components (like the headphone jack) don’t change, while others would (the case, for example.)

A finely tuned production machine takes a lot of time and money to set up. Take a look at Apple’s capital expenditures. A mere $10B in 2012.

These capital expenditures show that Apple is planning ahead. At least 2-3 years, maybe more. You don’t just walk into Foxconn and ask for 50M iPhones. You need to predict the future.

Sure, it would be great to have a larger screen iPhone from what is known about current market conditions. But was a larger screen a sure thing 2-3 years ago? While you were falling in love with the new Retina display on your iPhone 4, I bet you weren’t thinking “Man, this display has got to be bigger!”

The cost to setup that production line is also a part of the final cost of the device. More frequent changes to the production line means that each device costs more or earns less profit for Apple.

As Apple continues to sell ever more devices, I see two things that could happen:

  1. A broader range of products (meaning more, smaller production lines to spread the demand)
  2. Increase the size of the production lines along with amount of time they stay online (meaning new devices are introduced every three years instead of two)

Given the highly competitive nature of the mobile space, I suspect we’ll see the first option come into play in the coming years. In the meantime, screens tick, while speed tocks:

Cheap as in Computing

There’s a good case for an iPhone that costs less. But with this lower cost, developers fear that device specifications will suffer:

As someone who’s actively working on an iOS 7 update, I’m noticing a definite pattern emerging: we’re removing a lot of shadows, gradients, and transparency. A lot of views that were previously required to make an app look at home on iOS 6 are no longer needed.

The visual simplification of iOS has led directly to a simplified implementation. As every developer knows, the less work your app does on a mobile device, the better it performs. It’s a lot easier now to make an app that feels fluid and uses less CPU and GPU resources.

While everyone focuses on what Jony Ive has put on the screen, he’s also made the hardware under that screen able to do more with less. And yet again, Apple’s tight integration of hardware and software is going to kick everyone’s ass.

Updated August 14th, 2013: A lot of Twitter followers are saying, “But what about the live blurs? Aren’t those CPU/GPU intensive?”

Yes, they are. And you should also note that access to those features is strictly through private API. An iPhone 4 turns off blur, an iPhone 5C could do the same if necessary.

(If you look closely at the blur behind a toolbar, you notice that there’s some kind of sub-sampling of the screen image. Because this implementation is private, the algorithm could also be adapted for other devices.)

There’s also the question of all the new dynamics in the UI (like bouncy messages.) The highest costs in a GPU, both with computation and hardware components, is with dealing a lot of textures. The math for a physics engine is relatively easy to handle.

AMBER Alert Usability

If you live in the State of California, you got an AMBER Alert last night just before 11 PM. If you have an iOS device, you saw something like this on your lock screen:

Or like this in Notification Center:

And if you’re like most people, you had no idea what it meant. Considering it’s a broadcast to locate missing children, that’s a bad thing. Let’s examine the usability of this alert and think about how this system can be improved.

Updated August 6th, 2013: Lex Friedman has written a great summary of AMBER Alerts at Macworld. Among the revelations: the text of the messages are limited to just 90 characters!

First Impressions

In our household, there are many iOS devices. At the time of the alert, we were in the living room with two iPads and an iPhone. The alert’s sound is designed to get your attention, and that it did!

Both my wife and I gave each other that “what the hell is wrong” look as I grabbed my iPhone from my pocket. Turns out we weren’t the only ones who were frightened by the sound:

My wife’s first question as I looked at my phone was “Are we having a tsunami?” (we’ve had these kind of emergency broadcasts before.) I replied with, “No, It’s an AMBER Alert”. To which she replied, “What’s that?”

And therein lies the first problem: I had no idea.

Unlike all other notifications on my iPhone, I couldn’t interact with the alert. There was no way to slide the icon for more information or tap on it in the Notification Center to get additional information. Through a combination of Google and my Twitter timeline, I eventually figured it out:

But I was also seeing a lot of people on Twitter whose response to the confusion was to ask how to turn the damn thing off. And since AMBER Alerts aren’t affected by the “Do Not Disturb” settings, a lot of people went to Settings > Notification Center so they wouldn’t get woken again in the future.

That’s exactly what you don’t want to happen when a child is abducted.

Alert Text

In looking at the message itself, it’s hard to tell what it’s about. Starting an alert with an acronym may make sense to the government, but there’s wording that could resonate much effectively with normal folks:

It’s also hard to tell if this is a problem with “Boulevard, CA” or a “Nissan Versa”. And where is Boulevard? And what does a Nissan Versa look like? Who do I call if I see license 6WCU986? In summary, this notification provides more questions than answers.

This one image has answers to all of these questions and more. Why can’t I see that image after tapping on the notification?

The Alert Sound

As I mentioned above, the sound definitely let us know that something was wrong. But we were sitting comfortably in our living room. A friend of mine was driving at the time and probably listening to music from their iPhone on a car stereo. Being startled at high speed is dangerous:

Unlike the devices that existed when the AMBER Alert system was first introduced in 1996, our iPhones and iPads do a lot more than calls and texts. Music and video are immersive activities and hearing a loud horn can be a cure that’s worse than the disease.

Also, we’re all conditioned to immediately look at our phone when the normal alert sounds are used: a simple ding would have gotten just as much attention.

Do Not Disturb

And what the heck is up with this crazy sound happening if Do Not Disturb is turned on? Dammit, it’s my phone and I get to tell it what to do. Stupid Apple!

Well, take a look at your government first:

And if you want the details, it’s only going to cost you $205 to download:

Bottom line: these bugs aren’t going to be easy fixes.

(And if you think getting woken up because of an AMBER Alert is such a terrible thing, why don’t you explain your pitiful situation to this boy’s parents.)

File A Radar

Even though these bugs probably aren’t Apple’s direct problem, I’m still going to file a bug report. If you have a developer account, please feel free to duplicate that Radar.

Apple is in a very unique position to address these issues:

  • It has direct access to millions of customers and their mobile devices.
  • It employs many people with a deep understanding of how mobile devices are affecting our lives.

This is clearly a problem where cooperation between Apple, the Department of Justice, and the public can improve a system where everyone benefits. Better usability with AMBER Alerts is case where “think of the children” isn’t a trite platitude.

App Updates for iOS 7

Like many of my fellow developers, I am in the middle of an update of an app for iOS 7. As you’d expect, it’s a lot more work than previous versions of iOS. But results are stunning: both David Lanham and I have commented that our shipping version was “feeling old and clunky.”

While cranking along on the update, a couple of thoughts occurred to me: how many other developers were doing the same thing and were they going to commit fully to iOS 7? The depth and breadth of the changes in iOS 7 makes it difficult to support older versions of the OS.

So I just asked. I also included a simple question that any developer who was actively working on an update would be able to answer as a sort of CAPTCHA.

After a little over 24 hours, I had my answers:

An overwhelming number of developers are updating apps for iOS 7. Of 575 valid responses, 545 developers indicated that they were working on an update for iOS 7. That’s an adoption rate of 95%!

Of those developers who were working on an update, I then calculated how many were going to require iOS 7 (and drop support for iOS 6):

Just over half of developers (284 of 545) were leaving the past behind. Initially I was surprised that this number was so high, but then I remembered how much time and effort I was putting into my own work :-)

If you’re a consumer of apps, this is great news: it’s likely that your favorite apps will be ready for action come this fall. If you’re someone who has a device that’s a couple of years old, now’s the time to start thinking about upgrading. Many apps will require a device capable of running iOS 7.

After I posted the survey, I heard from several game developers who complained that they didn’t know the answer to the trick question: UIView -tintColor is only used in traditional interfaces. Most of the difficulty in adapting apps is changing navigational and content elements to match the new style. Games don’t have this problem: they’re basically all content. Considering these facts, my guess is that games will have much broader support for older versions of iOS.

If you’d like the raw data and my analysis using Numbers, here you go: iOS_7_Updates.numbers

The Origin of Tweet

Last week, one of my colleagues informed me that the word “tweet” was now included in the Oxford English Dictionary (see “Quiet announcement” at the end of the page.)

The noun and verb tweet (in the social-networking sense) has just been added to the OED. This breaks at least one OED rule, namely that a new word needs to be current for ten years before consideration for inclusion. But it seems to be catching on.

John Simpson
Chief Editor, Oxford English Dictionary

It’s not everyday that a word you helped create gets added to this prestigious publication, so I thought I’d share a bit of the early history of the word “tweet.”

In the early days of Twitter, the service used “twittering” as a verb and “twitter-ers” as a noun. The December 2006 newsletter is a great example of the lingo that was in use back then:

From: "Biz Stone"  
Date: Wed, 06 Dec 2006 07:51:31 +1100
Subject: Twitter Now Supports AIM and More

Hello Twitter-ers!

Things are really heating up at Twitter headquarters these days.  Last month, the number of Twitter users doubled and it looks like it's going to double again before we run out of December. We  thought the best way to react to all this positive activity would be to keep on making improvements. So come on by and check out!


That's it for now, Happy Twittering!
Biz Stone and The Twitter Team

I started started using Twitter at the beginning of December. Like John Gruber and my colleagues at the Iconfactory, I loved our new “water cooler for the Internet.” I was, however, unhappy with using Twitter via the website or Dashboard widgets.

While taking a shower in the middle of December, an idea struck me: it wouldn’t be hard to hook up Twitter’s new API to the Cocoa networking classes and display a table with tweets. So I dried off and started prototyping: the next day I had the world’s first Twitter client running on my Mac.

A few days later, I checked all my code into our repository and Twitterrific was born:

r174 | craig | 2006-12-20 17:54:11 -0800 (Wed, 20 Dec 2006) | 1 line

Initial import

There was a problem, however.

As I started to implement the user interface, it was clear that nouns and verbs were needed. Menu items with labels like “Post a Twitter Update” were both wordy and boring. And as someone who loves language, using a phrase like “Refresh Twitterings” made the hairs on the back of my neck stand up.

So we started calling them “twits”; more as a placeholder than anything. Using the term in January 2007 felt just as awkward as it does today:

@Dan: my wife was using the Mac when your twit popped up, followed by “there’s a guy named Dan who’s looking for love”. Classic.

(Thanks to Jordan Kay at Twitter for digging that tweet up. Also, the “Dan” is Dan Benjamin—in those early days we hadn’t figured out screen names, and as far as I knew, there was only one Dan on Twitter!)

Luckily, things were about to change. On the 3rd of January, I checked in a temporary application icon. I always check in something crappy as an inspiration for the talented folks I work with:

r215 | craig | 2007-01-03 13:46:11 -0800 (Wed, 03 Jan 2007) | 1 line

Added a temporary application icon. Updated preferences panel (with quit and about info.) Tweaked on window size. Added expanded size to preferences. 

Less than 24 hours later, David Lanham sent me something much better.

I couldn’t check it in quickly enough:

r225 | craig | 2007-01-04 13:21:01 -0800 (Thu, 04 Jan 2007) | 2 lines

Added new app icon

We didn’t know it at the time, but this is also the moment when a bird became synonymous with Twitter. Prior to that point in time, Twitter’s only identity was a logotype.

Work was proceeding at a very fast pace during the first week of January 2007. Beta releases were frequent and widely distributed. Fortunately, the folks at Twitter were using our app with it’s snazzy new bird icon. One of our beta testers was an API engineer named Blaine Cook who sent me the following email:

From: "Blaine Cook" <[REDACTED]>
To: "Craig Hockenberry" <[REDACTED]>
Date: Thu, 11 Jan 2007 18:29:01 -0800
Subject: Twitterific

Hey Craig,

I work on Twitter with Jack, and just wanted to ping you re: Twitterific. First off, great work - I love it, and I think so does everyone else in the office! :-)

Two thoughts; first, how about changing "twit" to "tweet" - the "official noun" is "Twitter Update", but that's boring...? 

Second, I'm in the process of building a real (re: flickr-style) authentication API, so that you'll be able to obtain tokens for users without having to store their usernames and passwords. I don't want its pending release to stall your development or release date, since we will continue to support basic auth for existing clients, but would you be interested in beta-testing the api machinations? 

Thanks again for Twitterific!


(In retrospect, this email is also the first hint that we spelled the app’s name wrong!)

It’s rare to have unanimous agreement when naming things in software, but in this case everyone loved the word “tweet”. I quickly updated both the app and the website:

r263 | craig | 2007-01-12 11:46:22 -0800 (Fri, 12 Jan 2007) | 1 line

Changed "twits" to "tweets". Removed auto launch of Twitterrific web page. Added link to Twitterrific web page in config window.
r2183 | craig | 2007-01-12 11:44:07 -0800 (Fri, 12 Jan 2007) | 1 line

Changed "twits" to "tweets"

And not a moment too soon! We released the first version of Twitterrific just three days later with the following copy on the product website:

About Twitterrific

Twitterrific is a fun little application that lets you both read and publish posts or “tweets” to the Twitter community website. The application’s user interface is clean, concise and designed to take up a minimum of real estate on your Mac’s desktop.

This is the first time “tweet” appeared on the Internet in reference to something you do on Twitter.

Our new app was a hit with users everywhere. We even got a mention in Twitter’s next newsletter:

From: "Biz Stone"  
Date: Wed, 17 Jan 2007 07:37:07 +1100
Subject: =Things Are Heating Up At Twitter

Hello Twitter-ers!


Continued Hotness: Twitterrific

The folks over at The Icon Factory have created a brilliant little application that lets you both read and post updates to Twitter. The application's user interface is clean, concise and designed to take up a minimum of real estate on your Mac's desktop. Twitter headquarters is sporting this little jobbie on every monitor in the house! Download it for free from The Icon Factory web site.



Things are heating up!
-Biz Stone and The Twitter Team

Unfortunately, the work I had done to expunge “twit” from our app was not complete: I had forgotten to remove it from some button tooltips. After the release of version 1.1 on January 25th, “twit” was gone for good.

Even though the use of the word “tweet” spread quickly, Twitter took awhile to embrace the new terminology. Even after several months, “twitter-ers” were still “twittering”.

As far as I know, the first time “tweet” appeared on Twitter’s site was when they referred to our product. (And yes, there was a point in time when the founder of Twitter would send us feature suggestions!)

Almost a year later, “tweet” was used on the company blog (but again, in a quote by a third party).

The word “tweet” didn’t appeared unquoted on Twitter’s blog until June of 2008. Coincidentally, it was in reference to the WWDC where we won an Apple Design Award for Twitterrific!

It still feels strange to hear a word I helped create be mentioned over and over again in the media. It’s a great word to go along with a great service, and in the end, I’m just happy we’re not calling each other twits!

Addendum – July 13th, 2013

I dug around through my Twitter archive and came up with some interesting tweets that show how and when the first Twitter client came to be.

The first notion that Twitter didn’t belong solely on the web happened on December 5th, 2006 (a couple of weeks before the first check-in in the Twitterrific repository.) This line of thinking was inspired by a tweet John Gruber had posted about the Dashboard widget he was using:

Less than an hour later, I posted this:

A couple of days later, I started poking around with the new Twitter API:

(Note that in the early days of Twitter, the website was designed around @jack’s original idea of posting status messages. The user name was implied in the post, hence “Craig Hockenberry” “is experimenting”.)

By the 20th of December, I felt confident enough in the state of the project to go public (that’s also the day that the prototype code got checked into the repository):

At the Iconfactory, everyone gets a two week Christmas break. I’d rather code than shop :-)

Unlike many products, we knew the name of what we were building very early on:

And from this point on, I never posted from the website again:

Here’s the first tweet with a source parameter (that tells Twitter which client posted the tweet.) We worked with Twitter engineering to implement this, and for a long time Twitterrific was the only source besides “web”. Note that this happened just two days before the release!

Of course on January 14th, 2007, the release was announced on Twitter:

Been There, Done That

We’re all thinking a lot different today.

Designers and developers alike are coming to terms with Apple’s latest iteration of iOS. As I tweeted just before the announcement, there is only one way to describe it:

shock |SHäk| noun
• a sudden upsetting or surprising event or experience.

Those of us who’ve been around awhile had a similar experience 13 years ago. Apple switched from the Classic interface in Mac OS to a new Aqua interface. As fate would have it, I was in the room with some of my colleagues when Steve Jobs introduced a UI “that you wanted to lick.” We all left that keynote in the same state of shock as we experienced yesterday.

I think it’s useful to look at the history of Aqua while thinking about the future of iOS 7.

Some designers are saying that the new look is “over the top.” The same thing was said about Aqua over a decade ago. And in succeeding years, that original UI has continuously been refined to what we see today.

We’ve become accustomed to Apple’s incremental approach which continuously refines their products. This is typically an additive process where new features are included or existing ones are improved.

But with major user interface changes such as Aqua or iOS 7, Apple has another tendency: they overshoot the mark. Their incremental approach then becomes one where unnecessary items are removed (such as Aqua’s stripes) or improved (excessive shadows and transparency are toned down.)

There’s a good reason for this: it’s much easier to take away elements from a design than it is to add them. Simplicity is achieved by removing that which is not really needed.

One parallel with iOS 7 and Aqua that I don’t expect to see: an evolution that takes over a decade. There are a couple of reasons for this.

The first is that the pace of development for iOS is much faster than we’ve ever seen for OS X. Ask any developer and you’ll hear the same thing: it’s a constant struggle to keep up with Apple’s improvements on iOS. Shit happens, and it happens quickly.

Another is the amount of time Apple’s designers have had to work on this project. The decision to put Jony Ive in charge of the interface design happened in October: a mere eight months ago. A major overhaul of a system-wide interface takes much longer than that.

It would not surprise me to learn that the developers had a very short time with the graphical assets we saw yesterday (think in terms of weeks.) This would also explain why the first beta is only available for smaller screens. The development work to support larger screens is relatively easy, but specifying the layouts and generating the assets is much harder.

Another important aspect to consider is the conditions where this new user interface was being evaluated. Every iOS developer who was using iOS 7 prior to yesterday’s announcement was using a security screen. These screens distort the colors and other elements on screen. Try looking at your laptop screen with polarized sunglasses and you’ll see what I mean.

Apple’s “doubling down on secrecy” also played a part. No friends or family were able to see an engineer’s work-in-progress. It’s likely that no one outside the engineering organization was able to give feedback on what they saw. I can think of a few types of users where this kind of criticism is essential: kids that can’t read, friends with vision impairment and parents with failing eyesight.

The good news, and reason I think that we’ll see many improvements before the fall, is because these kinds of surface changes are relatively easy to implement.

Which leads me to my final points: what are the most exciting parts about what happened yesterday?

It’s hard to tell from the keynote, but all of the interactions that surround the app you’re using are vastly superior. Unlike the visual redesign, the work on Springboard feels more mature. It’s likely that work has been underway for a much longer period of time (probably before last year’s WWDC.) Moving around in iOS is so much more fluid and natural.

Like with Aqua, these fundamental changes in how things work will stick around for a long time. We may complain about how things look in the short term, but improvements in usability will be something that we value much more in the long term.

But more importantly, and more subtly, is the change of focus within the apps themselves. In the design of Twitterrific 5, we went through the process of figuring out what content was most important and then designing controls around that information. Previous designs focused on the control structure first and then filled it with content.

(It’s also interesting to note that apps like Twitterrific and Vesper, which take this content-centric approach, also immediately feel at home on iOS 7.)

It’s clear that Apple’s designers have done the same thing: their focus has shifted towards content. I can’t wait to see what happens to the iOS ecosystem when other designers and developers follow their lead. That path forward won’t be easy, but it will take the platform to a whole new level. Yet another example of “can’t innovate any more, my ass”.

Launch Services Woes

For the past week or so, I’ve been suffering from slowness in the Finder, corrupted icons and terrible performance in our version control client (Versions).

Today, I decided to do something about it. The first step was to sample Versions while it was beachballing. The app was spending most of its time in [NSWorkspace iconForFile:]. That, along with the corrupted icons I was seeing in various apps made me suspect that there was a corrupted database somewhere. But where?

After a lot of Googling, I finally found this link. The path to lsregister has changed a bit in Mountain Lion, so this is the command I ended up using:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -seed -r

My development machine immediately felt like it was running at normal speed (I refuse to say snappy until they update the Mac Pros.) And, of course, as soon as I figured that out, I found that someone smarter had beaten me to it.

So how did this happen? In looking at the documentation for the Launch Services database, there is a lot of information that’s collected when applications are first launched. As developers, we launch applications all fricken’ day. And we also know that pounding on a database is the best way to break it.

So, the next time you’re seeing general slowness on your Mac, don’t forget to give Launch Services a kick in the pants. Guaranteed to be more effective than zapping your PRAM.