It was around the same time that his Verizon Wireless contract expired and he finally got an iPhone. He started scouring the App Store. "I realized there are no good Twitter apps," he recalls. "But there are a billion bad ones." He figured he could probably write a better app. "What triggered me to do it? I was playing with Twitterific, which I used, and everybody used. I thought: I wonder why the scrolling is so slow? I wonder if I can make it faster." In an hour, he had built a prototype of a list of fast-scrolling tweets. Then, after a two-week paroxysm of coding, he had built Tweetie, shown in Figure 1-1, which is as of this writing the most popular mobile Twitter client on any platform, and the most popular Twitter app for iPhone.

Brichter attributes Tweetie's meteoric rise in popularity to a cocktail of luck, quality programming, and some well-timed publicity. But what really lives at the core of his success—and Tweetie's—is an absolute intolerance for mediocrity. "I have a shit-list of Twitter apps that just drive me insane," he says. "Apple lays out all these guidelines and conventions about how to write an iPhone app, and these developers basically looked at them and did the exact opposite in every single case."

He's not looking for perfection, however—just parsimony. If it's one concept of design and interaction that gets Brichter excited, it's economy of energy, be it in actual usage scenarios or in software development. Ask him what aggravated him about the existing selection of Twitter apps back in November of 2008, when he wrote Tweetie, and he doesn't talk about their ugliness or their complexity. Even the slowness that bugged him in Twitterific is merely a symptom of flawed thinking. "The problem isn't with how the other apps used Twitter's API, it's with the way they interacted with the iPhone OS," he says. "Either they were doing something completely custom, or completely wrong." His antipathy wasn't even aimed at Twitterific, though it was the immediate catalyst for Tweetie. "To tell you the truth, I didn't have a lot of beef with Twitterific," he says. "They were the ADA winner from the year before, and everyone loved the app. It just didn't jibe with the way I used Twitter."

It's not that Brichter is a loyal Apple devotee, either; he has beef with plenty of the native apps. "On the SMS app, the 'Send' button is right next to the keyboard," he quibbles, "so you hit it accidentally. There's no reason they couldn't have put it up in the nav bar." Mail too was a cautionary tale for Tweetie. "Everything in Mail is twice as many taps [as with Tweetie]. You have the account list, then the folder list, and then you get into the message list," he says. "I want to be able to go into an inbox with one tap, not two or three." (Figure 1-2 shows the first tweet feed prototype; Figure 1-3 shows a second iteration.)

Figure 1.2. The first Tweetie fast-scrolling prototype.

Figure 1.3. Another scrolling iteration, this one more iChat-inspired.

The atebits way of using something, distilled, is the pursuit the path of least resistance. "I got lucky, because the way I originally wrote Tweetie made sense in terms of how you should interact with a Twitter app," he says. His idea of how a user "should" use Twitter is based the navigation Apple Mail, made better: each tap in a tweet's menu pushes you rightward into a deeper folder. That's how Tweetie manages to pack in Recent Tweets, Search @, Following, Followers, and Block/Unblock without a mess of buttons or oddball menus. "It doesn't seem complicated—that's how every Twitter app should work," he says. "But yet that's not how Twitter apps work."

The most popular functions aren't made available through more buttons, or more menus—just swipe, as if you're deleting an email or a text, and you have the ability to star, @reply, or see the profile of the user whose tweet you're investigating (though you can also do this by clicking a tweet, if you're not aware of the shortcut). "My philosophy was: don't fight the framework," he says. "UI Kit APIs are so insanely beautiful that you can pick them up super-fast, even if you don't know how to program. It provides all this awesome functionality, but all these other apps do things their own custom way. But if you just embrace the UI Kit philosophy, you can build an app like Tweetie really fast." (Figure 1-1 shows the swipe shortcut.)

