You probably know this, but just in case you are out of the loop, I’ll give some quick background.

Apple’s trackpads – obviously including the iPad – can support up to eleven distinct touchpoints per touch sequence. In other words, you can use both hands and…your nose? On the iPhone, and mostly on the laptops, we use one or two touches most of the time.

On top of the number of touchpoints, multitouch development uses a concept of “touch sequences” to track a discrete series of touches over a short period of time. In English, that means you can put ALL ELEVEN FINGERS on an Apple touch screen, twist, twirl, and swipe, and apps can respond accordingly.

This is fairly new to personal computing. We’re used to a keyboard, a mouse, occasionally a trackball or trackpad. We point, we click, and we drag.

Now we can do more. Much, much more. Obvious, yes? Yes.

Today

We’ve all seen touch-and-drag. We’ve seen flicking through a collection, or flicking to activate supplemental controls on a cell. We’ve seen pinch-to-zoom and reverse-pinch-to-zoom-out. We saw these on the most well-funded educational video series ever: Apple’s own iPhone TV commercials.

Apps mostly stick to the meaning of those gestures, and users benefit from that fact. Collectively, we developers and designers have self-regulated in a fairly organic, reactionary way. But with the larger screen on the iPad, can we unify sooner? Preemptively?

Just wait until people begin using the iPad. Think about that form factor, about the usage contexts. It wouldn’t shock me if a QWERTY keyboard disappeared from the device in a couple of years, replaced by something brand new…something one-handed and elegant. If so, the new *thing* should be leveraged across apps to the benefit of everyone. Novel gestures are a fleeting competitive advantage.

Why Collaborate?

In the sort of wild west that popped up around the iPhone – and will likely pop up around the iPad – the earliest adopters gained footing and market share (by virtue of a smaller market) while users floundered in a Stockholm Syndrome situation. Consumers were captive to the limited array of apps that existed in the early days and were willing to invest time learning how each app worked. A lot of folks are still quite flexible, but I wonder how long it can last.

The tipping point between critical mass of users and critical mass of apps happens quickly, though, and we product designers have to make sure it tips the right way. That is, in favor of users. And reciprocally, in favor of product developers. We can do that by lowering the learning curve for each new app that pops into the store.

A Warm and Comfy Blanket Statement

It’s a mistake to hijack established gestures, just as it would be a mistake for every computer to have a different keyboard layout.

I wrote about this in my book on iPhone UX hacking, and still abide by it.

We owe it to users to collectively invest the same meaning in each new gesture we invent/acknowledge, unless there’s a great reason to change established gestures. If that’s the case, we should register the change with other product devs/designers and move everyone else in the right direction.

We should also focus on bringing new gestures to market in a way that prevents confusion. It would be great to share feedback from our users on input gestures. I can even imagine a choreographed A/B test among competing apps. (KUMBAYA!)

Right now, though, there’s no easy way to share. No grand central dispatch. No forum.

We can read the iPhone and iPod Human Interface Guidelines, copy the earliest players, and bank too much on “common sense” (a problematic concept if ever there were one).

Instead, maybe we should talk about this. Contribute. Debate. Share code. Share artwork. Share labels. Share translations.

The Gist – CommonUX

To get to the point, I want product designers to collaborate and focus competition on features that don’t alienate users. I want us all to share our concepts for gestural input, share the iconography that represents actions (and more), and focus our innovation on the features that matter. Let’s assist users by assisting each other, reduce barriers, and make for a great platform where product designers can spend time where it pays off.

I’ve created a GitHub site and have purchased a domain that could – if folks choose to participate – act as a central repo for collaborating on common user experience elements. This post is to get the word out and figure out whether folks care.

Elements we can standardize include:

• Gestures for common actions
• Apple-friendly icons representing common concepts or objects
• Code and icons for both Cocoa and Android (and…?) for handling common gestures
• Colloquial names for gestures

So, welcome to CommonUX. Let’s sort it all out.

Certainly, I’ve contributed my fair share of aesthetic pollution/terrorism during a lucrative and decorated career in interactive marketing, and if I end up starting my own shop, I’ll likely have to suffer through projects like these to make ends meet. (I hope not, but start-up life can be hard.)

