★ The Fear

The NDA is dead, yes, and good riddance, but there remain serious problems with the way Apple is managing the App Store. It boggles my mind that there remain so many people who don’t see this. This piece by Dan Kimerling at TechCrunch is one example; various of the reader comments on Jason Snell’s piece for Macworld last week are another.1 One factor, perhaps, is the tendency to see everything in terms of extremes. Black or white, good or bad. But this debate is not about wanting Apple to make radical changes, such as, say, changing the iPhone from a closed platform to a more open platform a la Android. There are reasonable arguments to be made that a more open iPhone platform would be good not just for iPhone developers, but for Apple and its shareholders. But those arguments aren’t what this debate is about. This debate is about wanting Apple to make minor changes — a slight but very significant course correction. Put another way, this is not about the big picture scope of what kind of hypothetical App Store (or Stores, plural) Apple should have created. That train left the station long ago. This is about the specific details of the App Store that actually exists, and the rules that govern it. I believe that a closed, controlled App Store can work, but by definition that requires developers to place trust in Apple. The problem is that Apple is managing the App Store in certain untrustworthy ways. And I mean trust more in the sense of stability than honesty — like in the way you need to trust a ladder before you’ll climb it. Here is a complete list of what Apple must do to increase developers’ trust in the App Store system: State the rules. Follow the rules. That’s it. This is so clear that even those who are arguing the other side — that Apple’s App Store stewardship is just fine as it stands today — have jumped through hoops in an attempt to argue that Apple’s exclusion of Podcaster was in fact in accordance with the iPhone SDK Guidelines. Kimerling, in his “Stop Complaining About Apple and the App Store” piece, writes: When you create the platform, you set the rules. If Apple wants to restrict iPhone applications to those that do not compete with features built into the iPhone, well, they can go right ahead and do so. It is right in the SDK’s user agreement. That’s just not true. The iPhone SDK Agreement, at least by the standards of legal contracts, is written in clear, straightforward English. (Apple’s lawyers, in the opinion of yours truly at least, are good writers.) The rules it lays down are clear. And Podcaster doesn’t break any of them. Given any set of rules, there will always be edge cases. Judgment must be rendered, and, inevitably, some will feel edge cases were judged the wrong way. But the reason iPhone developers (and prospective iPhone developers) are appalled by Apple’s rejection of Podcaster and MailWrangler is that neither app was near any edge defined in the SDK guidelines. Podcaster was rejected for duplicating the podcast features in iTunes and the iPhone “iPod” app. MailWrangler was rejected on the following grounds: Your application duplicates the functionality of the built-in iPhone application Mail without providing sufficient differentiation or added functionality, which will lead to user confusion. The word “duplicate”, in any conjugation, does not appear in the iPhone SDK Agreement. Not a word about it. And there is clearly no general rule about third-party apps duplicating the functionality of the iPhone’s built-in apps. PCalc, along with a handful of other calculator apps, duplicates every single feature of the built-in Calculator app. There are dozens of note-taking apps that compete with Notes; MagicPad goes so far as to use the same icon as Apple’s Notes app, just with different colors. There is an entirely category in the App Store — an entire category — for weather apps, several of which “duplicate” the entire functionality of the built-in Weather app. So, not only judging by the rules set forth in the iPhone SDK Agreement, but also by the existence proof of hundreds of apps currently published in the App Store that duplicate (which is really to say compete with) built-in iPhone apps, no reasonable person would have expected Podcaster or MailWrangler to be rejected. So their rejection is problematic on three fronts. First, the submission process is such that an app rejected at the conceptual level — one that cannot be tweaked or fixed to gain entry upon resubmission, but whose fundamental premise is rejected by Apple — such an app is only rejected after it has been written. The developer does all of the work to produce the app and only then finds out it was all for naught. Second, there are clearly rules which are not listed in the SDK guidelines. Third, in its explanations for the rejections, Apple is not stating what these actual unpublished rules are, and is instead offering as the reason this “it duplicates a built-in app” rule which, given all the aforementioned counterexamples that have been accepted into the App Store, isn’t actually a rule at all. The explanation is clearly false. Taken together, these three factors lead to The Fear, which is that developers cannot trust the App Store process. You can spend all of the time and effort it takes to build an app, follow every known rule, and still get rejected. From Apple’s perspective, especially, say, in upper management, it may be all too easy to look at what’s going on with the store — thousands of published apps, a ton of money changing hands — and not see the problem. In the big picture, from both a technical and marketing perspective, the App Store is a grand success. The problem is that the apps that are the most interesting, the most important, are the ones that take the most work to create. And the apps that take the most work to create are the ones that are most likely not even to be made in this environment, because the risk is greater. The more work it takes to create an app, the more you lose if Apple rejects it. Going back to the ladder analogy, the higher you’re trying to climb, the more you need to trust the ladder before you start. It’s not about a handful of developers who’ve had their apps rejected. It’s about all the other developers who are now spooked, and that the ones who are the most spooked are the ones who harbor the grandest, boldest, most innovative ideas. Interpolation Regarding a Theory on Which Apps Apple Won’t Allow Developers to Compete With In the absence of revised iPhone SDK Agreement from Apple, we can attempt to guess what the unpublished rules are. With Podcaster, for example, the “follow the money” rule of thumb leads to the conclusion that Apple will not allow any competition with iTunes, because iTunes is a profit source. This is why MailWrangler’s rejection is the one that puts The Fear in my heart. As unjust as the Podcaster rejection appears, if Apple really wants to prohibit competition with iTunes, even anti-competitively, you can at least see the thinking behind the decision. It’s foolish and unnecessary — the fact that iTunes is wide open to total competition on both Mac OS X and Windows hasn’t hurt it at all — and it also quite possibly invites some sort of legal challenge, but at least there is a logical idea behind it. But Mail? Why on earth should Apple care if some third-party email client for the iPhone becomes wildly popular? It makes no sense. iPhone users who use the built-in Mail app don’t pay extra to do so. Mail doesn’t tie users to Apple’s own MobileMe service. In fact, Mail offers specific setup help to work with Gmail, the service MailWrangler is optimized for. If you can make a replacement for Notes and Weather and Calendar, why not Mail? I have a theory. It is more, well, emotional than logical. But it’s the only theory I can think of that makes any sense at all and fits the available evidence. The theory is that there is an unpublished rule that Apple — and in this case, where by “Apple” I really mean “Steven P. Jobs” — will not publish third-party apps that compete with or replace any of the four apps in the iPhone’s default “dock”: Phone, Mail, Safari, and iPod. Go back to Jobs’s original iPhone introduction at Macworld Expo 2007. It was a masterful presentation. Carmine Gallo, writing for BusinessWeek, calls it Jobs’s greatest presentation; I agree. Gallo describes the moment it was unveiled: After laying the groundwork, Jobs builds up to the new device by teasing the audience: “Today, we are introducing three revolutionary products. The first is a wide-screen iPod with touch controls. The second is a revolutionary new mobile phone. And the third is a breakthrough Internet communications device.” Jobs continues to build tension. He repeats the three devices several times then says, “Are you getting it? These are not three separate devices. This is one device … today Apple is going to reinvent the phone!” The crowd goes wild. This “three revolutionary products” pitch was inordinately effective. For one thing, live, in the hall, Jobs completely fooled the crowd, yours truly included. But then as he repeated the three product ideas over and over, while icons representing the three products rotated behind him on screen, faster and faster, it started dawning on us how we’d been tricked. By the time Jobs came out and said that it was just one device that encompassed all three products, everyone in Moscone West had come to that conclusion on their own — a nifty little way of making the crowd feel clever, as though we’d figured out a riddle. But this pitch also worked because it was true. All three of those products sound good on their own. All three in one device sounds insanely great. Jobs was introducing the iPhone simply by describing precisely what it was. A phone, a widescreen video iPod, and a breakthrough Internet communicator. The icons in the iPhone’s default dock represent the core functionality of the device. Phone, Email, Web, iPod. With nothing other than those four apps, the iPhone still would have been a hit. Not as great, but, still, great. Everything else the iPhone’s built-in apps do could be done, to some extent, through Safari: notes, calendars, weather, maps, stocks. There are a few minor exceptions. SMS is one example, but that’s really just an adjunct to the Phone app. Anything that relates to the phone network — voice or SMS — is unavailable through the third-party iPhone SDK anyway. You couldn’t write your own SMS app even if you wanted to. (Apple clearly has no problem with competing chat apps — there are several IM clients available in the App Store. That’s the same basic concept as SMS, but using IP networking.) And so my guess is that while there may not be any logic, there’s at least a notion, if only in Jobs’s mind, that these four apps are sacrosanct because they define the iPhone. Everything else, both from Apple and from App Store developers, is piffle, secondary to those four apps. Harry McCracken’s recent iPhone user survey indicates that iPhone users agree that those four apps comprise the most-used features of the iPhone. But the least essential of the four is Mail. You cannot place phone calls or play music and video from your personal iTunes library using a web browser, but can read and send email through it.2 Millions of people do just that every day, including, I’m sure, many of you reading this essay. And Google’s iPhone-optimized version of Gmail shows just how well it can be done. It’s not just good for web-based mail, it’s just good, period. And so this idea that Apple seems to have that Mail is particularly special is misguided. The Phone and iPod apps are special, because at a fundamental level they perform tasks that cannot be duplicated in a web app. But there’s nothing any more special about Mail than there is about, say, Calendar. Calendar, if anything, is more closely tied to Apple’s proprietary and commercial MobileMe service — Mail works great with any IMAP server, including Gmail, but Calendar only works for online syncing with MobileMe or Exchange. But Apple doesn’t seem to have any problem allowing Calendar competitors into the App Store. Notes Calendar is a $3 Lotus Notes calendaring client. Exchange Remote Calendar is a $10 is a $10 calendaring client for Exchange. If these are OK, why not a dedicated Gmail email client? The only explanation is that Mail is deemed untouchable and Calendar is not. The real test would be for someone to write a dedicated Google Calendar iPhone app — but given what happened to MailWrangler, it might be hard to find someone willing to try it. In short, my theory is that Mail is on the do-not-compete list not because there’s any strategic reason for Apple to do so, but simply because of a vague notion that Mail is one of the iPhone’s defining apps. This notion is wrong. Mail is important, but there’s nothing about it that needs to be protected from competition. End of Interpolation, Back to the Three Problems, Which, Due to the Grotesque Length of the Above Interpolation, I Will Remind You Are: (1) App Ideas Are Rejected Only After the Apps Are Actually Built; (2) There Exist Secret Unpublished Rules Regarding What Is Allowed; and (3) When Apps Are Rejected for Violating the Unpublished Rules, Apple Refuses to State Just What These Rules Are One thing that would make a difference would be a submission process whereby developers could submit their application ideas to Apple in advance, to find out if they’re OK. That’s how it works on game platforms from Nintendo, Sony, and Microsoft — developers submit a detailed proposal and wait until they get the green light before actually building the game. That sounds good, but there are problems with the idea. For developers, it would require an additional level of trust in Apple. Ideas are less valuable than actual implementations, but the more original an idea is, the less comfortable you are to share it. And for Apple, it would require significantly more work. They’d still need to examine and approve the actual shipping applications, but now they’d also have to examine and consider application proposals. The world’s hard drives are littered with abandoned unfinished software projects — there would surely be far more proposals submitted for consideration than there are actual iPhone applications. As it stands today, Apple is already struggling mightily to keep up with the work of approving new and updated application submissions — the typical turnaround time is between one to two weeks. Perhaps Apple could offer this as a service limited to ADC Select ($499) or even Premier ($3,499) members. The service is needed most by the developers who are considering the biggest apps, most of whom either are already paid ADC members or wouldn’t bat an eyelash at the cost of joining. It wouldn’t be democratic, but it might make it feasible. Platforms like Wii and Xbox ship maybe a few dozen titles a month, tops. The App Store has published 3,500 titles in just three months. (And it costs far more to join the developer programs for gaming consoles than the $100 iPhone SDK fee.) More important, though, is for Apple to address problems 2 and 3, by publishing in the iPhone SDK Agreement all of the rules they’re using to evaluate applications. If we’re not allowed to write email or podcast clients, say so. If something unforeseen comes up, Apple should make a decision, and then publish the new rule. Rules you disagree with are frustrating. Rules you don’t know about are scary. I will also note that, to my knowledge, not a single published iPhone developer has spoken out in favor of the App Store’s current rejection policies. Those developers who have spoken are against it. Those who see no problem are not themselves iPhone developers.�↩ Even if Apple were to come to its senses and allow third-party developers to write competing email clients, the built-in Mail app would hold one significant technical advantage, which is that it runs in the background. In fact, background processing is the one factor that unites the four dock apps. Phone, Mail, Safari, and iPod all continue running the background; no other apps, including those from Apple, do.�↩