Easy for the ex-Apple iPhone wonk to say, right? Well, sort of. "At Apple I didn't do any app stuff except some performance tuning for other teams—making apps faster, doing some fancy looking transitions. I didn't really have any app building experience at all, so when I sat down to start writing Tweetie, I was learning the process from scratch."

While Brichter might have a thing for parsimony, the fine-tuning he did during his year at Apple is readily apparent in both Tweetie and Scribbles in a handful of beautiful actions. Make a command—a new document or tweet, or the preferences pane—and the window slips out from under the menu bar with a flourish, in a kind of reverse-genie effect inspired by the dock. Things in both apps move uncannily fast; even on a dual-core Macs where waiting is a rarity, the file browser practically rockets out of a tweet's title bar. Atebits apps are compact, purpose-built and deceptively robust, like race-tuned Mini Coopers of the Cocoa realm. (Figure 1-4 shows a tweet in the making, using Tweetie for Mac.)

Figure 1.4. Tweetie for Mac, which uses the same codebase as Tweetie 2 for iPhone, contains subtle, rapid animations.

Economy of design is often accompanied by minimalism, and Brichter's work style is fittingly Spartan. He doesn't use Interface Builder; all of Tweetie versions 1 and 2 were built programmatically in Xcode. And unlike most of the Mac developers in this book, uses just one machine and just one screen. "A few months ago I got a 17-inch MacBook Pro, and my Mac Pro has been in storage ever since," he says. It took Brichter just five days of coding to build the Twitter-iPhone core inside Tweetie 1, a few days doing the user interface, and a few more in the hands of beta testers; the whole app weighed in at 30,000 lines of code.

It is perhaps because of Twitter's straightforwardness that Brichter's Tweetie project makes for such an excellent example for developers. Unlike most apps, Tweetie has the benefit (and the onus) of an extant paradigm: the Web version of Twitter The extent to which Tweetie (or any Twitter iPhone app) succeeds is based largely on one question: how much additional cognitive load will it take me to use Twitter using this app instead of the Web?

To give Tweetie parity with the Web experience, Brichter first built in all the features an average user would want, but he didn't stop there; he lets power-users navigate reply chains, upload pictures to Twitpic.com, view trends, do searches, search nearby users using the phone's A-GPS, and even built a bookmarklet that users can deploy in mobile Safari to send links to Tweetie. In 1.2, the first major feature update of release, he added Instapaper support, landscape keyboard, image compression control for Twitpic uploads, those Mail-like swipe shortcuts, stock quote links, and the ability to forward direct messages to email (for more on Instapaper, see Chapter 13). If you're a Twitter Web user, you know that a whole lot of those features don't even appear anywhere on Twitter itself.

So features he had in spades—but having tons of features is often anathema to usability. Since it was Twitterific's slow scrolling that compelled him to build Tweetie in the first place, Brichter first set out to invent a new way the iPhone rendered its table cells. Most apps—in accordance Apple's own tutorials—force the phone to render a morass of subviews of labels and images, but Brichter's code pre-blends everything together using CoreGraphics. Once it renders that first frame, it hands one opaque static view over to CoreAnimation without the need to rely on the GPU to do any blending Brichter was so convinced that his fast-scrolling code was superior to Apple's that he posted a tutorial on his web site, where he makes his case: "If you think about what is happening in terms of overdraw, having one big view per table cell is a big win, because CoreAnimation will only touch a single given pixel on the screen once rather than multiple times (potentially, depending on how much overlap your old view hierarchy had)," he wrote.^[1]

As with Tweetie, Brichter's sample project relies on just one class of object for everything: ABTableViewCell.h and ABTableViewCell.m. In Listing 1-1, he creates a sample list of words with a first- and last-name field in two separate fonts as in the Contacts app.

//
//  FirstLastExampleTableViewCell.m
//  FastScrolling
//
//  Created by Loren Brichter on 12/9/08.
//  Copyright 2008 atebits. All rights reserved.
//

#import "FirstLastExampleTableViewCell.h"

@implementation FirstLastExampleTableViewCell