Still, we should stay honest. Even if we ignore the irony of such an unhealthy product claiming to care about nutrition, this app won’t make America smarter, healthier, or more likely to buy Wonder Bread. These types of initiatives are pointless. Wonder Bread isn’t going to test better. It’s not going to borrow any halo from the iPhone brand. It’s not going to gain any new reach, any recall, and sure as hell won’t see any cases moved. It’s going to embarrass the person who flipped the switch on the green light.

Why do companies keep jumping on the “gotta be on every screen” mindless non-strategy? It doesn’t matter what we release, as long as it’s there!

The App Store, in particular, is a difficult ecosystem. Contrary to what marketing geniuses think, there isn’t an effective addressable audience equal to the number of iTunes accounts. Sure, the eyes are there, but they’re discerning (mostly), fickle (extremely), and purposefully ignorant of 98% of the apps in the store.

Wait a Minute…This is Genius!

Ya know, maybe Wonder Bread will actually help make America healthier with this app. By wasting their marketing cash on pointless efforts like this, they may lose some market share. Getting Wonder Bread out of shopping carts would be great for America.

Hopefully this strategy can spread to soft drink companies, tobacco companies, and booze conglomerates!

The question is obvious for mobile projects because highly variable environments are par for the course. It matters with all non-stationary touch points, though – from door handles on train cars to Android applications to the work we’ll surely be seeing from the new Schematic Touch group.

Asking the question is easy. Using the response may not be. I see mobile apps all the time that are clearly made for users who are stationary, physically stable, connected to a consistent network, and with both hands free for interaction. High demands, right? They conflict with my more common usage patterns, and those apps rarely get launched.

A great example of a more subtle conflict – and one being addressed without much fanfare by many app developers – is iPhone usage in bed and auto-rotation.

Welcome to My Boudoir

My wife and I are incredibly lame. We tend to lie, side by side, reading news on our iPhones before falling asleep at night.

Apps that auto-rotate when the device orientation changes suck in bed. Or on the couch. Or in a reclining seat in first class. Or in a hammock. You get the point.

The problem is that we all flip-flop all over the place in bed (va-va-va-voom!), changing the point of reference for orientation. What makes a lot of sense when we’re upright is a pain in the ass when we’re horizontal.

A Suggestion

I’d like to encourage developers to carefully consider auto-rotation. A lot of devs are starting to catch on to this one as customers complain or make feature suggestions. I thought I might provide an example illustrating a really easy approach to disabling auto-rotation globally in an app. There are more sophisticated and pattern-y ways for the clever.

Don’t get me wrong – auto-rotation can be a great feature. I am all for it. But I have decided the baseline rule should be: If your views auto-rotate, you should provide a (preferably in-app) preference for disabling the feature.

An Example

So how does a developer do that?

Well, the interface is up to you. Let’s assume you have a project with a button that brings up an in-app settings screen.

If you have a UISwitch in there that represents the global auto-rotation state, just save it to the user defaults when you close the settings.

- (IBAction) dismiss:(id)sender
{
	// Update the defaults.
	NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
	BOOL autoRotationEnabled = self.autoRotationSwitch.on;
	[defaults setBool:autoRotationEnabled forKey:kAutoRotateKey];
	[defaults synchronize];

	// Close!
	[self.parentViewController dismissModalViewControllerAnimated:YES];
}

In your app delegate, declare a method to get the current global auto-rotation value.

- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
	return [[NSUserDefaults standardUserDefaults] boolForKey:kAutoRotateKey];
}

Finally, in each view controller that should obey the globals, ask the app delegate for the scoop.

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
	PillowTalkAppDelegate *appDelegate = (PillowTalkAppDelegate *)[UIApplication sharedApplication].delegate;
	return ([appDelegate shouldAutorotateToInterfaceOrientation:interfaceOrientation]);
}

Here is a quickie example project that illustrates the concept: PillowTalk.zip

It’s shorter than I would have liked, and took longer to write, but it’s nice to have it in my hands.

You can buy it at Amazon.

I think iTunes has become the main interaction platform for Apple. Given the popularity of the iPod line and iPhone, combined with iTunes for both Windows and Mac OS X, I’d bet more hours are spent using iTunes than Finder every day.

As with the App Store, Apple seems to be stumbling over itself with the iTunes experience. They need to slow down, reset, and rethink the experience promised by the Apple brand.

We know that iTunes is slow. The UI is inconsistent. The store feels completely alien to the main UI and experience. The app does far too much, plays too many roles too slowly. iTunes is more Wal-Mart than Apple Store.