• Daring Fireball on October 2, 2008
• More Details
• Related News

Will Google's Android Play DOS to Apple's iPhone?

Daniel Eran Dilger Today's broad array of smartphone operating system contenders are offering lots of potential answers to a problem that only requires one. It appears the market has two options ahead: either pool generic hardware makers behind a single operating system and deliver a smartphone marketplace that resembles the Windows PC market, or watch them fall to a dominant leader and have a smartphone market that resembles Apple's iPod ecosystem. This decision isn't going to be made by a class of intellectual elite, or by government mandate. it's going to be made by the market itself. Here are the factors that will influence the outcome, either marginalizing Apple's iPhone into a niche as the company has twice experienced previously at the hands of DOS in 1981 and Windows in 1991, or positioning it as the dominant leader as Apple has achieved for itself with the iPod since 2001. The third segment in this series looks at Google's Android and the Open Handset Alliance as a possible “DOS-attack” against Apple's iPhone. Subsequent segments will look at Nokia's newly opened Symbian and other mobile contenders challenging the iPhone. Will the iPhone Meet its Match from a Modern Day DOS? Will Windows Mobile Play DOS to Apple’s iPhone? Will Google's Android Play DOS to Apple's iPhone? Will Symbian Play DOS to Apple's iPhone? Google Acquires Android. In 2005, Google purchased a startup named Android, which had been in business for nearly two years. The secretive startup was known only to be working on software for mobile phones. It was being run by a who's who of mobile industry veterans, including Andy Rubin, the founder of Danger. Rubin had earlier worked at WebTV along with Chris White and Andy McFadden, both of whom had also joined Android. Richard Miner of Orange and Nick Sears of Tmobile also brought their mobile provider experience to Android. At the time of the acquisition, Google didn't announce any plans for Android and instead only told BusinessWeek, “We acquired Android because of the talented engineers and great technology. We're thrilled to have them here.” It appeared that Google was only going to be expanding its search services for mobile phone users, along the lines of the Google SMS answer system it had recently released. Google Buys Android for Its Mobile Arsenal - BusinessWeek Windows XP Media Center Edition vs Apple TV: The Fall of WebTV The GPhone Myth. As reports began to leak out about talks between Google and hardware makers throughout 2007, rumors began to fly about “the GPhone,” a competitive offering that was supposed to take on the iPhone. Some phone enthusiasts hoped Google would jump in to rescue the struggling OpenMoko project and turn it into a viable project that could attack Apple's new smartphone. In October 2007, I printed the Great Google GPhone Myth, taking apart the idea that Google would be directly competing against the iPhone, and describing that Google was really working on a free alternative to Windows Mobile as a conduit for getting its search and related services on a broader variety of mobiles. Google's services were already on the iPhone. In November, Google played its hand: it had organized a consortium of companies called the Open Handset Alliance to develop open standards for mobiles. The first product from the group would be Android, a mobile operating system built on the Linux kernel. Google wasn't getting into the phone handset business at all; it was only making sure that its mobile search products would not risk being marginalized by the threat of Windows Mobile on phones in the same way Microsoft had been working to leverage its PC monopoly to push Google search off the Windows desktop. The Great Google gPhone Myth Introducing Android: Leader of Linux. Two weeks later, Google released an early version of the Android software. On top of a Linux kernel, Android uses a specialized version of a Java Virtual Machine that takes Java language code and turns it into what Google calls “Dalvik bytecode” rather than Java bytecode as a standard JVM would. This allows Google to leverage existing and familiar Java language tools without paying Sun for a Java license. Like Mac OS X and its fraternal iPhone OS, Android includes a variety of open source libraries, including SQLite and WebKit. On top of that, Google developed a series of frameworks that handle the tasks Cocoa Touch does on the iPhone. Android also bundles a set of applications. While Apple adapted its existing Mac OS X to work in a mobile environment to create the iPhone OS, Android is more like a customized Java environment running on a specialized mobile Linux variant: elements of maturity in an otherwise experimental new platform. What is Android? -Google Android was by no means the first mobile OS using Linux. Both Palm and its amputated ACCESS software arm have Linux-based mobile platforms. Nokia has Maemo, which it uses in its Internet Tablets, and also recently acquired Trolltech and its Qtopia mobile Linux platform. Motorola has teamed up with MontaVista Software to use its Mobilinux. Intel created the Moblin project for mobile Linux, aimed at Internet devices. Google's OHA also isn't the first consortium to attempt to standardize a mobile Linux platform. The OSDL started the Mobile Linux Initiative to define requirements for hardware; the Consumer Electronics Linux Forum (CELF) then worked to define various phone profiles aimed at the Japanese market; the Linux Phone Standard (LiPS) Forum tried to do the same thing in Europe. In 2007, LiPS was folded into the new LiMo Foundation, along with the OSDL. All of these committees have had some overlap and some complementary features. Several of Google's OHA partners are also LiMo members, including NTT DoCoMo, Wind River, and Motorola. So why didn't Google just join LiMo? “LiMo, very candidly, wasn't moving fast enough,” OHA board member John Bruggeman told CNET. Google hopes to herd the Linux cats into a progressive, structured platform that can battle against Symbian and Windows Mobile to succeed as the new DOS of smartphones. Will Google fracture or unify mobile Linux? The Presumption of the Necessity of DOS. The previous segment examining Windows Mobile pointed out how the PC industry as a whole assumed that Microsoft's desktop Windows monopoly would easily take over dominance in the MP3 player market, pushing Apple into a niche position. This was expected because DOS had pushed Apple's early computers into a reduced role starting in 1981, and Microsoft had repeated this again in 1991 when the DOS world migrated to Windows, effectively pruning Apple's Macintosh into a Bonsai platform. The inability of one company to dominate any product category has been frequently repeated by PC industry pundits as a given, despite the fact that history is full of examples of this happening. Sony dominated personal music players for two decades under the Walkman brand even while equally large competitors tried to push it from this position; Nintendo has similarly owned handheld gaming despite ill-fated efforts to grab a piece of its pie by products running a generic platform such as Microsoft's WinCE (Gizmondo), Linux (GP32), and Symbian (N-Gage). In fact, outside of the Windows/DOS PC, there are actually few examples of a generic platform taking over an industry. Nearly every other consumer-facing product uses proprietary platforms: car makers, stereo equipment, appliances and so on typically all use designs custom to their maker. The paradox of the Windows PC market has been that Microsoft's broadly licensed software supposedly saves hardware makers from investing in software development while ensuring compatibility, when in reality it adds significant costs to PC makers while limiting their ability to differentiate themselves. That explains why PC makers have been perpetually merging together and going out of business while Microosft has rolled in money over the last two decades. Parallel efforts to copy Microsoft in broadly licensing an operating system have regularly failed: IBM's OS/2, Apple's Mac OS, Palm's PDA OS, even Microsoft's own efforts to duplicate Windows dominance in other markets, from copy machines to PDAs to smartphones to SPOT watches to music players. The closest copy may be Symbian, but its customers are partners, not simply consumers of a generic third party's operating system as Windows licensees are. That indicates it is not necessary to duplicate the dominance exercised by Microsoft over the PC industry in the smartphone market. Google's Android and Symbian exist more as technology sharing pacts among manufacturers, but both aspire to take Microsoft's DOS role among smartphones. However, the idea that Apple's iPhone must be dethroned by a modern-day DOS, whether Windows Mobile, Android, or Symbian, is not just debatable, but does not sync with the reality of more recent events. Apple's recent history of the iPod further refutes the idea that a software analog to Microsoft is needed. The iPod Emergence: Apple & Pixo vs IBM & Microsoft. Apple's iPod in 2001 made no effort to clone the DOS business model; it actually did the opposite. When Apple entered the market, there were a number of existing MP3 devices using custom software, hardware designs, and DRM codecs. The iPod used off the shelf components to deliver a custom MP3 player using third party software, but Apple also added its own technologies: easy to use sync with iTunes, a fast Firewire interface that made uploading music far faster than the prevailing USB 1.0, and an attractive industrial design. With the iPod, Apple played the role of IBM in 1981, using Pixo's embedded operating system to enter the market quickly, just as IBM had used DOS. The difference was that Apple didn't direct any market attention toward Pixo and added a lot of value on top of that core embedded OS. A modern day Compaq couldn't simply clone the hardware and license Pixo to run on it in order to compete against the iPod, because the iPod was much more than just generic hardware running Pixo software. As the iPod developed, Pixo's role diminished and was eventually displaced. Just like IBM, Apple jumped into a new market just as demand was beginning to explode. Apple made MP3 players far more attractive to a general audience by delivering greater playback capacity than most entry level devices offered, along with an ease of use that encouraged buyers to jump in at the higher end of the market. That left Apple with not only the lion's share of the market, but also by far the most profitable segments of the market. Two decades prior, IBM badly fumbled its play with the early PC and ended up irrelevant in the PC world by the late 80s, sideswiped by Microsoft's DOS and the cloners who were licensing it in parallel, notably Compaq and later HP and Dell. Steve Jobs had witnessed that happen, and was determined to not let it happen again to Apple. Rather than being manipulated by a software middleware vendor as IBM had, Apple worked to incrementally develop the iPod market itself. After consuming the hard drive-based player market, Apple took on the Flash RAM-based market with a tiny hard drive system used in the iPod Mini, and followed up with Flash-based devices of its own in the Nano and Shuffle. This allowed Apple to progressively serve an increasingly wider market, incrementally growing upon an established foundation. With the iPod, Apple became, in effect, an IBM with its own internal Microsoft. Microsoft's Failure Despite Features. In contrast, Microsoft entered the music player market by promoting music player hardware reference designs around WinCE. However, it was unable to ship a finished design until the iPod had become firmly established around 2005. Later branded as PlaysForSure, the devices were sold by various hardware makers and all purported to support the same DRM and the same music subscription services while also offering a broader array of hardware that presented video before the iPod did, supported wireless before the iPod, and so on. Despite these unique features, all of those PFS designs still failed. Microsoft blamed the failure of PFS upon its music store and hardware partners and decided to take Apple on itself in 2006. It relaunched a Toshiba PFS player as its own device under the Zune brand, adding WiFi music sharing features and a larger display than the current Pods had. It failed dramatically as well. Did Microsoft's attempts to float a new DOS among music players fail because of Apple's success, or due to Microsoft's own problems? The failure of the Zune, which followed the iPod model rather than the DOS model, seems to suggest that Microsoft itself was to blame. Consider too that Microsoft's Windows Mobile phones, which use the same underlying operating system as its failed PlaysForSure music players and the Zune, had similarly flopped even before Apple could release a charismatic phone equivalent to the iPod. Of course, when the iPhone was released, it hit Windows Mobile hardest. The iPhone made Windows Mobile Smartphones look ridiculous and underpowered, and made Windows Mobile Pocket PC phones look clumsy and awkward, despite the fact that they both supported a variety of features the iPhone didn't, including the ability to edit documents, capture video, send MMS, and so on. Simply adding on features did not enable Microsoft to compete against Apple. The only conclusion that can be drawn from all this is that competing against Apple requires more than just having a feature arsenal. Microsoft's failures in themselves do not necessarily mean that Google's Android will fail in its attempts to float its own smartphone platform. Why Microsoft’s Zune is Still Failing Microsoft’s Zune, Vista, and Windows Mobile 7 Strategy vs the iPhone Will Google Succeed where Microsoft Failed? Microsoft's demonstrated inability to successfully enter consumer markets for MP3 players and smartphones has given observers little faith that the company will somehow turn things around in late 2009 when its next generation of devices are expected to be released. However, prior to that the first fruits of Google's efforts to build its own smartphone operating environment will arrive. Will Google's Android take over Microsoft's crown as the “DOS vendor” among smartphones? Supporters of Google's Android project point to some parallels between Android for smartphones and Windows on the PC: Android will allow hardware makers to differentiate in ways that can offer features Apple can't (or doesn't want to); it should allow software developers to offer features Apple does not allow on the iPhone; it embraces open, hobbyist experimentation in ways that Apple currently isn't; and it opens the potential for content providers that Apple is not interested in allowing. Openness is Android's key competitive feature. Will all this openness allow Google to unseat the iPhone to become the primary platform developers want to participate in, and subsequently soak up the market for third party hardware makers that Windows Mobile serves? While Google currently has no market share due to the fact that no Android phones have yet shipped, it does have broad vocal support from a variety of the same kinds of hardware manufacturers that supported DOS and Windows and helped to make those platforms successful in the desktop PC market. HTC and Android. The first Android phone is expected to be the HTC Dream; Taiwan's HTC (High Tech Computer) also manufactures Palm's Treo Pro phone as well as many of the most visible Windows Mobile devices. In addition to models produced under its own name, HTC also sells Windows Mobile devices under the Dopod brand, as well as no-name phones branded by providers, such as AT&T, Orange, Sprint, T-Mobile, Verizon Wireless, Vodafone, and others. HTC will also be building the XPERIA X1 Windows Mobile phone for Sony Ericsson. HTC was quick to throw its support behind Android despite its long term alliance with Windows Mobile. Why would it so enthusiastically support an unproven platform from a company that has no experience in consumer hardware platforms? One can only assume that HTC is not happy with the current state of Windows Mobile, and desperately wants another “DOS” to succeed where Microsoft's has so spectacularly failed. As an Original Design Manufacturer for Palm, HTC watched as Palm adopted Windows Mobile in place of the Palm OS and subsequently fell even deeper into crisis. Palm's only successful phone since has been its Palm OS-based Centro. HTC undoubtedly sees Android as its ticket to becoming the next Dell, but without a similar dependance upon Microsoft. Android for mobile phones is essentially playing the role of Linux for PCs, except that it has the backing of a major company behind it. Can Android Take on the iPhone with Openness as its Feature? As great as this sounds, it's important to consider that Linux on the desktop has made no significant progress in eating into Windows dominance after a decade of trying. Being open, free, flexible, and decentralized hasn't been enough of an advantage to get consumers to migrate from Windows to Linux in any fraction of significance. Similarly, in the music business, Linux-based MP3 players have had no impact on the iPod, despite offering more features, flexibility, support for additional codecs, and so on. In the mobile phone area, Linux enjoys a sizable portion of the smartphone market, but this is almost entirely due to phones sold by Motorola in China, where the advantages of Linux' openness are void. Motorola's Linux phones offer nothing to users in terms of openness or flexibility, and are really no different in terms of features than other appliance 'feature phones' based upon closed operating systems. And again, a key problem with assaulting Apple in a feature war is that neither the iPod nor the iPhone became popular by being “highly featured.” They both delivered perhaps 80% of the functionality found in all other devices in the market. Rather than trying to match every feature and cater to every niche as Microsoft had with Windows Mobile, Apple's devices did a few things very well at launch, and incrementally developed into full featured devices that still lack some of the more unique features of their competitors. Further, in terms of openness, the demographic that embraces Linux' characteristic freedoms is not the same as the demographic that buys smartphones in quantity and then pays for data service. This is a critical fact to consider because a big part of the iPhone's success stems from the fact that it is being pushed by mobile providers who want to capture the cream of the market willing to pay a premium for data services. The Frankenphone. Combining the fractured aesthetic of HTC's Windows Mobile phone hardware with Android's software, based upon Linux' perpetually unfinished DIY openness and Google's Java-like development platform, will not result in a product similar to the iPhone. Instead, it will look a lot like phones that have already failed in the market. Apple's advantage comes from slick hardware designs with a close attention to detail, combined with software that purposely does less so that it can do what it does better. Even Apple's own conservative attempts to broaden its software capabilities with iPhone 2.0 have resulted in instability problems that can be blamed upon both Apple's early releases of its phone operating system and software from inexperienced third party developers new to the platform. Would the current frustrations with iPhone 2.0 be somehow mitigated by additional openness that also embraced all kinds of variables from different hardware makers with less quality control than Apple, a loose committee of additional cooks working to serve up operating system features targeted at every possible conceived need, and a wider third party software group with fewer constraints on illegal behaviors? The Failure of Open. While it is politically unpopular to criticize the well meaning efforts of open source contributors, the failure of Linux on the desktop, the failure of the vaporware Indrema game console, and the failure of the OpenMoko project to deliver a workable phone within a year of its deadline all underline the serious problems open development faces in the world of consumer oriented devices. Open has simply failed to deliver on its promises in the world of consumer hardware. OpenMoko was supposed to release its first mobile phone to consumers for $250 several months in advance of the iPhone. When the iPhone shipped, the group then announced new plans to get its phone out by the end of 2007. Instead, this spring the group announced new plans to move to an entirely different development platform, and ship its phone mid year for $400 with limited functionality and incomplete software outside of basic GSM phone features. Linux's notable successes, from Motorola's Linux phones to the Tivo DVR to Linksys Routers, have often come without any associated openness or freedom, and were instead delivered simply to provide their manufacturer with a free kernel to build upon. This indicates that while Linux may find its way into an increasing number of smartphones, it will likely not be accompanied by the glorious freedom of an open development environment Google has said it would offer with Android. Apple iPhone vs the FIC Neo1973 OpenMoko Linux Smartphone Can Google Succeed Where Open Has Previously Failed? Despite “openness” being Android's strongest competitive feature compared to Apple's iPhone, Google recently revealed that its wide-open development model is intentionally gravitating towards a closed association of top tier partners due to practical considerations. In July, Google accidentally sent out a notice that revealed that it had been seeding private SDK updates to only a subset of its contributors, angering those who believed that Android would be as open as Linux on the desktop or the OpenMoko project. Further, Google has restricted initial development to higher level APIs just as Apple did, further indicating that Google itself realizes that being wildly open to impress a minority of hobbyists will not result in the commercial success of its new platform. That serves to neuter Android's primary advantage over the iPhone. Without delivering on the premise of being wide open, Android is really just a less mature set of Java libraries used to create a specialized binary that runs on a Linux foundation. Unlike Apple's iPhone, Android phones won't have a slick user interface developed by professional artists, nor the iPhone's legacy of mature software development frameworks crafted over the last thirty years, nor the iPhone's tightly integrated hardware with award winning industrial design, nor its marketing power tied into the iPod and Apple's retail stores. Android won't be an open iPhone, it will only be a Windows Mobile phone with a better kernel that runs specialized Java software instead of Win32 or .NET code. Don't expect consumers to be impressed by that. The Biggest Missing Feature. There is one remaining factor that strangles to death any last remaining hope that Android might assassinate the iPhone and assume the crown of the “DOS of smartphones.” That is: Android delivers zero price advantage to consumers. In 1981 and 1991, consumers who wanted Apple computers faced the sticker shock of a somewhat arrogant price tag. Apple sold its computers, as it still does, at the higher end of the market, but there was simply far more range in prices available. In 1981, that meant the Apple II was $2600 and the new Apple III was $3500, even before you added a monitor. On the low end, Commodore sold its far less powerful, but “still a computer” Vic-20 for $300, while IBM entered the market with the IBM PC at $3000. Over the next few years, Apple focused on delivering additional sophistication at the same price, releasing the $10,000 Lisa and then the $2,500 Macintosh. IBM continued selling PCs in the same $3,000 to $10,000 range, but other DOS PC vendors began selling machines at prices that ranged as low as $1500. That left Apple with a roughly $1000 price premium over low end PCs. The products weren't really comparable, but consumers only saw the huge price difference. In 1991, Apple was still selling moderate to high-end Macintoshes for $3,800 to $10,000; the crippled Mac LC was $2500, and obsolete-at-birth Mac Classic ranged from $999 to $1500. Windows allowed PC makers to ship a functional $1500 PC and claim a rough approximation to Apple's $2500 entry level system, maintaining that apparent $1000 price premium. Today, pundits are lucky to find a Dell or HP system that is even a couple hundred dollars less than a comparable Mac. However, in the smartphone business, the iPhone 3G is now the same price, if not less, than generic competing phones on the market. Even more significant is the fact that the price of the phone hardware is nearly nothing compared to the cost of the service plan. This fact simply eases any price premium that could cause buyers to flock to a smartphone running a generic operating system over buying the iPhone 3G, regardless of whether it runs Windows Mobile or Android. 1990-1995: Planting Software Seeds Android Partners Have Already Failed. That same pricing principle similarly prevented buyers from considering many of the alternatives to the iPod. While Apple's original iPod models were more expensive than many of the first MP3 players on the market, they were price competitive with models offering similar features. By 2004, it was Apple who was undercutting MP3 competitors on price. Microsoft offered zero price advantage when it began selling the Zune, a major factor in its failure, but Microsoft simply couldn't out-price the iPod; it was already losing money offering the Zune at the same price as the iPod. Apple now has tremendous market power in buying RAM and other components that will prevent any competitors from being able to offer a huge discount over the iPhone's $199 price tag. Even if competitors were to give their phones away, they would only offer a $200 discount to users who would then still need to pay the same mobile fees to use the phone. Android's other partners, including Samsung and LG, have already failed to capture any significant market share in the music player market. Are they going to maintain their position as smartphone makers now that they face similar competition from Apple, its iPod ecosystem, its iTunes Music and Apps Store, Apple's retail store experience, and other factors that are pushing the iPhone? If they can, it is not obvious how partnering with Android will help. Other Problems for Android. Android was announced in early November 2007 and was followed with an early preview SDK within a couple weeks, a month ahead of Apple's initial announcement of the iPhone 2.0 SDK. However, between March and July 2008, Apple delivered nine progressive releases of its SDK, opened its App Store, and sold 60 million apps, raising $30 million to support iPhone software development in just the first month. It has since released three more SDK updates to developers related to iPhone 2.1, which is expected next month. Android just published its first open SDK beta update earlier this week, warning developers that “applications developed with it may not quite be compatible with devices running the final Android 1.0.” Additionally, Android still has no phones available. By the time the HTC Dream is expected to launch, Apple will have an installed base of around ten million iPhone (and iPod touch) users supporting software development through iTunes. The business model for selling Android apps is no better than that for selling jailbreak iPhone apps: there is no iTunes Apps Store to promote them, so users will have to track them down on their own. Android developers also have no real freedom that jailbreak iPhone developers lack. The only difference is that there are ten million iPhones to sell jailbreak apps to, and currently zero Android phones. If selling a jailbreak iPhone app sounds like more trouble than its worth, imagine trying to sell Android apps to a non-existant audience. Now add the official iPhone App Store into the mix, where publicity, promotion and profits are booming. What platform is going to have the most applications? How many users will flock to a smartphone platform with no apps? The wisdom of releasing a desirable phone and achieving a significant installed base before releasing an SDK makes a lot more sense in retrospect. Additionally, while Apple has a decade of experience in shipping regular updates to Mac OS X and its Xcode developer tools, Google has only shipped a random assortment of web-oriented SDKs (a number of which have been abandoned) as a tangent to its core business of selling advertisements. When the Android SDK 1.0 is finished later this year, developers will not only lack an installed base to sell their apps to, but will also have no high profile market for selling their apps in, and subsequently no financial incentive to develop applications that add value to the Android platform, just like Linux on the PC desktop. Around the same time, possibly within the next month, Apple will be shipping its second major OS release: iPhone 2.1. Apple will also be upgrading its entire user base to the new software so that developers will have a cohesive platform to target. This mirrors the efforts Apple has taken to upgrade its Mac OS X users to the same reference release. Mobile developers will be seeing money pouring in via iTunes while crickets chirp in the Android section of various mobile online stores. Apple’s iPhone Vs. Other Mobile Hardware Makers: 5 Revenue Engines Same Same, But Different: DOS Model Problems. Android developers will also have a series of other problems to manage. Like Windows Mobile, Android is intended to support everything, from BlackBerry-style keypad phones with a small touchscreen to the simple Windows Mobile Smartphone form factor lacking a touch screen to iPhone-like full size touch screens. Also like Windows Mobile, Android phone makers will have the option to leave off Bluetooth, WiFi, GPS location services, graphics hardware acceleration, and so on. Each Android phone will also have unique camera hardware, support for different video and audio codecs, and varied support for other differentiating proprietary services demanded by mobile operators. This will force developers to to make complex decisions regarding the lowest common denominator they choose to support. So while the iPhone will have a cohesive feature set, a managed software environment, and a functional market, Android will be a loose federation of hardware makers selling the same random features found on Windows Mobile today, with a chaotic development environment that lacks any central market for users or developers. And it will be run as an experiment by a company with no experience in consumer hardware or platform development. The Missing Tap. One specific example of the “DOS model problem” is that Android currently does not support multitouch. It's not touched on in the API, and Google quietly tap dances around its omission. Why no multitouch? Because multitouch screens are expensive, and most OHA hardware members are more interested in making a profit in a competitive phone market rather than impressing consumers as Apple did with the iPhone. Most existing smartphones, even those trying to directly rival the iPhone, use a stylus driven, pressure sensitive tap screen or a simpler, cheaper touch technology that lacks support for sensing multitouch. The iPhone's screen can actually sense up to five fingers at once, but the primary feature multitouch offers on the iPhone is the two fingered tapping and the pinching effects everyone associates with it. Android could certainly support multitouch if there were a demand for it, but that's the point: Google knows that its hardware partners are cheap and unlikely to put out hardware that actually competes with the iPhone. Instead of using expensive technologies that deliver clever yet largely invisible functionality, OHA members, just like PC makers, are far more likely to add flashy, impractical gadgety fluff that's cheap to tack on, such as slide out keyboards, neon tubes, and scratch and sniff stickers. That's how you impress gullible nerds on the cheap. Google itself is blowing smoke and erecting mirrors to distract from the reality that it being a “DOS vendor” means supporting bargain basement hardware from penny pinching duplicators. Android has been demonstrating some “wow” features such as a Street Maps app that pans around based on an internal compass in the demonstration phone. The problem is that that kind of thing only makes for a fun demo. Nobody needs to twirl around their phone in the air to see a view of the other side of the street, but everyone who has used an iPhone will wonder why they can't pinch to zoom out. Even worse, most Android phones aren't going to have a compass built into them, so Google is demonstrating features most Android users won't be able to use. That Sounds Like Microsoft… Google's design decisions are beginning to look a lot like Windows Vista; rather than actually working to make laptops boot faster, Microsoft came up with the idea of adding a small screen to the back of Vista laptops so users could check their email without having to wake the system up. But this was a stupid idea for a number of reasons, the most obvious being that most users just want a laptop that boots up quickly. Few laptops got the mini screen, but every user who tries Vista on their laptop will wonder why it doesn't boot up as fast as Mac OS X Leopard. In the same way, Google is advertising features for Android that most users won't ever see in their actual phones while ignoring things people will expect based on their exposure to the iPhone. Android is simply selecting the wrong features. Android will offer the advantages of supporting MMS, recording video, and the list of other features Windows Mobile already supplies. Those features didn't stop Apple from firing past Microsoft in the smartphone arena however, just as the Zune's highly touted WiFi and screen didn't phase iPod buyers. Incidentally, just months after the Zune, Apple had not only demonstrated a larger display but a higher definition multitouch screen, and not only WiFi, but functional WiFi that could be used to browse the web or check email. This suggests that Apple, with its faster release schedule, won't stay behind any of the leading features potentially offered by Android for very long. Android partners, however, will find it as difficult to catch up with Apple's unique features, just as Microsoft has been stymied to keep up with Mac OS X, the iPod, and the iPhone. The underlying reason: both Google and Microosft are tasked with maintaing support for a huge variety of hardware options demanded by all their partners. Apple has the unique circumstances to do only what it needs to do itself. Android in Windows Mobile's Shoes. Like Windows Mobile, Android faces a difficult market. In the US, it competes against the popular BlackBerry in corporate markets and the iPhone among consumers. Worldwide, it competes against entrenched market leader Nokia. The difference is that Google, unlike Microsoft, has no in. Windows Mobile was adopted by Windows-bound IT shops despite its weaknesses. Nobody has any preexisting reason to try an Android phone apart from hobbyists and open software enthusiasts, a demographic that has done little to move Linux on the PC desktop. Google also lacks Microsoft's installed base; it's starting from zero. The smartphone industry initially doubted Apple's chances of making much progress with the iPhone, despite the company having the Mac platform, the iPod, retail stores, platform development experience, marketing savvy, industrial design prowess, and so on. Google doesn't have any of those things. Mobile Providers vs Android. Apple also started with an exclusive partnership with AT&T, a three legged race that demanded effort from both. Google is hoping that hardware makers handle the hardware details and that mobile providers will be excited to sell its Android phones. While hardware makers such as HTC clearly appreciate having found a free alternative to Windows Mobile, it's not obvious why providers would be excited about Android, as it promises an openness that most mobile providers strongly oppose. AT&T took a big risk in getting behind the iPhone, as the phone encouraged users to use email rather than fee-based SMS and MMS, it supported WiFi for data access, and it bypassed AT&T's MEdia Net services to plug into iTunes instead. Verizon refused to parter with Apple and grant it those kinds of concessions. Is AT&T going to take a similar risk to partner with a phone that is not exclusive to it, and is Verizon now going to open its arms to support phones that do not exclusively support BREW, VCast and its other proprietary services? While Android may well eat into Microsoft's Windows Mobile business by stealing away its hardware makers, it seems unlikely that Android will ever serve as more than free alternative to Windows Mobile in a market where Windows Mobile is increasingly irrelevant. Android may have the dubious distinction of swallowing Microsoft's mobile business the same way Microsoft ate up the Palm OS, but even if it accomplishes that goal, Google will likely find itself unsustainably hungry immediately afterward. It will also find itself swimming in a shark tank of hungry rivals, including Nokia's Symbian, RIM's BlackBerry, and Apple's iPhone. Symbian is the final generic platform vying for the opportunity to play DOS in the smartphone market. The next article will examine Nokia's chances in its bid to match Microsoft's PC dominance in the mobile market while setting out in a new venture to copy Android's open software model. Did you like this article? Let me know. Comment here, in the Forum, or email me with your ideas. Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast (oh wait, I have to fix that first). It's also cool to submit my articles to Digg, Reddit, or Slashdot where more people will see them. Consider making a small donation supporting this site. Thanks!