@synthesize firstText;
@synthesize lastText;

static UIFont *firstTextFont = nil;
static UIFont *lastTextFont = nil;

+ (void)initialize
{
        if(self == [FirstLastExampleTableViewCell class])
        {
                firstTextFont = [[UIFont systemFontOfSize:20] retain];
                lastTextFont = [[UIFont boldSystemFontOfSize:20] retain;
                // this is a good spot to load any graphics you might be drawing in -drawContentView:
                // just load them and retain them here (ONLY if they're small enough that you don't care about them wasting memory)
                // the idea is to do as LITTLE work (e.g. allocations) in -drawContentView: as possible
        }
}

- (void)dealloc
{
        [firstText release];
        [lastText release];
    [super dealloc];
}

// the reason I don't synthesize setters for 'firstText' and 'lastText' is because I need to
// call -setNeedsDisplay when they change

- (void)setFirstText:(NSString *)s
{
        [firstText release];
        firstText = [s copy];
        [self setNeedsDisplay];
}

- (void)setLastText:(NSString *)s
{
        [lastText release];
        lastText = [s copy];
        [self setNeedsDisplay];
}

- (void)drawContentView:(CGRect)r
{
        CGContextRef context = UIGraphicsGetCurrentContext();

        UIColor *backgroundColor = [UIColor whiteColor];
        UIColor *textColor = [UIColor blackColor];

        if(self.selected)

{
                backgroundColor = [UIColor clearColor];
                textColor = [UIColor whiteColor];
        }

        [backgroundColor set];
        CGContextFillRect(context, r);

        CGPoint p;
        p.x = 12;
        p.y = 9;

        [textColor set];
        CGSize s = [firstText drawAtPoint:p withFont:firstTextFont];

        p.x += s.width + 6; // space between words
        [lastText drawAtPoint:p withFont:lastTextFont];
}

@end

ABTableViewCell.m reads:

#import "ABTableViewCell.h"

@interface ABTableViewCellView : UIView
@end

@implementation ABTableViewCellView

- (void)drawRect:(CGRect)r
{
        [(ABTableViewCell *)[self superview] drawContentView:r];
}

@end



@implementation ABTableViewCell


ABTableViewCell.h reads:

#import <UIKit/UIKit.h>

// to use: subclass ABTableViewCell and implement -drawContentView:

@interface ABTableViewCell : UITableViewCell
{
        UIView *contentView;
}

- (void)drawContentView:(CGRect)r; // subclasses should implement

@end

RootConroller.m reads:

//
//  RootViewController.m
//  FastScrolling
//
//  Created by Loren Brichter on 12/9/08.
//  Copyright atebits 2008. All rights reserved.
//

#import "RootViewController.h"
#import "FastScrollingAppDelegate.h"
#import "FirstLastExampleTableViewCell.h"

@implementation RootViewController

- (void)viewDidLoad
{
        self.title = @"Fast Scrolling Example";
    [super viewDidLoad];
}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    return 100;
}

static NSString *randomWords[] = {
@"Hello",
@"World",
@"Some",
@"Random",
@"Words",
@"Blarg",
@"Poop",
@"Something",
@"Zoom zoom",
@"Beeeep",
};

#define N_RANDOM_WORDS (sizeof(randomWords)/sizeof(NSString *))