People tolerate iTunes because it isn’t unbearable. It does work, after all. We all know the flaws I’ve mentioned and begrudgingly accept them because iTunes is the only choice we have. Another case of Software Stockholm Syndrome, I guess?

But here are two new (to me) insights.

1. iTunes focuses on multiple mobile devices paired to one computer rather than treating all Apple machines as peers. If nothing else, Apple should invert the model they currently use. Instead of one machine and one or more peripherals, they should focus on the more common case of one device and multiple computers.
2. Syncing a device to iTunes gets more painful every day, pushing users away from iTunes. Syncing a single podcast from iTunes to an iPhone takes fifteen minutes. It’s painful. This is a big threat the the Apple halo effect.

Mobile devices are for mobile people. Most of us operate in at least two computer-focused environments: home and work. Apple lets us buy, download, and sync content (apps, podcasts, audio, video) on a single computer, but on multiple iPhones or iPods. We still can’t easily add content – with or without DRM – to our devices from work and home. Aside from risky hacks to trick the phone into seeing multiple libraries as one, there are no practical ways to keep the whole digital lifestyle in sync.

My wife has stopped plugging her iPhone into her computer. In fact, she’s stopped opening her computer, save for writing posts on her blog. I asked why.

“I can do everything I need to do on the iPhone. I can get podcasts and music and apps, and iTunes freaking sucks, so why bother?”

The Apple lifestyle brand and experience is amazing when it’s strong, but like so many other things, it’s a bubble. iTunes is a thorn. Apple peripherals once caused a halo effect, but as they get better and iTunes gets worse, the iPhone and iPod Touch might cannibalize the Apple (desktop, laptop) computer market for lifestyle users.

The newest example: Mastercard Priceless Picks.

Their location aware social review sharing tidbit finder app is a cute, ephemeral trinket (at best). It would have made a rather interesting location-aware banner ad. Unfortunately, someone told them they should ship an iPhone app instead of a ton of banners. Hey, why not, right?

Here’s one reason: installing an iPhone app is work. If you make users work, you owe them something valuable.

Despite the attempt at “one-click” installation, the App Store is a nightmare. iTunes is still slow and unwieldy. Installing, updating, deleting, and managing applications is still quite a bit of work.

Contrast this to banners. A banner loads when a page loads. Users don’t have to do anything. Actually, users don’t get to do anything – including disabling ads or opting-in – but that’s a post for another day. Unlike iPhone apps, the barrier to entry for a banner is very low. Your debt to users is lower.

They’re fast to develop, cheap to run, and simple to measure. They probably get more traction than iPhone apps, especially as the “first in my category!” novelty slots are snapped up. But alas, the creatives are bored with them.

These days, many digital agencies won’t touch banners. They relegate banner work to a production ghetto, churning them out when they have to, and apologizing to the creatives forced to touch such dismal fare. They blame the format for the lack of satisfying creativity instead of looking at themselves.

Hey, don’t get me wrong: I agree that banners, as a format, are terrible. I want online display ads to die as much as the next normal, sane human – and with them, their concepts.

There is a class of creative concept that belongs in a banner/widget, if anywhere at all. Most of the iPhone apps spit out by brands belong in that class. Transposing formats is a distraction. Sleight of hand. Another paycheck.

The Mastercard app shows the warm reception from the public.

Would so many agencies pitch iPhone apps if their compensation was usage-based? I don’t mean downloads, either. I mean repeat launches, with the first dozen per device being free.

A Mantra

Ad world creatives and strategists, repeat after me: My iPhone app idea sucks. It belongs in a banner. Leveraging the accelerometer, magnetometer or location API doesn’t change that.

If you’re the exception, I’ll buy you a pint. Of gold.

Brand App User Scenario

To those who will pitch their dumb ideas despite my sage advice, I offer a token of friendship: your primary user scenario.

The user will follow these ten steps.

1. Hear about the application.
2. Search App Store or come in via link.
3. Click install, wait for download.
4. Plug in phone.
5. Sync. Take nap while backup and sync complete.
6. Find the app on the many screens of icons.
7. Launch it.
8. Close it.
9. Delete it.
10. One star.

Ouch. I’m sure you’ll win an industry award, though.