• RoughlyDrafted Magazine on August 24, 2008
• More Details
• Related News

★ Raining on the OpenClip Parade

The OpenClip project, which debuted this week, describes itself as “a non-profit, open-source, community-effort project, which promotes a framework for the iPhone that allows users to copy / paste between participating applications.” The obvious shortcoming, compared to a hypothetical system-wide clipboard from Apple, is that apps which don’t explicitly support the OpenClip scheme don’t work with it — including all of Apple’s apps, like Mail and Safari. That’s to be expected. But it’s worse than that. The OpenClip framework, by Zac White, is a very clever implementation of a fundamentally unwise idea. White’s description of the project on his own weblog is fairly open regarding its inherent problems. The OpenClip.org web site, however, is hosted and written not by White but by Proximi, the developers behind MagicPad. Their developer FAQ states: How does it work? OpenClip utilizes a shared space on the iPhone. Applications that use the OpenClip framework can access this common area to write to and read from, allowing copy / paste between participating apps. That struck me as curious, as I wasn’t aware of any inter-application “shared space” on the iPhone. White’s own description of how it works and the OpenClip source code itself show that such a description is disingenuous. The “How does it work?” section of their regular (i.e. non-developer) FAQ is more technically accurate: OpenClip utilizes an application’s ability to read into other application’s Documents directory. Applications that use the OpenClip framework can access this read only area to read pastes from other applications and then OpenClip can offer the newest data to the current application. The fundamental problem the OpenClip project faces is that of data interchange. If you copy something in app A, and wish to paste it in app B, the clipboard data needs to exist somewhere where app A can write (when you copy), and where B can read (when you paste). On Mac OS X, the system provides this to Cocoa apps via the NSPasteboard class and associated APIs. Individual applications don’t have to worry about the details of how and where clipboard data is stored; it’s an implementation detail completely managed by the system. But even ignoring Mac OS X’s standard system-wise clipboard, apps on the Mac face no challenges when it comes to exchanging data with other apps via the file system. On the Mac, all apps can read and write wherever they want within your entire home folder. So if Mac apps A and B wish to share data with each other via a custom file format, they can both agree to do so via a shared file, in, say, the user’s Documents folder. iPhone apps can’t do that. Or, more specifically, third-party iPhone apps written with the official iPhone SDK can’t do that; Apple’s own iPhone apps can do whatever they want. iPhone Sandboxing The idea with sandboxing is that each app executes in its own space, with limited resources and with no ability to alter or modify anything outside its own sandbox. The downside is that some of the things Mac apps can do but which iPhone apps cannot are potentially very useful (and/or very cool). The upside is that those same things are potentially dangerous (both in terms of security and in terms of stability). It’s a trade-off. Here’s how sandboxing works in iPhone OS 2.0. Given its shared roots with Mac OS X, the iPhone OS unsurprisingly has a very familiar file system layout. The system’s standard apps reside in a top-level folder named /Applications/, just like on Mac OS X. Apps that you install via the App Store don’t go there, however. Instead, there is a separate Applications folder for these applications. In iPhone OS 2.0, that folder is at /private/var/mobile/Applications/, but it doesn’t really matter exactly where it is. (/private/var/mobile/ is more or less the iPhone equivalent of your home folder.) Every time you install an application, a new sandbox is created within that Applications folder. The sandbox is a folder named with a UUID, for example, “68813987-A628-493F-90E2-A6ABCD922A89”. The application itself is installed inside the sandbox folder, along with its own directories for writing data. So, if you install two iPhone apps from the App Store, named, say, “Foo” and “Bar”, they’ll be installed in two separate sandboxes that look something like this at the file system level: /private/var/mobile/Applications/04A74595-4DE8-4026-8459-63B2D153D13C/ Documents/ Foo.app/ Library/ tmp/ /private/var/mobile/Applications/77C9A482-F5F8-4284-9E16-C629763B9162/ Bar.app/ Documents/ Library/ tmp/ Each app gets its own Documents folder, its own Library folder, and even its own temporary scratch space (“tmp”). Each application can only write to the file system within its own sandbox directory. This isn’t just a guideline from Apple — it is enforced by the OS. Any attempt by an app to write to the file system outside its sandbox will fail.1 However, in iPhone OS 2.0, an app can read from anywhere in the file system. This serves as the basis for how OpenClip works. How OpenClip Works As an API, White’s OCPasteboard class is a clone of Cocoa’s NSPasteboard. For every NSwhatever call in the standard Cocoa NSPasteboard class hiearchy, OpenClip offers a corresponding OCwhatever. The advantage to this design is twofold: first, it’s exactly what Cocoa developers are accustomed to on the Mac; second, if Apple eventually ports NSPasteboard to the iPhone OS, it’s likely to have a very similar API. When an app using OpenClip copies data,2 it writes the data into two files within its own Documents folder: Documents/ OpenClip/ OCGeneralPboard.data OCGeneralPboard.metadata Foo.app/ Library/ tmp/ When an app using OpenClip pastes, the OpenClip framework peeks into the Documents folder of every other app sandbox in the file system, looking for the most recently-modified OpenClip data files. So if you have three apps, A, B, and C, and you copy something in A, then copy something else in B, then do a paste in C, C will paste the data copied from app B, because it was created more recently. The Problems On his weblog, White writes: How it works is relatively simple and doesn’t break the SDK agreement. OpenClip works by looking into the Documents folder of other applications to get their pastes. Applications are allowed to write all they want to their own Documents directory (for copy), so no foul there. Applications are also allowed to read outside their sandbox into the Documents directories for other apps (for paste), so no foul there. This is not accurate. It’s more like “slipping through a temporary loophole” than “no foul”. In the Security section of chapter 4 of Apple’s iPhone OS Programming Guide, the sandbox is described by Apple as follows (boldface emphasis added): For security reasons, iPhone OS restricts an application and its preferences and data to a unique location in the file system. This location is part of the security feature known as the application’s “sandbox.” The sandbox is a set of fine-grained controls limiting access to files, preferences, network resources, hardware, and so on. In iPhone OS, an application and its data reside in a secure location that no other application can access. Not simply that no other application can write to, but which no other application can access. That this restriction is not yet enforced at a technical level (such as is the case with an app attempting to write outside its own sandbox) does not mean it’s permitted. And, indeed, in the 2.1b4 release of the iPhone OS, it is enforced. The OpenClip demo apps, which work as advertised on iPhone OS 2.0.2, do not work in the current 2.1 beta, because apps are no longer able to read or even see other apps’ sandboxes.3 To be clear, this change is clearly not in response to OpenClip; Apple began seeding the 2.1 betas with these tightened sandbox restrictions before OpenClip debuted, and the iPhone OS Programming Guide has stated all along that apps can’t “access” the contents of other sandboxes. There is no “shared space” for iPhone apps to exchange data. (One workaround I’ve seen bandied about is to use the system-wide Address Book database as a storage location for shared clipboard data. Needless to say, such an implementation would not qualify as an intended use of the AddressBook framework.) Wishing it were otherwise doesn’t make it so. The intent of OpenClip is fine. That there’s been so much coverage regarding OpenClip in the past 24 hours shows just how much demand there is for inter-application copy-and-paste. But developers would be foolish to adopt a framework that only works today because of a loophole in iPhone OS 2.0 that is already closed in iPhone OS 2.1. This structure has another benefit in addition to security — it makes it easy for the system to remove all of an app’s data along with the app itself when you delete the app. No preference files or application support detritus can be left behind, because the entire sandbox folder is deleted when you delete the app.�↩ And I do mean “data”, not just text. OpenClip supports both text and images.�↩ In iPhone OS 2.1, an application using OpenClip would still work for copying and pasting within itself, because that only requires reading and writing to the app’s own sandbox. But you don’t OpenClip for that.�↩