- (UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
       static NSString *CellIdentifier = @"Cell";

       FirstLastExampleTableViewCell *cell = (FirstLastExampleTableViewCell
*)[tableView dequeueReusableCellWithIdentifier:CellIdentifier];
        if(cell == nil)
        {
                cell = [[[FirstLastExampleTableViewCell alloc]
initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
        }

        cell.firstText = randomWords[indexPath.row % N_RANDOM_WORDS];
        cell.lastText = randomWords[(indexPath.row+1) % N_RANDOM_WORDS];

return cell;
}


- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
        [tableView deselectRowAtIndexPath:indexPath animated:YES];
}

@end

In July 2009, almost eight months after Brichter posted his tutorial on the atebits blog, Apple updated their iPhone Reference Library to include his method as one of the suggested scrolling solutions, though as Brichter points out, it's the last suggested example as of this writing.^[2]

Tweetie's scrolling, which Brichter is fond of calling "ridiculously fast," is technically a bug, because it doesn't save state between launches. And because of its speed, it conceals the true memory load the app presents the iPhone OS. "You'd be surprised—when you think of all the avatars you're loading while you're scrolling by, those take up memory," he says. Thanks to Shark and Instruments, memory management wasn't a burden, he says, but there's another lurking problem in Tweetie: its inline browser. "The biggest pain in the ass of iPhone development is using UIWebView," he says, "because that thing just sucks up memory like crazy." On 2G and 3G iPhones, he says, the browser taxes the phone so much that the OS frequently kills it, crashing the app. "You've gotta give Apple some credit, because they're doing something complex," he says of in-app browsing. "But it's the single biggest headache I ran into."

Twitter's API, while "quirky," didn't give him too much trouble, Brichter says, yet that didn't stop him from re-engineering the entire app during the development of Tweetie 2. "When I wrote Tweetie 1, I got a lot right, but I also got a lot wrong. At the UI level, there was a list of nit-picks that I had to address," he says. "But it was really just the code was a mess: I reimplemented stuff a few times." One example: because the regular Twitter API for retrieving tweets is different than the API for searching tweets, Brichter says he ended up with a lot of duplicated code behind the scenes. Building Tweetie for Mac, which he launched in spring of 2009 and is $19.95 through the atebits web site, he recoded the bulk of the app, which he subsequently began modifying to for use in Tweetie 2. He calls the new codebase BigBird. "Now it's all unified and pretty," he says.

But Brichter doesn't characterize Tweetie 2 as the progeny of Tweetie for the desktop—in fact, it's actually the iPhone version that fathered the desktop iteration. As he told a Stanford University undergraduate computer science class in May 2009, just before winning an Apple Design Award, he actually mimicked the iPhone's UITableView controller on the Mac. "Once you feel the philosophy of [iPhone] view controllers flow through you, it's this really beautiful concept," he told the class. They chuckled at his sincerity, but remained rapt as he described something he calls ABTableViewController, the manifestation of his iPhone philosophy ported to Mac. Double-click on a tweet in Tweetie for Mac, and you see a tab view controller at work, as well as a sub-view controller, all of which are operating inside of a navigation controller. "It's this idea that you can have a ton of info and be able to delve into it without having to scroll across your screen," he told the class. "When you're looking at a tweet, you see the tweet details beneath. If you want to see user details, rather than sliding over to another screen—which would just be another view controller pushed onto the navigation controller stack—there's a little button that will slide down the tweet and reveal the information beneath it. But those are actually two separate view controllers," he says. "I have view controllers within view controllers within view controllers within navigation controllers." The result, he says, is a "beautiful hierarchy" that allows you to eschew the usual logic of presentation. The other result, of course, is a Twitter app that lives in a fraction of the screen space of TweetDeck and other popular desktop apps and flows through each of its functions with minimal buttons and menus.

Brichter says that Tweetie has taken over his life in the last year; he's still pulling 100-hour weeks developing updates and new versions. Still, there's a good reason he has the luxury of flying out to Stanford to guest lecture: he has spent almost no time doing marketing, and yet the sales keep rolling in.

The story of Tweetie's no-marketing marketing start with quality of the app itself. His sales began to climb at first only because of word of mouth—he had indeed succeeded in making something better than Twitterific, Twittelator, and Twitterfon, and word spread quickly (even though he says that in hindsight, his foray into the crowded Twitter iPhone app space was "batshit-insane." He also tweeted about the app to find beta testers, and when the first release dropped he had a ready audience who could retweet the announcement. After that, he added something he jokingly called "Popularity Enhancers," or project "PEE." It added fart sounds and a flashlight to Tweetie: features "meant to make fun of the App Store," he says. He also added a page to the atebits web site touting PEE with what can only be called unconventional salesmanship.^[3] (Figures 1-5 and 1-6 show images he added to atebits.com to promote PEE.)

PEE is a collection of ever-growing technologies scientifically designed to enhance the size of that certain something ... you guessed it: App Store sales!

Teams from around the globe have analyzed figures and come up with a secret formula for App Store success. I share these findings today, ABSOLUTELY FREE. Success is made up of: a FLASHLIGHT... and DIRTY WET FART SOUNDS!!!

Tweetie, the only app that bundles together these two incredible features FOR THE VERY FIRST TIME. Accept no imitations. Why buy a dedicated fart app AND a flashlight, when you can have BOTH, and get a TWITTER CLIENT along with it! Read on for more details...."

Figure 1.5. A screenshot Brichter added to atebits' PEE web site.

Figure 1.6. Brichter's personification of Tweetie with PEE enabled, as pictured on atebits' PEE web site.

Tech news sites like ArsTechnica picked up the PEE features; sales quintupled day-over-day. Then Apple decided to feature the app on its iTunes Store's opening screen. Even more sales. Then Apple did Brichter another favor: they rejected Tweetie update 1.3.

This wasn't Brichter's first rejection: they had rejected his initial submission because he used the open-book bookmarks icon as a "favorites" icon used to save searches. That was an easy fix: he changed the open-book icon to a star. The second rejection was more puzzling. At the time he submitted the update, one of the trending terms on Twitter was the "f*ckit list." Brichter says, "Apple saw the trending term, and they were like, 'No you can't have curse words in the app'." Others people picked up the rejection when Brichter tweeted about it, and sales of the app skyrocketed—even though the updated version in question wasn't in the app store yet. Brichter says that Apple acknowledged the error in judgment and resolved the issue within a day, but the publicity stuck and sales kept climbing. To date, Tweetie has reached as high as number six on Apple's overall list of paid apps, and has topped the social networking category. Brichter says he's not comfortable sharing revenue numbers, but sufficed to say it has made atebits a very, very viable company. (Figure 1-7 shows the relative sales boosts of each of Brichter's marketing events.)

