The Case for a $49 Apple TV

Rumors of Apple releasing a TV have surfaced once again… it’s apparently the new Verizon iPhone. I bet they have a few prototype TVs hidden somewhere in Cupertino, but I wonder if their short-term strategy is something much less sexy—a dirt cheap Apple TV.

As many have pointed out, the TV industry is a mess of commoditization. Apple could be working toward a hardware/software differentiation strategy similar to what’s driving their industry leading profits in computers and mobile devices, but the logistics of bringing a TV to market just don’t seem to make sense for Apple. They do, however, have this amazing technology called AirPlay that makes the TV somewhat irrelevant once the user plugs in the tiny Apple TV.

The current Apple TV sells for $100, which is actually pretty cheap for such an amazing piece of technology. But $100 is still too high to be an impulse purchase, even for the throngs of iOS users who pay $200+ for an iPhone and thousands of dollars to connect that device to the rest of the world. More so for those who buy an iPod Touch or iPad expecting it to be a one-time purchase.

Apple, under the leadership of Tim Cook, has done an amazing job leveraging pre-purchase contracts and economies of scale to drive down the cost of hardware. According to iSuppli the Apple TV cost Apple around $60 to manufacture when it first launched last year. iSuppli is having to guess as to what exactly Apple paid for components, but they do attempt to account for the special pricing Apple is able to negotiate. Though not accurate, it at least gives us a ball park number to work with.

Looking at the bill-of-materials there isn’t a lot of room for Apple to dramatically drop the cost, but most of the big ticket items on that list are the sorts of components that drop in price over time. And keeping the hardware exactly the same means the manufacturing partners and component suppliers don’t have to ramp up new processes. It might be a stretch, but after a year on the production line, I bet Apple could make a small profit selling the current A4 based Apple TV for just $49. But why would they?

Jobs stated rather plainly at D8 that set-top-boxes don’t have a viable go-to-market strategy. They are given away for free or rented at a nominal cost by cable and satellite TV companies. Nobody wants to buy a set-top-box. Apple could drop in an A5 processor, lots of RAM, 16+GB of storage and market it as some sort of gaming console meets set-top-box, but with AirPlay you don’t really need beefy hardware constantly hooked up to the TV.

I’ve been thinking quite a bit lately about the concept of a “thick client.” Over the past few decades as Moore’s Law has been pushing hardware improvements logarithmically, the gatekeepers of the Internet have been thwarting and throttling networks. And now we’re increasingly moving toward ubiquitous internet connectivity, but the mobile web is being built by many of the same gatekeepers and faces even greater tech challenges. I hope to write more about this soon, but the bottom line is that the idea of a true thin client makes less and less sense. Why offload all the work to the server when we all carry incredibly powerful computing devices in our pockets? Similarly, why do we need a beefy Apple TV when the iPad 2—and soon the next iPhone—are quite capable on their own.

A few days after returning from WWDC, I loaded the iOS 5 beta onto my iPad 2 and Apple TV. The experience of playing RealRacing 2 HD over AirPlay completely blew my mind. The iPad acted as the controller and the graphics I saw on my 1080p TV looked as good or better than what we saw early in the current generation of dedicated gaming consoles.

With iOS eating its lunch in mobile gaming, Nintendo recently showed off the successor to the amazingly successful Wii, the Wii U. Guess what? iOS 5, AirPlay, and the Apple TV will combine to give a Wii U like experience when iOS 5 launches this fall. The Wii U isn’t expected to ship until mid 2012. Throw in a few more iPhones or other iOS devices and you have the full on party mode Nintendo was proposing as the future of gaming. The iOS platform already has quite a few AirPlay enabled apps and that number will grow quickly as developers see the full potential of iOS 5.

But the bigger question remains—why would Apple sell a device on such a thin margin? I think the answer is two-fold. First, a $49 Apple TV would be an incredible, no-brainer accessory to devices running iOS 5. And though margins would be thin on the device itself I think it would help drive sales of iOS devices and propagate iOS platform lock-in. Second, I think the low price would give Apple momentum in the living room. Without a clear strategy for selling billions of dollars in high-margin set-top-boxes, why not grease the wheels a bit with a trojan horse that may help create an opportunity while at the same time pushing sales of their ridiculously profitable mobile devices?

I have no idea what the long-term living room play is for Apple, and I’m not sure it’s clear to them either, but I’m more and more convinced that a cheap Apple TV would be a boon to the entire iOS ecosystem.

The Eleventh App

In his post on the 37signals blog, David Heinemeier Hansson makes a very good point about the small number of mobile apps most people actually use regularly. If most of us use just ten or so apps on a daily basis, do we really need hundreds of thousands of apps? His answer is a rather emphatic no, but I think he’s having trouble seeing the forest for the trees.