• Daring Fireball on August 21, 2008
• More Details
• Related News

★ Macworld Expo Predictions

Predictions and advance commentary for tomorrow’s Macworld keynote, some based on consensus rumors, some based on no more than wishful thinking on the part of yours truly. This is all conjecture and tea-leaf-reading (well, mostly), so, please, no wagering. I keep two questions in mind when evaluating Apple product ideas: Would people run out to stand in line to buy this immediately? If not, is there a long-term strategic reason for Apple to start selling this now? If the answer to both questions is “no”, then Apple isn’t going to do it. The iPhone is a perfect example of a #1; the Apple TV is a #2. New Sub-Notebook MacBook: Yes Apple hasn’t had a small notebook in its lineup since the 12-inch PowerBook G4, which I still see in wide use. If you’re using a portable as a portable, smaller size and lighter weight make a tremendous difference. The demand for a good notebook smaller and lighter than standard MacBooks is strong; I think it’s a sure thing that Apple is set to announce one. (Of course, I said so before last year’s Macworld, too.) I say the consensus rumors are right: super-thin, no built-in optical drive, widescreen 12-inch display. It will use a hard drive, not flash memory, for storage. (Look no further than the iPod Classic to see how hard drives don’t keep a device from being super-thin). Rumors are already running strong that it’ll be called MacBook Air. (I like it, not sure though if Nike would.) Newton-y Tablet Thing: No I am nearly convinced that this product exists, at least as a project in development. My hunch is that AppleInsider has it spot-on: it’s in development, but not yet ready to launch, and, perhaps, never will if Apple can’t get it right. (Recall Steve Jobs’s statement to Walter Mossberg that he’s as proud of some of the products Apple decided not to ship as he is of the ones they did.) Like the iPhone, it runs “OS X” but not Mac OS X, does not run Mac apps, and will not be called a “Mac”. The big problem with a “tablet” computer of any sort is that 15 years of industry history indicate that people do not want to buy tablet computers. But the iPhone, arguably, is a tablet computer — a sub-tablet, if you will. The key mistake with failed efforts like Microsoft’s Tablet PC (and even Apple’s own Newton) was that these devices attempt to do too much. It’s seen as a feature that Tablet PCs run the full version of Windows. But why force software UI’s designed for traditional hardware form factors upon a totally different device? A successful tablet-like device from Apple, I think, would clearly be designed as a secondary computing device — a satellite attached and synched to a Mac or PC (probably, of course, through iTunes). There’s still the “what would I use it for?” factor. It seems to me it would need to be something more than just an iPod Touch with a larger screen — if that’s all it is, then what’s the point of buying one instead of a smaller, poctetable, iPod Touch or iPhone? I simply lack the cleverness to imagine what that hook might be — but I can’t imagine Apple releasing such a product without an obvious “Oh I gotta buy that” hook. Anyway: I do think something like this is in the works, but I don’t think it’s coming out now. I’d love to be wrong. Ubiquitous Wireless Networking for MacBooks: Please After using my iPhone for a few months, it started feeling weird that my PowerBook doesn’t have ubiquitous wireless networking: Wi-Fi when available, and seamless, instant switchover to something else when it isn’t. Just what that “something else” is, I don’t know. EVDO? WiMax? A Bluetooth connection to share an iPhone’s EDGE connection? I don’t care. But I’d pay for it. Ubiquitous networking is certainly the most intriguing thing about Amazon’s Kindle. It just feels crippled that I can’t get a network connection — even a slow one — once I’m outside the range of Wi-Fi. Wireless Time Machine Backups: Yes Time Machine is very cool; the first backup that qualifies as “you don’t have to do anything, it just works”. But currently it only works using a storage device connected via USB or FireWire. Tethered backups are irritating with notebooks — and MacBooks are the fastest-growing segment of Apple’s Mac hardware sales. The problem is that when you want to use your portable away from your desk, it’s a pain to disconnect mounted USB and FireWire drives. You can’t just pulled the plugs — you’ve got to unmount them in the Finder first. And, once you do so, to get Time Machine backups running again, you’ve got to re-tether your storage drive. Leopard developer seeds all supported network backups to USB drives connected to an AirPort base station. The feature was also demoed at WWDC. It was removed (or, better said, disabled) very late in Leopard’s development, supposedly because of a security problem that was discovered, but I expect the feature to return, perhaps in 10.5.2. It’s a terrific idea, perfect for multi-Mac homes and small offices. But so why not sell a device as a dedicated product — a big 500 GB or larger hard drive (or array of them) with built-in AirPort networking. No need to attach it to a separate AirPort base station, no temptation to use the device for anything other than one purpose: backing up via Time Machine. Just plug it into a power outlet, run through a simply configuration tool a la AirPort Utility, and it’s ready. When it first appears on your network, your (Leopard-running) Mac could prompt to ask if you’d like to use it for Time Machine, the same way it prompts when you first plug in a new USB or FireWire drive. iTunes Movie Rentals: Yes This one seems like such a done deal that it barely qualifies as a rumor. It seems obvious: Unlike with music, there’s been a strong market for movie rentals for as long as there’s been a home video market. Most movies aren’t worth watching more than once. Reports (based on leaks from studio executives) indicate rentals will cost $3-5, and will expire after 24 hours. If true, presumably that means they’ll expire 24 hours after you beginning playing them, not 24 hours after downloading. It’d be nice if the terms were a bit more flexible than that. One of the best things about Netflix, and something which makes it far more appealing than traditional brick-and-mortar Blockbuster-style rentals, is that you can watch movies on your own terms. A Netflix-style iTunes movie subscription service that lets you keep a certain number of unlocked movies open at the same time would be killer. Apple TV 2.0: Yes Jobs has called Apple TV a “hobby” for Apple. I think they have high hopes for it, but calling it a hobby is a practical way to buy time for it. What Apple did with the iPod was start as small and simple as they could — one device, in one configuration, only for the Mac, and all it did was play recorded audio — and then build the platform slowly from there. Things like Windows support, color screens, video playback, and expanding to a range of form factors all came incrementally. I think that’s the plan with Apple TV. Start simple and humble, and build from there, year after year. One obvious improvement (albeit contingent upon another rumor) would be to allow us to buy (or rent) movies and TV shows directly from the iTunes Store, right from the Apple TV. If the iPhone can do it, the Apple TV should too. I still think it’d be good business for Apple to sell their own HDTV sets with Apple TV built-in — more money for Apple, one fewer device spewing cables behind the display. DRM-Free iTunes Plus Music From the Other Major Music Labels: No I think Apple would love to have this, but it seems pretty clear that the major labels — other than EMI, of course — are convinced that it’s in their interest to withhold DRM-free music from Apple, in the hopes of helping Amazon gain market share. It actually agree that it’s in the music labels’ interest for Amazon’s music store to succeed. I’m not sure, though, that withholding DRM-free music from Apple is spiting anyone other than iTunes customers. I suspect the vast majority — an overwhelming majority — of iTunes music purchases are made by people who have at best only a vague inkling of what “DRM” is. If there’s any actual logic to it, it’s PR — withholding DRM-free music from Apple makes it easier to paint Apple as a company bent on using iTunes as a competitive cudgel to lock customers in to iPod hardware. Only a hack reporter would buy into that line, given Steve Jobs’s unequivocol “Thoughts on Music” open letter last year. One thing that would dispel any negative stories on the state of the iTunes empire, of course, would be the long-awaited debut of The Beatles catalog, exclusively at iTunes, perhaps with an on-stage visit from Paul McCartney. New iPhone Hardware: No, With a Minor Exception Apple announced the original iPhone a year ago, but they didn’t ship it until six months ago. They’re not going to announce new iPhones six months in advance again. (It was to their advantage last year to cause people to postpone phone purchases until the iPhone appeared; that’s not the case now that the iPhone is on the market.) If anything, I don’t expect new iPhones to appear until next fall, at the yearly iPod/iTunes pre-holiday season special event, leaving the original iPhone on the market for over a year. Why revise hardware for a product that, by all accounts, is selling remarkably well as-is? The only exception I could see would be a 16 GB iPhone that’s otherwise unchanged from the current 8 GB model. iPhone SDK News: No I can see the upcoming iPhone SDK getting a mention from Jobs on stage, a reminder that it’s coming and that’s it’s going to be great, but Macworld isn’t WWDC, and SDKs don’t make for splashy presentations. If I’m wrong, it’ll be because they have a demo queued up from a third-party developer with early access to the SDK. Actual third-party software (written against the actual official SDK) is demoable. Games, perhaps? The apparently-leaked 1.1.3 firmware might make for a good demo, what with the jiggly icons and whatnot. Cinema Displays With Better Resolution, Brighter Screens, and Built-In Cameras: Yes If I keep predicting it, eventually I’ll be right.