According to AdMob, a large portion of iPhone and iPod Touch users claim to use their mobile devices to browse the web more often than they use their desktop or laptop computers. This number is undoubtedly going to grow.

Combine that with an article in AdAge this week examining the problems with Google’s AdSense for Mobile product, and you see the current, expanding dark period for users (victims?) of mobile ads.

Mix in Noah Brier’s thoughts on Google as a market leader and we see a larger risk: if Google ignores UX right now and users acclimate, nobody will have the weight to course-correct where the experience is concerned.

Admittedly, my opinion is that mobile advertising should shrivel up and die. That said, if it’s going to exist, the UX should be at least tolerable and, preferably, stellar.

This is the kind of problem that arises when engineers don’t obsess over UX.

Mobile users are often on the move while interacting with their devices. By definition, their environments change almost constantly and often introduce unforeseen obstacles. Mobile conditions can place limits on many user attributes: focus, input precision, network connectivity, available time, personal space, and patience. Yet mobile devices are becoming as robust and powerful as laptops, inspiring tons of new, high-end functionality. The challenge is to reconcile the two factors, creating a helpful user experience that uses the new tech to the benefit of the largest number of users and the detriment of none.

User-centered designers face some interesting questions: How do you design an interface that allows someone to find directions or call a cab while carrying bags of groceries home from the market? How can an interface accommodate limited agility, gloved hands, a jostling subway train, or fat fingers? How do you let users subtly compose, edit, and erase email messages while in a long, boring meeting? (Hint: shake-to-edit or shake-to-delete or shake-to-anything are not very friendly requirements.) How do you model user behavior when the nature of mobile use is unpredictable and endlessly diverse? How can you solve problems as unobtrusively as possible?

I hear questions like these very often these days. Designers and developers who never paid much attention to the usability of their web or desktop applications are suddenly quite concerned about the UX of their mobile applications and mobile-optimized sites. I welcome the new interest in the topic, as I’ve always been a bit UX-obsessed, but I have to wonder about the inspiration. I think I’m witnessing a new empathy for users and a shift from the assumption that users crave every complex, novel, “innovative” idea a designer can throw at them.

Progressive Enhancement to the Rescue

One of the topics covered in my iPhone book is progressive enhancement. For those unfamiliar with progressive enhancement, it is the art of providing baseline value to all users and additional value to those in favorable environments or with extra abilities. A strong, accessible functional baseline is important for all software products and interfaces because we want our products to be user-centric.

Progressive enhancement patterns are familiar to a lot of web designers. I think a lot of folks kind of fudge the topic, though. They meet their stated requirements (such as 508 compliance), but often ignore the art. They provide baseline functionality, but they make it clear it’s only baseline. They passively penalize the audience that can only meet the minimum requirements and focus all elegance, fun, and inspiration on the most capable users.

Building Empathy Through Adversity

I think the growing importance of mobile devices in our everyday lives can give a new perspective on baseline users, perhaps leading to more time spent providing amazing, elegant assistive applications and reducing the importance placed on gimmicks.

Think about it: these days, we are all mobile users. As such, we all face adverse conditions for use. Suddenly, we all understand what it’s like to have external conditions impose limitations on our abilities. We are all handicapped in one subtle way or another as we go about our day. All it takes is a taste of frustration to ignite passion for assistive interfaces.

The applications we truly appreciate in the mobile space are those that enable us to accomplish our tasks no matter what our environment. We can compose emails in the absence of a network connection–they simply send when we are back online. The better Twitter clients and RSS readers store data on the iPhone to provide some value when users aren’t online. The better interfaces allow us to perform tasks with one free finger and minimal attention. They don’t impose gestural abilities on tasks for the sake of novelty. Or, if they do, they treat the novel interaction as an enhancement, allowing us to accomplish the same goals with the tap of a button.

In interactive design, including software and web design, progressive enhancement is often treated as an annoying requirement. Designers can now tap into their own experience using mobile devices to better empathize with users who lack full control of their environment, tools, and body, leading to a new respect for baselines and a shift in attention from the secondary enhancements to the primary use cases.

Most folks will eagerly update their devices as the new OS is truly stellar.

Many applications will be updated to take advantage of new features like the Push Notification Service, In-App Purchases, and Bluetooth-powered Private Area Networking (with GameKit).

I can’t wait to watch the Twitter chatter.