As an iOS developer I’ve spent an inordinate amount of time thinking about the market for apps. When the App Store first launched in July of 2008 I was absolutely blown away by the hundreds of apps available on day one—as was Apple, from what I’ve heard. Then a month later when my first app launched I was dumfounded to see the total number of apps already pushing into 5-figures. And a few months after that, 6-figures. And before the platform is even 5 years old that number will surge past 7-figures!

We’re obviously in the middle of a boom, and in any boom there’s going to be excess and redundancy, but are 499,999 of the 500k apps available on the App Store excessive and/or redundant? Obviously not. Can other mobile platforms be competitive without 500k apps? Absolutely! But here’s the really interesting question to ask: what specific apps does a mobile platform need to be competitive?

I think it’s telling that David says he only uses/needs ten solid apps on a daily basis, then goes on to list nine apps Apple baked into iOS (Safari, Camera, iPod, Clock, Weather, Photos, Messages, Mail, and Maps) and two apps from the App Store (Echofon and Bloomberg). So, he’s actually at eleven apps, but then backs off saying that he’d be fine reading Bloomberg in a browser. That leaves Echofon, a Twitter client, as the one 3rd party app David just can’t live without.

Well, WebOS, Windows Phone 7, Blackberry OS, Android, and even Meego all have the core apps covered as well as some sort or Twitter client. So, what is it that’s so magical about the iOS App Store? It’s that eleventh app.

Like David and many other iOS users, my tenth app is a Twitter client, Tweetbot, but just a few weeks ago that tenth app was Twitterrific and I’m actually hoping that with improved support for lists, Twitterrific will soon be my tenth app again. I do, however, have an eleventh app—Reeder. I could probably use Google Reader in a browser if I absolutely had to, but I REALLY don’t want to. Oh, and Black Pixel recently acquired Net News Wire, so my eleventh app might even be changing in the near future.

Nine core apps, a Twitter client, and a Google Reader client, surely that’s all a mobile platform needs to be competitive? Hardly. I shouldn’t have even conceded that a Twitter client is the tenth essential app for mobile platform success, many would argue it’s a Facebook client or something else entirely. But saying that a Google Reader client is essential to mobile platform success is laughable. To me, however, that eleventh app really is essential. I’d never switch to a mobile platform that didn’t have a fast, rock-solid Google Reader client.

Like most iOS users I could rattle off another 5-10 apps I use on a weekly, if not daily, basis and even that list is constantly changing as new apps come along and developers iterate on existing apps. Are those additional 5-10 apps essential and irreplaceable? Probably not, but my mobile computing experience would undoubtedly suffer without them.

If we took a poll of all iOS users and asked for a list of the eleven absolutely essential, can’t live without apps I bet we’d end up with at least a thousand different types of apps. A doctor might include a medical imaging app, a musician would likely include a multi-track recorder or some other musical sketch pad, an artist would include an actual sketch pad app, a builder might list an estimating app, a freelancer a time-tracking and invoicing app, and so on.

And that’s just app types. If the poll asked for the names of specific apps, I bet the list would head well into 5-figures and might even break 6-figures. That “builder” I mention above is a generalization of an entire category of professional iOS users and each individual in that group has different needs and expectations. The estimation app that’s essential to a residential builder might be completely useless to a commercial builder.

We can each argue convincingly that the apps we use daily are the essential apps that make a platform, but the truth is, each app is just a tree and the magic is in the forest.

Winning the Mobile Platform Race

I’m not much of a racing fan, so forgive me if the analogy breaks down rather quickly, but it struck me today that Apple’s disciplined approach to building its mobile platform looks somewhat like a well managed racing team. While competitors have been taking risks and cutting corners in an attempt to catch up, Apple has been meticulously preparing for the race ahead.

RIM bolted a spoiler and painted some racing stripes on a dated car with a winning pedigree. Without a major overhaul in recent memory, the car’s age and sustained abuse have become more and more apparent as competitors shift into second gear. What was a very strong lead early in the mobile platform race has been completely squandered. They did go out and buy another car, but it also needed an overhaul and they didn’t have the patience to finish before tossing it into the race. After an embarrassing crash and burn they’re still pushing ahead, but RIM needs much more than a quick pit stop at this point.