• Daring Fireball on January 14, 2008
• More Details
• Related News

★ BlackBerry vs. iPhone

1: Wherein Neither ‘RIM’ Nor ‘BlackBerry’ Are Even Mentioned, but Rather the Stage Is Set for Showing Why They Might Be Seriously Screwed Along the lines of can’t-really-be-answered-but-gosh-they’re-fun-to-ponder questions like, say, “Who’d win in a fight, Batman or Spider-Man?” or “Star Destroyer vs. U.S.S. Enterprise?”,1 here’s one regarding the iPhone: What historical Mac is a current iPhone most analogous to, spec-wise? I.e, complete this sentence: “An iPhone is like having a tiny ____ in your pocket?” Now of course the comparison can’t be precise. Different software, different use cases, different purposes. But there’s no denying that an iPhone is a computer. And unless you’re really young, it’s faster — a lot faster — than the computers you owned not so long ago. So, seriously, stop here for a moment and think about it. My first answer, pulled simply from recollection of how fast machines felt to use, was the original iMac. But that machine — announced 10 years ago this week — had a 233 MHz G3 and, by default, a paltry 32 MB of RAM. Apple has never officially released the CPU specs of the iPhone, but Craig Hockenberry poked around with undocumented system APIs which indicated the iPhone’s CPU runs at 400 MHz with a bus speed of 100 MHz, and that there’s 128 MB of RAM. As we all recall from the PowerPC era, MHz is not a precise metric for comparing the performance of CPUs across different architectures; I wouldn’t be surprised in the least to find out that a 400 MHz PowerPC G3 is a faster chip than the 400 MHz ARMwhatever that’s in the iPhone, if only because of the power constraints. But, still, it’s something. So, my answer to the question: the original “Pismo” G3 PowerBook. The numbers match up pretty closely: 400 MHz CPU, 100 MHz bus speed, 64 MB of RAM. (The higher-end Pismo had a 500 MHz CPU and 128 MB of RAM.) Even storage sizes are similar: hard drive options for the Pismo were 6, 12, or 18 GB. Another possible answer: the original blue-and-white Power Mac G3 — again, 400 MHz CPU, 100 MHz bus speed, 64-128 MB of RAM, and 6-12 GB hard drives. Think about that — in just nine years, the specs that then described Apple’s top-of-the-line desktop computer now describe their phone. One thing that makes this comparison hard is that there’s not much software in common. You can’t use most of the real-world tasks commonly used for ballpark benchmarking, like, say, Photoshop image processing or ripping MP3s from AIFFs, because the iPhone doesn’t do them. But there is one processor intensive task we can compare: web page rendering. In the early days of the web, it took a while for even moderately large web pages to render in a browser, even when you were loading them from HTML files right on your hard drive. If you were to plop yourself down in front of one of these vintage 1999-2000 Macs for an afternoon of web browsing, even with a decent Ethernet connection to the Internet you’d find the experience pretty damn slow by current standards. For all the incessant chatter about the demand for and purported certainty of 3G wireless networking in the next generation of iPhone hardware, the truth is that current iPhones are held back, web-surfing-wise, by more than just the speed of EDGE (which admittedly, is indeed pretty slow). Recall this video pitting a 3G Nokia E61i against an iPhone on EDGE — total rendering time was more or less the same, and in a few cases, the iPhone came out ahead. You can see that browsing speed — which is what matters — depends on more than just networking speed simply by comparing how long it takes to render a web page on the iPhone using Wi-Fi: a lot longer than it takes to load the same page in using Safari on a Mac. For example, it takes about two or three seconds for Safari to load the Daring Fireball home page on my new MacBook Pro. Using the same Wi-Fi network, it takes my iPhone about 15 seconds. (Using EDGE, it takes about 60 seconds to completely load, although you can start reading much sooner than that.) Point being that even if 3G wireless networking were as fast as Wi-Fi — which it’s not — browsing on an iPhone would still be pretty slow compared to browsing on a modern desktop or laptop. If you frequently use Wi-Fi on your iPhone, a faster processor in the next-generation hardware would make a bigger difference to the overall experience than faster phone-carrier networking. And so here’s the point I’m driving at. If a 2007 iPhone is loosely equivalent in terms of computing power to a 2000 PowerBook or 1999 Power Mac, that puts the spread at around seven or eight years. Extrapolate forward, and it’s therefore not at all unreasonable to think that a 2014 iPhone will pack the computing power of today’s MacBook Pro. Or, nearer term, that an iPhone introduced two years from now might pack the punch of a 2003 Aluminum PowerBook G4 — quite a difference from the Pismo. Even if your estimate of the iPhone’s equivalent-horsepower Mac is further back in time than mine, there’s no denying that Moore’s Law applies to handhelds, too. Eventually there will be a computer that fits in your pocket that is more powerful than today’s Mac Pros. But the path from here to there is riddled with difficult engineering problems — heat dissipation, battery life, and OS integration chief among them. There is marketing. There most certainly is design. But at the core of this market — by which I mean the market for handheld multitasking web-surfing networked-everywhere “phones” which are really computers — is engineering. Apple is the best handheld computer engineering company in the world today, hands down. They’re also the best handheld computer user experience design company. And they’re not sharing. 2: Why RIM Is Screwed When the iPhone was announced, I saw Apple as staking out ground far afield from the territory RIM occupies with the BlackBerry. Last year, I didn’t see Apple implementing Exchange support in the iPhone OS, and clearly that was, well, completely wrong. The “enterprise” features Apple has announced for the imminent 2.0 release of the iPhone OS — remote wipe, push email, automatic calendar and contact synching — pretty much encompass every single feature that’s been held up as a reason the iPhone wouldn’t sell to enterprise users. It remains to be seen how well these new iPhone features will actually work, but if the answer is “as well as promised”, and if the iPhone’s Mail app is improved in ways targeting people who receive a high number of messages, it’s hard to see a single software advantage in the BlackBerry’s favor. Which leaves hardware, which leaves the keyboard. Two Sundays ago, the New York Times ran a lengthy business-section piece by Brad Stone, titled “BlackBerry’s Quest: Fend Off the iPhone”. Regarding the upcoming BlackBerry 9000, the focus turned to the keyboard: Photographs of the device, leaked to gadget news sites, also indicate that the new BlackBerry will have elegant curves suggestive of the iPhone. It will also have a physical keyboard like previous R.I.M. devices, as opposed to the glass touch screen found on the iPhone. There’s a reason that R.I.M. is averse to the iPhone’s glass pad. “I couldn’t type on it and I still can’t type on it, and a lot of my friends can’t type on it,�? says Mike Lazaridis, R.I.M.’s co-chief executive and technological visionary. “It’s hard to type on a piece of glass.�? Mr. Lazaridis thinks that e-mail-dependent BlackBerry owners demand the reliability and tactile feedback of a keyboard. But, despite his critique of the iPhone, he does not dismiss the possibility that R.I.M. may itself one day sell a touch-screen phone, aimed specifically at consumers without the e-mail demands of BlackBerry’s core users. Translation: “We’ll emphasize the physical keyboard as a differentiating factor as long as it seems to work, at which point we’ll try a touch-screen keyboard too.” The only other angle RIM seems to be hanging its hat on is “security”: RIM is also betting on security, which hinges on the fact that its handsets and e-mail systems are relatively impervious to hackers. Mr. Lazaridis predicts that corporations will not give iPhones to their workers because they have already proved vulnerable to hackers eager to pry iPhones off AT&T’s system and make them work on other wireless networks. “It’s not that simple for an I.T. manager to give up security,�? he said. The idea that iPhone carrier unlocking is a “security problem” is a conflation between what an attacker can do to your phone, against your will and/or unbeknownst to you, versus what a phone’s owner can do to their own phone. It’s not like these “hackers” are attacking happy AT&T-subscribed iPhone owners and switching them over to Sprint against their will. To understand why Apple is making a concerted effort to appeal to BlackBerry users, consider an analogy to the board game Risk. RIM has a large army (read: users), but they’re all massed together in one spot on the map. They care about email, they care about exactly the sort of enterprise features Apple has announced for the iPhone, and they are known to be willing to pay several hundred dollars for a handset. A lucrative target that can be attacked all at once. And the BlackBerry is weakest where the iPhone is strongest: web browsing, music, and video. Compare and contrast with, say, a software platform like Windows Mobile, or a hardware maker like Nokia — their users are spread across a wide variety of phones and platforms. It was far easier to turn the iPhone into something almost every BlackBerry customer might at least consider than it would have been to make a lineup of iPhones that appeal to every Nokia customer. RIM doesn’t really have any lock-in other than user habits. The BlackBerry gimmick is that it works with the email system your company bought from Microsoft. Replace a BlackBerry with an iPhone (2.0) and the messages, contacts, and calendar events that sync over the network will be the same ones on the BlackBerry you just tossed into a desk drawer. In broad terms, BlackBerrys are optimized first for email; the iPhone for the web. What’s more important, an email client or a web browser? For most people, and perhaps even most current BlackBerry users, the answer is clearly the web. Many people in fact read their email entirely through the web. Unless you’re Richard Stallman, you probably don’t read the web through your email client. The iPhone would be a credible, useful device with just two apps: Phone and Safari. But it doesn’t just have those two apps. It has a slew, and they’re all better on the iPhone than the BlackBerry and the difference with regard to anything other than email is only going to get more stark once the iTunes App Store opens its doors. If nothing else, consider games, games, and games. As I wrote when the iPhone’s upcoming enterprise features were announced, the iPhone can do more BlackBerry-ish things than the BlackBerry can do iPhone-ish things. Apple doesn’t wait for someone else to knock one of their hit products off its throne or slowly run it into the ground (cf. the Motorola Razr) — they do it themselves. For six years pundits have been declaring that competitors would “soon” catch up to the iPod, but the iPod has never been a static target — over the same six years Apple has released significant new iPods every year. There are no signs that RIM has the engineering chops on either side of the ball — hardware or software — to compete with where the iPhone is now, let alone where it’s going to be. We know that Apple has an OS that can scale to take advantage of faster (and multi-core) processors, because OS X is doing that already. If a two-years-away 2010 iPhone might be like having a 2003 PowerBook G4 in your pocket, for RIM’s sake a 2010 BlackBerry had better be something more than a BlackBerry with a brighter screen. Correct answers: Batman, Star Destroyer.�↩