The parts of Tweetie's marketing that Brichter actually orchestrated on purpose—project PEE, his announcement tweets—are examples of how economical thinking can keep a lone developer from over-extending himself. Instead of launching a web campaign or trying to contact journalists, Brichter simply did what he knew how to do: he wrote more Objective-C, and tried to make Tweetie more fun. When he wanted to get the word out, he found his audience where he knew they'd be: on Twitter. He didn't bother wasting time becoming an impromptu expert on app marketing; it just didn't promise much of a return. He let the journalists do their job by discovering him, and let the customers do what they like doing: suggest a cool new app to their friends. When sales began booming and Brichter began getting hundreds of emails a day on his customer service account, he responded similarly: he outsourced it to an Arizona-based software engineer named Ash Ponders.

The second installment of Brichter's no-marketing campaign, the Apple rejection, allowed him to benefit from a curious phenomenon: iPhone owners rebelling against the App Store by buying something as a show of solidarity through the App Store. So fickle and unpredictable has the app approval process become that users jumped at the opportunity to show support for an app they thought didn't get its fair shake. If there were an allegory for iPhone users' simultaneous love and hatred for their devices, the Tweetie rejection drew it out: iPhone owners love their devices, and few will stand idly by while a BlackBerry or Android fanboy tries to overstate its flaws. But they also feel suckered by AT&T, the U.S. iPhone service provider whose coverage and call-quality on the iPhone is famously unreliable, and by Apple, which sometimes acts paternalistic in their content-censoring. In the beginning, Apple was pickier about accepting only apps with consistent usability standards. "Now they're just rejecting stuff that's ridiculous—they rejected a dictionary app because there are curse words in it. They're rejecting all the wrong things," Brichter says. Still, plenty of Tweetie's less-capable competition slipped right through the process, even though they didn't follow any of Apple's interaction standards. "I guess Apple lightened up [on usability] because they realized people suck at UI and user experience," he theorizes. "I guess they wanted the numbers in the App Store; they wanted to be able to claim they had 50,000 apps, and they realized if they cracked down on crappy UI they wouldn't have those numbers."