At just the right time, Palm abandoned its old, crufty car and built a new one from the ground up. The car looks amazing on the outside, but their new engine just hasn’t delivered. With time and lots of tweaks the engine should perform well, but Palm didn’t have the cash to stay in the race long enough to get the car firing on all cylinders. Just when things were looking most dire, HP swooped in and bought the car—racing team and all. HP’s cash, branding, distribution, and other strengths may well keep the car in the race, but it will likely take another year or two for the car itself to perform optimally and by then who know where the competition will be.

Microsoft initially didn’t understand that the rules of the race had fundamentally changed and expected the new competition to crash and burn. As others picked up speed Microsoft tried the racing stripes and spoiler approach but soon had the good sense to scrap their old clunker. The new car shows lots of promise, but started so far behind it’s going to take a herculean effort to catch up. With deep pockets, determination, and decades of platform building experience, Microsoft is just the sort of company able to mount a herculean effort, but I’m still not convinced they fully understand the race they’re now in.

Google looks to have a great car in the race, but they’re forgoing tire changes, routine maintenance, and timely fill ups to try and catch Apple. They’re making up ground and things look great from the grandstands, but it’s only a matter of time before a long pit stop or two kills their momentum.

The other analogies are a bit of a stretch, but I really do think we’re in the midst of Google’s first major pit stop. They admittedly rushed Honeycomb to market and are now having to fix things that would have best been done right the first time. They have a strong, well funded pit crew and may be able to get back in the race quickly, but the floundering of Honeycomb based tablets and slow growth in 3rd party tablet apps don’t bode well.

The next major pit stop for Android may be the elimination of physical buttons. Rumors have been floating around that the next Google phone (Nexus 4G?) wont have Android’s current physical buttons. If true, I’m very curious to see how the buttons are emulated and/or eliminated in software. Will all existing apps need to be updated? Will Ice Cream Sandwich automagically work on devices that have buttons just as well as those without? Will the transition confuse and frustrate users?

The Android team has proven itself able to iterate on features like Cut/Copy/Paste on the fly, but something as fundamental as removing the physical buttons may prove to be a slow, painful pitstop. And if not the physical buttons, who knows what other legacy implementation or hastily coded API may send the pit crew scrambling.

Google may well mitigate any major technical hurdles, but there’s still the threat that other corners they cut along the way will come back to haunt them. Oracle has presented a very strong case that Google “knowingly, directly and repeatedly infringed Oracle’s Java-related intellectual property”. It’s rather ironic that a dispute over “open” technologies may be Android’s biggest challenge.

Apple, on the other hand, had the luxury of defining this entire category and many of its fundamental concepts years before some other platforms had a single line of code written. Apple’s car then is a stripped down, painstakingly rebuilt piece of engineering art based on decades of hard-won race experience. They didn’t start with a clunker in OSX, but they still had enough of a lead on the competition to carefully consider the strengths and weaknesses of OSX and build iOS on a solid foundation.

iOS is by no means perfect, and Apple has and will continue to make pit stops along the way, but that’s actually my point—Apple’s disciplined approach to iterating on iOS and its OSX underpinnings allows them to take productive, well-timed pit stops while the competition continues to scramble and take on undue risk. As John Gruber put it: “This is how Apple rolls — steady, relentless, incremental progress.”

Twitter’s Unfortunate PR #Fail

In light of Twitter’s amazing integration in iOS 5 and conversations I had with Twitter employees after their developer meetup, I’d like to present a “glass half full” reinterpretation of recent events.

“…developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no.” -Ryan Sarver on Twitter Development Talk

Reinterpretation: We’re about to show you some really great stuff at WWDC, please don’t all go out and create new client apps just because we’ve made it easier to do so.

That’s oversimplifying the point, but I think that the forthcoming iOS integration may have played a part in the timing and tone of Ryan’s post. Twitter’s deep integration into iOS 5 is a game-changer. As MG Siegler put it in a post on TechCrunch: “Apple Just Handed Twitter The Keys To The iOS Kingdom.”

What most people took away from Ryan’s post was that Twitter was trying to take over the Twitter experience for monetization purposes and would be actively pushing 3rd party client developers away. In person, however, Ryan was rather effusive about TweetBot and other client apps. I may have been reading too much into things, but my takeaway was that Twitter has no intention of squashing existing Twitter apps built by lifestyle businesses (Twitterrific, TweetBot, etc).

Those who read the post as a threat to Uber Media and other VC backed startups were probably much closer to the mark. When Twitter bought Tweetie and released the official Twitter app in 2010 it was clear they intend to own the primary experience of Twitter. Even more so this year with the purchase of TweetDeck. Whether this is part of their long-term monetization strategy, or a just another way to “optimize for user benefit and create an awesome experience,” it’s clear that they have been and will continue to invest heavily in their own web and native apps.