• Daring Fireball on May 9, 2008
• More Details
• Related News

★ The Unsatisfying State of Twitter Web Clients for the iPhone

Twitter and the iPhone seem, at a glance, a perfect match: bite-sized micro-content paired with the world’s best mobile web reader. But here’s the thing: there’s not yet a single good iPhone Twitter client. The main things I want in a Twitter interface on my iPhone, roughly in order: A readable, attractive list of tweets, with the ability to page back to previous tweets so I can catch up if I haven’t looked at Twitter in a while. A good text input field for posting, including a live character count and responsive typing speed. The ability to mark tweets as favorites. An easy way to create @username replies. A way to view a list of replies directed at me. There’s not a single available Twitter client for the iPhone that offers all of the above. And the single biggest problem is out of the hands of third-party developers: paging. The API only returns the 20 most recent tweets, and the optional parameter to request previous pages (20 tweets at a time) has been marked “Temporarily Disabled” for over six months. This means when you use a third-party Twitter client, you see the 20 most recent tweets in your stream, and that’s it. It’s a deal-breaking limitation for third-party clients, because when you read your stream via the Twitter.com web site, paging works just fine. It’s unclear what the rationale behind this API limitation is — I can find no public explanation for it from anyone at Twitter. If it’s to prevent API clients from overwhelming Twitter’s servers by paging back through the entire history of users’ timelines (say, for the purpose of building a database for a Twitter search engine), this could be solved by allowing paging, but limiting the results to the most recent N pages, where N is a relatively low number like 10. That would suffice for common case of someone wanting to catch up on the last few dozen tweets from the people they follow. This limitation isn’t just a problem for Twitter web clients. Unless Twitter re-opens this ability in the API, it’ll impose a serious limitation on the coming-soon-to-the-iTunes-App-Store native iPhone application Twitter clients as well. Given that third-party iPhone applications won’t run in the background, each time you launch such a client you’ll see the 20 most recent tweets and no more. Twitter.com You don’t need a “client” to use Twitter, of course. You can just use the regular Twitter.com web site, which renders fine in Mobile Safari. It’s not, however, optimized for display on the iPhone. At its default size, it’s far too small to be readable: You can use the double-tap trick to zoom in on the content column, but you sort of have to double-tap at just the right spot near the top to get the entire column (including icons) sized perfectly. Once you’re zoomed in it’s a pretty good iPhone Twitter display: it looks pretty good, includes user icons, and displays 20 tweets per page. It also includes “Newer” and “Older” buttons at the bottom of the list for paging. At the end of each tweet are two buttons: a star for marking favorites and an arrow for creating an @username reply. However, at just 18 � 18 px, these buttons are far too small to be usable on an iPhone’s touch screen. Apple, in the iPhone Human Interface Guidelines for Web Applications, recommends that controls have a tappable area at least 44 px high.1 (For example, the back/forward/etc. toolbar at the bottom of the screen in Mobile Safari is 44 pixels high.) In terms of area, an 18 � 18 px button is just 16 percent the size of a 44 � 44 px button. But what really kills the usability of these buttons in Mobile Safari is that you’re typically viewing them scaled down. Twitter.com’s tweet list, not including the user icons, is 470 px wide; the iPhone screen in portrait mode is just 320 px wide. When zoomed to the width pictured above, these buttons are just 10 or 11 px wide. You’ve got to zoom significantly to use these buttons on the iPhone. For posting, the Twitter.com interface is a disaster on the iPhone. It works, but the size is all wrong. When you tap in the field to begin writing, Mobile Safari zooms the view to a width that cuts off half the field. If you zoom back out to a scale where the entire field is visible, the text is ludicrously small. Worse, typing in the field is dreadfully slow. The JavaScript Twitter.com uses to display the live character count works just fine in a desktop browser, but it’s way too slow for the iPhone. Worse, you can’t even see the character count while typing because it’s off the screen if you’re zoomed in close enough to make the text in the field legible. In short, Twitter.com is a perfect example of a web page that renders and works correctly in Mobile Safari, but which provides a user experience far inferior to what could be done with an iPhone-optimized web site. It seems weird that sites like Facebook and Amazon, which do so much more than Twitter, have iPhone-optimized interfaces, but Twitter does not. m.Twitter.com Twitter also provides a “mobile web” interface — a web interface for phones with rudimentary browsers. It used to be that to access this interface, you used a different URL: m.twitter.com. That was good. A few weeks ago they changed this, however, and Twitter is now using user-agent sniffing to automatically serve the mobile web interface to Mobile Safari, even when you go to the regular twitter.com domain. This is bad. You can change which version you’re getting in the footer at the bottom of the page. (Even if you don’t have an iPhone or iPod Touch, you can try out the mobile interface by using Safari’s Develop menu to set your user agent to Mobile Safari.) This setting is remembered with a cookie, but it doesn’t take long for the cookie to be forgotten. With the old scheme, where the standard and mobile web interfaces were specified by different URLs, you could (and I did) bookmark both separately, for use in different situations. The key appeal of Twitter’s mobile web interface is that it is very fast to load. One obvious reason is that doesn’t display user icons. Another is that the entire page is almost self-contained — the CSS is inline, it doesn’t use any JavaScript, and the only image is the small Twitter logo. It also only loads 10 tweets at a time. There’s no need for zooming, and typographically the display is spot-on — perfect use of Helvetica for the iPhone. (Unless you rotate the screen to landscape: if you do, the font blows up to giant size and stays there even if you rotate back to portrait.) There’s no way to mark favorites or create @username replies. The editing interface for the mobile version stinks. Most obviously, the field is way too small: it’s just one line high and doesn’t even extend to the full width of the iPhone screen. Typing performance is good, but that’s because it doesn’t use JavaScript at all, which means it doesn’t provide a character count. It does stop you from typing any additional characters once you hit the 140 mark, though. (It’s just a text field with the maxlength attribute set to 140.) A notable omission from the mobile interface is a way to view your @yourname replies. In the standard web interface you just tap the Replies tab, and all the third-party Twitter web clients support this as well. The 10-tweet display is a bit limiting, but like the standard Twitter web interface, the mobile interface supports paging. Better to have just 10 tweets at a time but with paging than 20 tweets at a time and no paging (as with third-party clients). EDGE network performance ranges from “kind of slow” to “really damn slow”; when tending toward the latter, the difference in loading Twitter’s mobile interface and standard interface is dramatic. That’s why it stinks that it’s set with cookie rather than the URL: if you’re currently set to use the standard interface (because, say, you were on Wi-Fi) but now wish to use the mobile interface (because you’re now on EDGE), you have to wait for the entire standard web interface to load, scroll to the bottom, zoom in, and click “Mobile”. With the old way, (a) they were bookmarkable, and (b) you could keep them open in two separate tabs at the same time — making it easy to use the standard Twitter interface most of the time, while switching to the mobile web interface with just two quick taps for use on EDGE. Hahlo Dean Robinson’s Hahlo is my favorite third-party Twitter web client. If it weren’t for the no-paging limitation in the Twitter API, I’d use it as my primary iPhone interface to Twitter. My biggest complaint about Hahlo itself is that its initial screen is a list of menu items, not a list of tweets. Perhaps this seems like a ticky-tacky thing to complain about, but the main thing you want to see when loading Twitter are the tweets. Waiting for the page with the menu to load before you then wait for the page with the tweets to load is annoying. (There’s a workaround for this, though, which I’ll get to in a moment.) Plus, the menu commands are a bit oddly named: “My Timeline” is a list of your own tweets. Twitter’s own parlance for this is “Archive”. Hahlo’s second menu item, “My Friends Timeline”, is what you want: a list of the 20 most recent tweets from the people you follow. But because Hahlo is entirely Ajax-driven, the URL doesn’t change from http://hahlo.com/, which means you can’t bookmark the tweets page you see after tapping “My Friends Timeline” on the main menu. However, you can get a bookmarkable list of tweets from Hahlo by loading this URL: http://hahlo.com/friends_timeline. Most users will never realize this is possible, because there doesn’t seem to be a way to navigate to that URL from within the Hahlo UI. Once you do see Hahlo’s tweet list, it looks nice. Good size, good spacing, good use of Helvetica. It includes user icons and has reasonably-sized buttons for marking tweets as favorites and for creating replies and direct messages to the author of a tweet. Editing is where Hahlo is a Viking. Typing speed is acceptable — not great, but good enough — and the best of any Twitter web client with a live character count. In most other iPhone clients with a live character count, typing feels dreadfully sluggish. Hahlo’s character count is mostly accurate — which means it’s best-of-breed for iPhone Twitter web clients.2 iTweet Colby Palmer’s iTweet is very much comparable to Hahlo. The most notable difference is the reversed light-on-dark color scheme. (I like it.) Like Hahlo, it offers a very nice tweet display, replete with nicely-sized per-tweet buttons for marking favorites and creating replies. iTweet’s UI is more sensibly laid-out and named than Hahlo’s. At the top of the tweet list are three buttons: Menu, Refresh, and Post. (Hahlo uses the word Update instead of Post, which is ambiguous: Update could just as easily be used to mean Refresh, in the sense of “Update this list of tweets.” You shouldn’t have to press a button to figure out what it does.) iTweet’s editing field looks good. Appearance-wise, it’s my favorite of any client — the text is eminently readable, slightly bigger and bold. iTweet also provides a live character count, but unlike with Hahlo’s, iTweet’s JavaScript hooks result in terribly sluggish typing speed. It doesn’t even come close to keeping up with my two-thumb typing speed, which is rather slow to start with. It doesn’t lose keystrokes, but the UI feedback for each keystroke is delayed by a fraction of a second, completely ruining the feedback that makes the iPhone’s on-screen keyboard tolerable. PocketTweets Justin Williams and Bobby Andersen’s PocketTweets uses more gradients than any other iPhone Twitter client. The icons look good, as one might expected from Mr. Andersen, but the text is too small throughout the entire UI. PocketTweets correctly defaults to showing you a list of tweets rather than a menu, and like iTweet, offers buttons for marking favorites and replying. However, once you mark a tweet as a favorite, PocketTweets doesn’t seem to allow you to unmark it. Also, the vertical Favorite/Reply button layout is worse than the horizontal layout in Hahlo and iTweet — I find myself inadvertently invoking Reply when I mean to tap Favorite. Another annoyance is that PocketTweets doesn’t create links from @username instances in the text of a tweet. In other clients you can tap on @username to display a list of that user’s tweets — useful for picking up the context of a reply. PocketTweets’s editing UI is also too small; it feels unnecessarily cramped. Typing speed is acceptable (on part with Hahlo), and it provides a character count. Unlike Hahlo and iTweet, PocketTweets doesn’t enforce the 140-character limit in the field. With Hahlo and iTweet, once you hit the 140-character mark, you can’t enter additional characters in the field. PocketTweets lets you run long, trusting you to notice the greater-than-140 character count. I like this design — it allows you to finish your sentence and then go back and edit the message to get under the limit. Sort of like writing an article with a word count — you wouldn’t want your word processor to stop accepting input once you’ve reached the limit. One last, truly minor niggle: the name “PocketTweets” is too long to fit as a web clip name on the iPhone home screen. It gets truncated as “Pocke…eets”. PocketTweets pre-dates the iPhone web clip feature, but it goes to show that iPhone app names need to be short and sweet. Thincloud Last and least is [Thincloud], from New Leaders. For reading, Thincloud’s font is too small, the text wraps back underneath the user icon on long-ish tweets, and there’s no way to mark a tweet as a favorite or automate a reply. For posting, there’s no live character count or enforced limit — Thincloud will let you blow past the 140-character mark with nary a warning, and you won’t notice until you see your truncated tweet in the list. (On the other hand, it’s the JavaScript for the character counting that seems to slow the other clients down; typing speed in Thincloud’s editing field is the fastest of the bunch.) SMS Twitter was conceived from the outset as a service for mobile phone users, even those with ridiculous old-timey pre-2007 phones without web browsers, using SMS. Twitter’s 140-character limit on status updates is a result of the 160-character limit of SMS. For reading tweets, Twitter might work OK via SMS if you only follow a very small handful of relatively quiet friends. But if you follow even just a few dozen people, I can’t even imagine how annoying it would be to have an SMS alert jingle your phone every time someone updates. To post status updates via SMS, you associate you mobile phone number with your Twitter profile (on your Twitter.com account settings page), and then send messages to the short code 40404. Typing speed is excellent in the iPhone SMS app, but, of course, you don’t get a character count. One technical advantage to posting tweets via SMS is that it works well even with sketchy signal strength or when Twitter’s web servers are under duress. Via SMS, I was able to post live updates from the hall in Moscone West during the Macworld Expo keynote in January. (Given that Twitter’s web servers were mostly down during the keynote, however, it’s questionable whether anyone was able to read them until afterward.) So If ever there was a web app that could be — should be — better on the iPhone than on a desktop browser, Twitter is it. But it isn’t. Twitter.com is the best site for reading tweets, even though it’s not iPhone-optimized at all, simply because it allows for paging. But it’s the worst site for posting. Hahlo and PocketTweets are the best for posting, but because the Twitter API doesn’t allow for paging, no third-party client is good for reading. The result is completely unsatisfying. Using one Twitter client for reading and another for posting is like getting your sandwich at Burger King and your fries from McDonald’s — convenience is the who