Figure 1.7. Apple's rejection of Tweetie 1.3 provided one of Brichter's biggest sales boosts.

Though Brichter says he didn't give Tweetie's pricing much thought ("I put work into this app, I may as well charge money for it," he says), he has received a powerful and profitable lesson in the economics of the App Store. "I think Apple was smart setting the limit at 99 cents, otherwise we'd have bidding down to like 5 cents or 10 cents for an app," he says. But by pricing his app at $2.99, instead of the one-dollar standard, Brichter is an example to developers that an app doesn't need to be bargain-bin cheap or free to make it into the top 10 list. "Honestly I think the right price depends on the app; there are certain kinds of apps that target the cheapo's. But who's your market? People with iPhones—people are spending tons of money on iPhones. The vast majority of those people have the extra money that they can spend 2 or 3 bucks on an app," he says.

Brichter's $2.99 price-point may also imply higher quality to shoppers. Since there's no way to preview or demo apps on the app store before buying, price may have become a valuable clue to worthiness; few developers would have the guts to put out a $2.99 app unless they expected five-star reviews. "I thought $2.99 was also within the range of impulse buy for most people. There wasn't really too much else out there competing with it, so people picked up on it," Brichter says. Contrary to many developers on the iTunes Store, Brichter thought a free version would cannibalize sales; because he had developed Tweetie with so little overhead, he didn't need to make an immediate play for market share. "The fact that I didn't release a free lite version probably helped the sales of the paid version," he says. "I don't want to sound sleazy, but there are some percentage of users who would have downloaded the free version, said this is good enough, and even if they were willing to spend three dollars, they wouldn't have spent it."

The key to app-pricing psychology, Brichter thinks, is getting customers over the decision to buy. "I think the barrier between zero and one dollar is huge," he says, "and the barrier between 99 cents and $2.99 is relatively small." For all the talk of "downward pressure" on app prices in the iTunes Store, Brichter says that many developers are leaving money on the table by going as low as possible. He has even considered going higher. "I'm not sure what the limit is: five, six, seven bucks? Then again, you could buy lunch for that," he says.

Brichter spent about half a year building Tweetie 2 for iPhone, inventing a variety of iPhone OS 3.0 features and modifying the slick new Tweetie core from the desktop version. The new version of Tweetie allows for in-app email composition: you can copy an entire threaded direct message conversation into an email, formatted in rich HTML. It also uses MapKit to plot nearby tweets and users, runs in landscape mode, and supports full persistence.

Brichter is perfectly aware that his apps live and die by users' whimsy, so he has taken big risks to make Tweetie 2 a substantial improvement over its predecessor (shown in Figure 1-8). Unlike other iPhone apps, Twitter apps require very little informational investment from users. In apps like RunKeeper or iFitness, for example, users spend time logging their workouts; in Beejive, the instant-messaging app, they spend time adding accounts and buddies, and tweaking backgrounds or settings. But Twitter apps are comparatively plug-and-play. "There's no lock-in with Twitter clients," Brichter observes, "so if something comes out that's better, they'll use it. They just sign in and all their info is there." He's hoping that features like Tweetie's slick new navigation and hierarchy will keep users hooked, but all it takes is a sexier alternative to erode Tweetie's lead. "Tweetie is in a unique position where market share is meaningful," he says; since Twitter advertises which client a tweet comes from, the more mentions the better. Market share is so meaningful, in fact, that Brichter doesn't seem particularly concerned about piracy. Yes, there are copies of Tweetie on torrent sites, he concedes. "But that actually helps me because it increases Tweetie's user base."