See, I’m obsessed with UX – especially on the iPhone. I get bent out of shape about ugly applications, hijacked gestures, disruptive branding and flippant differentiation. I fully acknowledge the delicate bubble Apple has created in the form of the iPhone UX, and I hate to see folks pushing blindly at the edges. The aesthetic and experience are what really differentiate the platform from similar devices, and it’s worth maintaining.

Cocoa Touch developers, like Cocoa developers, spend a lot of time thinking about user experience. With Cocoa Touch, there is an additional onus on folks to think about the experience outside their application because the device has limited resources: memory, CPU, battery life. Mobile users also have more limitations than desktop users: attention, coordination, time, tolerance, physical ability.

With iPhone OS 3.0, I am especially worried about the Push Notification Service and its potential for misuse, abuse, and overuse. Without consistency in the meaning of push messages, we might collectively burn users out on notifications.

Notification Misuse: Audio and Text Alerts

Developers can use the push service to send three types of notices to devices: short audio events, strings of text, and a number shown in a red circle (aka badge) on the application icon. Each of these has a place, and Apple cautions developers against using notification mechanisms that are disproportionate to the importance of messages.

For example, you should avoid sending audio alerts unless users are in the application context (that is, the application is running and users are interacting solely with it) and have opted into receiving audio. Nobody wants their phone to chirp away with random noise when they’re trying to listen to music or play a game.

Text alerts can be used to communicate very important events, but they too should be used with care. Text alerts trigger a full-screen, modal alert box that not only steals the focus of the entire phone but requires users to dismiss the alert by tapping a button. It’s pretty cocky to hijack an iPhone for a trivial note, so make sure the message is worthy.

Notification Abuse: Audio and Text Alerts

Don’t flood devices with flippant text or audio push notifications. Understand the disruptive impact of those messages and avoid them unless they are absolutely necessary. And repeat this mantra: “Push notifications are rarely necessary!”

Consider an asynchronous chat service in a social application. It might be awesome to use the push service to send messages to users, SMS-style, even when the app isn’t running. Now mix into the equation the presence of other applications. Most of us have at least two social apps on our iPhones. Suddenly, modal alert messages are popping up for each of them. God forbid you have multiple Twitter clients installed that send alerts for direct messages – redundant popups flooding in would be pretty annoying.

Don’t fall into the “I can, so I should!” mindset. Applications have worked well without notifications thus far. You won’t increase stickiness by pushing notifications to users, catching their attention and helping your icon stand out on the screen. Stickiness is a terrible concept carried over from the ad-driven web and is the banner under which advertising ruined online UX. Even if your application is ad-supported, your best bet for success is to create a tool that fits into the whole iPhone experience rather than trying to use every feature available to you in hopes of standing out. Beat your competition by doing less, better. Don’t steal focus. Earn it.

Notification Overuse: Badges

You should also avoid overuse of icon badging. Think about mobile development holistically. Every badge added to an application icon impacts the overall user experience. It’s your duty (yes, duty) to play nicely and work with the iPhone developer community to create a strong experience. You are not an island. Your app is nothing without the experience provided by Apple, and that experience must be ruthlessly maintained. Your application is a guest on a very expensive, aspirational fetish device. Don’t trash the place, lest you be trashed.

Badge Blindness

So why should badging be limited? Overuse of badging will lead to badge blindness. Badge blindness occurs when users lose faith in the importance of icon badges. RSS readers provide a really great example of this phenomenon.

Imagine you subscribe to 50 feeds – a modest number – and have your feed reader set to poll for updates every hour. If your reader shows a badge that reflects the current number of unread stories in your collection of feeds, you can almost guarantee that you will always have a badge present. Often, it will have a very large number inside. You will never reach zero, and the badge will never disappear. The badge becomes a permabadge – an annoyingly persistent reminder that the application wants your attention. You will probably declare RSS bankruptcy – marking all feed items as read – just to get the satisfaction of seeing the badge disappear… for less than an hour.

Imagine that, on the Mac desktop, several applications in your Dock show badges. Mail, iChat, NetNewsWire, iCal, and Xcode. Suddenly, you don’t feel as though your computer is trying to direct your attention towards an important, but non-critical, focal point. Instead, you feel as though your computer is constantly nagging you.