I honestly think Twitter did developers a favor by laying things out so clearly. Building a Twitter client has been a sort of “hello world” project for many developers. But competing with existing apps, especially Twitter’s, is going to be a losing proposition for most. Much more so for those who take on debt or funding to do so.

I do, however, think the post came off rather aggressive and Twitter didn’t do a very good job taking back control of the message as the press and developers had a field day with the possible ramifications. Then this:

“Apps that you use to access your direct messages will ask for your permission again. By the middle of June, applications that do not need access to your direct messages will no longer have it, and you can continue to use these apps as usual.” -Twitter blog

Reinterpretation: We have lawyers now, and those lawyers are telling us direct messages will be a huge bag of legal hurt unless we deeply change our approach.

From congressmen to Twitter’s own employees, DM Fail has been an issue for Twitter since it’s inception. However, I don’t think the legal liability of direct messages (now apparently just messages) fully set in until the trickle of subpoenas turned into a flood in 2011. For legal reasons Twitter hasn’t been very open about the frequency and source of message subpoenas, but we all heard about the Wikileaks Subpoena and I get the impression new ones are coming in on a weekly, if not daily, basis.

Though many developers, myself included, took this as evidence that Twitter would be actively pushing away existing client apps, I now think this was a legal maneuver more than anything. Even the timing of it smacks of fear. Twitter initially gave developers just a few weeks to adapt their apps to the new authentication guidelines. By publicly acknowledging the fact that messages aren’t as private as most users assume, Twitter had to quickly close the window before a rogue app took advantage of the situation.

From the aforementioned TechCrunch article: “But Sarver says this is not about screwing over those apps. ‘It honestly has nothing to do with making it harder for them,’ he said. Instead, this authentication change is about protecting users.” If he were being completely honest, I think he’d have to mention something about protecting Twitter as well, but his point stands that the decision wasn’t made with the explicit intention of pushing away existing client apps.

“But now literally every iOS developer can be a Twitter developer. We think every app is going to benefit from instant personalization from this social layer, from gaming to utilities to enterprise apps.” -Ryan Sarver in an interview with All Things D

What’s unfortunate about Apple’s unveiling of Twitter integration at WWDC is that it came at a time when most developers in the iOS ecosystem were questioning Twitter’s relationship with developers. I’m not sure Twitter fully understood the backlash to their two major API related announcements in the Spring. iOS developers talk, and even if we didn’t, John Gruber and other members of the tech press made it clear what we should think about the situation.

So, the announcement at WWDC hit many of us like a big wet kiss from an estranged lover. What the hell? Is this for real? Can I trust you or will I just get burned again?

Some of us are trying to take a more optimistic view of things while others have been so badly burned it’s hard to give Twitter another chance. My hope is that in the months preceding the launch of iOS 5, Twitter will do a better job communicating with developers and better explain some of its prior comments. This is a huge opportunity for both Twitter and the iOS ecosystem, I’d hate to see bad PR stifle excitement and innovation.

Orchestrating Magic

I’ve really tried to like The Daily. I want ambitious projects to succeed on iOS. I want to see the delivery and consumption of news reinvented on the iPad. But I just don’t look forward to launching The Daily. It hasn’t become part of my daily reading routine.

A distaste for the editorial voice may be part of my hang-up, but I do actually enjoy many of the stories when I take the time to launch the app. However, that’s where I frequently get hung-up… taking the time to launch the app.

I’ve been hesitant to speak my mind on the app because I know what it feels like to work incredibly hard on something only to have it torn apart by armchair quarterbacks. But I just can’t hold back any longer.

Instead of ripping apart the hard work of my friends and colleagues, I’m going to offer a very specific solution for solving one of the biggest complaints about the app. I know a lot has been written about this, and I’m likely repeating things that were said months ago, but the app has now seen several updates that failed to properly address the issue, so I think it’s time to bring it up again.

When I launch an app on any computing platform, I do so with very specific intent—to read, to catch up on Twitter, to edit a photo, etc. Anything that comes between me and that intent quickly becomes frustrating, especially when I launch the app often. This has always been the case with computers, but it’s especially apparent on mobile devices such as the iPhone and iPad. I don’t want to wait for things to load, I don’t want to navigate through a messy jungle of options, I want to get right to doing whatever it is this particular app does well enough that I bother launching it in the first place (further reading on that subject: Tapworthy).

And guess what? Many iOS developers have gone to great lengths to satisfy that expectation. I remember launching Reeder for the first time on my iPhone and being absolutely shocked at how quickly my feeds loaded. My expectation had been set by other slow RSS apps which discouraged me from spending much time with them on my iPhone. Reeder changed that.