Figure 1.8. Tweetie 2, pictured on the left, drastically re-imagines profile viewing.

Perhaps Tweetie 2's most drastic departure from Tweetie 1 is the dynamic navigation bar at the bottom of the screen. In versions 1.X, Tweetie's lower nav stayed anchored with all of "your stuff," as Brichter terms it, shown in Figure 1-1: tweets, mentions, messages, favorites, and the "more" button, all viewable in the home screen. In Tweetie 2, the bottom nav appears in several screens, but changes function; when you're viewing a user, the glossy black tabs change to apply to that user, no longer to your stuff. (Figure 1-9 shows the dynamic nav bar at work viewing one user's tweets.) Navigation is relegated to the top bar, which lets you dip in and out of directories.^[4] That leaves the top navigation buttons to handle navigation when drilling deeper (or backing out into the main screen). The navigation that appears at the top of the screen varies based on the tab selected in the bottom navigation bar. In that respect, Tweetie for Mac and Tweetie for iPhone now share a logic. But that logic is contrary to what most iPhone users are used to; in most apps, the bottom nav stays static no matter where you go in the app, and when clicked, take the user upwards in the current directory. Brichter explains his rationale below:

Figure 1.9. Tweetie 2's dynamic lower navigation bar, right, changes depending on what the user views. In Tweetie 1, the lower navigation bar doesn't exist outside the home screen.

If ever there were a word that encapsulated Twitter, "market share" would be it. The company has no revenue stream and no discernible plans for one, even as profitable cottage industries sprout up around it. IPhone apps are only one slice: on the Web, users can sign up for EasyTweets for marketing, Twuffer for future-scheduled tweeting, Twittervision for real-time mapping, Tweetree for keeping track of @replies, Twtpoll for surveys, FollowFormation for who-to-follow suggestions ... the list burgeons. Since its inception in 2006, Twitter's singular goal has been earning users and stifling competitors—even before there were competitors to stifle. The service has an easy and robust API, and has been sure to let user ship grow unfettered, without any of the controlled growth or moderation users associate with Facebook. For those reasons, it feels like a direct connection to the world—unmoderated, unmitigated. Social networks are corporate middlemen by comparison. In a country that has become enchanted by local-grown food, super-economical cars, minimalist netbooks and ultra-thin televisions, Twitter is the right kind of platform: light, pure, unobtrusive, simple, elegant and endlessly accessible from any computer, mobile phone, or smart device.

Those qualities have earned it billions of dollars of free advertising as cable news, magazines and newspapers examine its societal impact. "It's awesome for Twitter, because they're getting more users," Brichter says of the publicity, "and it's awesome for me, because more people are gonna buy Tweetie. But it's also stupid." Brichter isn't fond of the direction Twitter is taking; leaving it so unsupervised has opened the door for a brand commercialism and crassness that may be sinking MySpace, and which Facebook made its reputation by avoiding. "You have a billion people screaming inane stuff," he says, "and if you've looked at the recent trends, it's all Hollywood crap. I guess it's good for me, but at the same time I didn't build Tweetie for those people," he says. "I built it for people like me."

Ironically, Brichter says he likes Twitter for one of the very reasons that Tweetie's success is never safe: its easy-come, easy-go interactivity. "I don't like Facebook or MySpace or any of those general-purpose social networks," he says. " I don't need to be 'friends' with the people I know—most of the people I know, I don't have any interest in 'what they're doing,'" he laughs. Between his two Twitter accounts—one for Tweetie and one for atebits—he follows a total of about 100 people (though he has about 10,000 followers for atebits and about 20,000 for Tweetie). Despite his commanding body of followers, he says he writes an average of "less than one" tweet everyday. "Maybe one every couple days," he estimates. "I would rather follows someone that only posted something when it was interesting." Call it economy of divulgence. Luckily for Brichter, the rest of Tweetie's user ship hasn't heard of it.