Now picture the equivalent on your iPhone. A screen of greedy little icons, all raising their hands wildly, begging for attention. You’ll start to ignore the mechanism. You’ll stop seeing the badges.

You’ll delete the annoying apps and leave one-star reviews on the App Store.

Advice

Imagine you’re in a crowded coffee shop. A friend is across the room, reading a book, or chatting with a crush. You think of something you think they may, possibly, maybe want to know. Would you shout the message out across the room? Wave your arms wildly, hoping they make eye contact? Send them a text? Email them? Leave a note with their server?

Whatever your message, make sure the transmission protocol is suitable. In some cases, this will mean badging. When badging, make sure the badge will be invisible more often than not, or it will lose its impact. If the message merits completely stealing focus, send a text alert or sound. Do so only in the rarest of cases, unless users have opted-in and can just as easily opt-out. Be nice. Don’t pop any bubbles.

For those not in the know, Twitter uses an incrementing integer as an identifier for each message on the site. On June 12, 2009, a message crossed the maximum integer value that could be stored in a 32-bit signed integer (2,147,483,647).

All messages created after that moment had integer values that would overflow the space allocated to the id.

This wasn’t a problem on Twitter.com. They’re surely on some rockin’ 64-bit systems and are continuing along as always.

The problem is with third-party applications using their API. When an application requests a list of status messages from Twitter, it receives the data in a format like XML or JSON. All values are stored as strings in those formats.

When the response is parsed, the string representing the status message id will be converted to a number. Applications that still use signed 32-bit integers will not be able to properly convert the string to an integer and will probably crash.

This problem is hitting a few Cocoa Touch applications. Tweetie seems immune, but the current release of Twitterrific and the in-beta Birdfeed both suffer. This is through no fault of either Craig Hockenberry or Buzz Andersen, though.

Buzz’s app, Birdfeed, is still in beta. Those of us testing it understand that beta means beta. He’s cracking on a fix now.

Craig preemptively fixed his issue well in advance, but – as I understand it – Apple is sitting on it instead of pushing it into the App Store.

This is just one of many ways Apple continues to please developers endlessly with their transparent, fair, open distribution channel.

Lots of folks want to blame Twitter, or shift some of the blame to them.

This is not a Twitter problem. They adapted their system and encouraged developers who use the Twitter API to remain in parity.

It’s probably true that Twitter could have made a bigger deal of the issue, but I think they did a solid job of keeping people informed.

Most people had ample time to update their code, and many of them did.

Daniel Jalkut suggested that Twitter might have provided an endpoint for the API that simulated large integer values, so application developers could test against the newer ids. I heard similar statements by folks attending WWDC.

I think this exposes a slightly dirty secret in the Cocoa world: most Cocoa and Cocoa Touch devs avoid automated testing. Unit tests are few and far between. From what I hear, Apple doesn’t even enforce units.

When you see regression bugs in Cocoa apps, you can assume the issue is in a lacking test suite.

The Cocoa community should learn two things from the Twitocalypse:

1. Write your units.
2. Submit to the App Store at least time * infinity in advance.

I’m about 50% on having test suites in my (admittedly, unreleased) iPhone apps. The half that have tests have strong coverage, though. Those that don’t are from the early SDK days, when the only way to test was with the Google Toolkit.

Wow, long time no write… Typical of me.

I’m wrapping up my newest tech book. Programming the iPhone User Experience will be released by O’Reilly this July.

I spoke at the Web 2.0 Expo (SF) this year on the subject of iPhone UX Anti-Patterns. It was the highest-rated mobile session. Great validation, and I think it’ll go a long way towards squelching the desire to jump off a building every time I have to get on stage.

After the book wraps, I hope to write more often here, on InsideRIA, and for other publications.

Or, I may just drink a lot and lay around.

Though I’m a recent convert to rSpec for my Merb work, I actually prefer to unit test Objective-C with OCUnit. I think it’s just part of that prejudice that tests should be written in the language of the app. Also, the more ‘natural’ it feels to write tests, the more likely folks will do so. In my experience, a great number of Obj-C developers have no interest in writing tests in the first place…

Still, rbiphonetest seems like a great project and I imagine several of the “pure” Web developers on my team who are itching to get into Objective-C will quite enjoy a familiar testing framework.

I found a Google project that looks promising, but haven’t looked into it.

Do my footwork for me!

Coding blind (no tests) is causing my ulcer to flare up.