Now, you could argue that The Daily is a different type of app—people launch The Daily with the expectation of spending some serious time in the app. That may be true (though I doubt it is), but that intent doesn’t change the expectation set by the launch speed of most well built apps on the platform. The launch experience of The Daily is about as far as I’ve seen an app stray from that expectation.

I could go on and on about why this is bad and why it’s not acceptable even for a “newspaper app,” but I’ll cut right to the case and offer my thoughts on a potential solution. You may want to download and experience the app yourself if you haven’t already, or just read this: The Daily Wait.

Though many would argue with me here, I don’t think the launch animation is necessarily a bad thing. It’s a pleasant animation with a nice branded look and sound. Like the Twitterrific chirp, the sound will cue most people in the room as to what you’re up to, and I’d argue there’s even a pleasant psychological cue, kind of like the crinkle of a physical newspaper. There’s a certain sense of comfort in those subtle aspects of a routine. The key is to use that sequence as a kind of slight of hand, or “magic” if you will. The user gets a little brain treat while the app is racing to deliver content in the background.

When the app launches, the first process that should spin up isn’t the launch animation, but a request to deliver the current day’s front page and table of contents. Then, in a separate thread start the animation sequence. I’m not sure this is technically feasible, but if it is, here’s why I’d do it that way…

The carousel is a fun bit of UI (at least in theory, it’s still a bit laggy and jittery for my taste), but there’s just no way to quickly deliver enough content to make the carousel usable. The front page and table of contents, on the other hand, could likely be fully delivered in the 4-5 seconds from the launch of the app to the end of the launch animation. Sending users directly to the front page (or potentially a redesigned table of contents, but I wont get into that) will make it feel as though the app has been magically filled with content.

The user can start reading the front page and even swipe to the table of contents instantly. To make this work, the left to right swipe to go to the back of the issue should be permanently disabled. Just after launch it’s unlikely that the last page of the issue will have been delivered, and even if that could be prioritized, I’m just not sure swiping from the front cover to the back of the issue is the best interaction.

Next is the prioritization of content delivery. I have no idea if the backend of The Daily currently allows individual stories to be delivered out of order, but if not, I think re-working the backend to enable this should be a top priority. The millions of dollars spent on development and content creation has been significantly tarnished by the UX. Fixing it would likely be cost effective as evidenced by Flipboard: Flipboard Triples Daily Usage in Two Months After Speed Improvements

Anyhow, back to content delivery. The first stories that should be delivered are the ones highlighted on the front page. It’s likely that users will be taken by a headline and jump right to one of those stories. In the few seconds it takes to read the headlines the full content of those stories could likely be delivered (though large files like video and 360º images should probably be separated from the main text/photo content so as not to slow that process). If the user does tap on one of those headlines, BAM, they’re reading the story, no loading spinner, no delay, just carefully orchestrated magic.

If the user doesn’t tap on one of the main stories, there are a limited number of possible interactions, so the next step is to prioritize those options. If the user swipes left to right, the page moves with their finger, but bounces back when let go—indicating that they are at the beginning of the issue. If the user swipes right to left, they are taken to the table of contents which has already been delivered.

Another option is for the user to tap on one of the section headings. I’d guess that most people are at least somewhat habitual in their reading and will either go directly to the table of contents (which is already accounted for) or jump to their favorite section. It would be trivial for The Daily to start logging which section shortcut, if any, is tapped most often on a particular device. After launching the app a few times, it should be able to reasonably predict which direction the user will head and prioritize the delivery of that content.

If the user typically swipes to the table of contents then just keeps swiping into the stories as if they were reading a magazine cover to cover, just deliver the content linearly. If the user always jumps directly to the sports section, it’d be best to start delivering the sports section right after the front page and table of contents have been delivered (even before the stories on the main page). The prioritization of delivery will be slightly different for each user, but will feel like magic to them all.

There will be times when the user inevitably strays from their typical patterns or are on a slow connection that delays the delivery of their favorite content. In this case some sort of loading screen will be inevitable, but the app better damn sure drop everything it’s doing and load that particular page as quickly as possible.

I’ll bite my tongue on further critique of the carousel view as the intended primary mode of navigation, but I will say that the app should only prioritize the loading of those assets if the individual user actually navigates to it frequently. Either way, it just too data intensive to be the spot where people land when the app first loads.

I know first hand how hard it is to build great iOS apps and I hope I haven’t been overly negative in this critique. The Daily is one of the most ambitious apps to have been created on this platform and though I’m quibbling about a few things I see as flaws, shipping such a complex app was, I’m sure, a superhuman feat. I’d love to see it reach its full potential.