Neil Mix

I’ve long been reticent to jump on the Applet tablet bandwagon because of a fatal flaw in the overall concept: key input. An onscreen keyboard doesn’t make sense: one-finger typing is too slow and the device is too big to be held for two-thumb typing. That leaves 10-finger laptop-style typing, but that requires the device sit in your lap with the screen tilted away from you, plus it provides no touch feedback. So you end up with either an iPhone-like slow input device without the portability, or an unfriendly keyboard that is no more portable than a laptop. Without a revolutionary advancement in key input, in my opinion this device is DOA.

But Apple isn’t likely to release a device with such a tragic flaw (are they?) so I think it’s a good bet they’ll revolutionize key input with the tablet. Which leads to the obvious question: how? The requirements are: you need to be able to give key input while standing up and cradling the device in one arm, and it must be relatively fast — fast enough to do creative writing, for example. Given that I see two options: handwriting or speech dictation. And speech dictation is out because no one wants a world filled with Macheads talking to their computers on public transportation, least of all Apple.

So that leaves handwriting recognition via stylus. Of course this has been tried before and failed, but Apple’s mechanism will differ in two key respects: 1) it will be really accurate, and 2) you will be able to write with the heel of your palm resting on the touch surface. (Ah, the beauty of multitouch.) So it will be just like writing on a pad of paper — without the ink smears.

So there’s my big tablet prediction. Can’t wait to see how wrong I am.

Prior to this past week, I’ve had several theories about the fabled Apple Tablet computer (in order from least cynical to most cynical):

• A brilliant new product with a revolutionary keyboard input mechanism
• An interesting product idea waiting patiently to become technologically feasible
• A really cool-sounding bad product idea whose keyboard input sucks
• A long-since failed product idea that just won’t die
• A series of individual, disorganized hoaxes with a common theme
• An active disinformation campaign designed by Apple to foil competitors and/or root out leaks

After the past week, just in case the rumors turn out to be yet another mirage, I’m adding one more to the end of the list:

• A conspiracy by tech blogs to drive traffic and increase ad revenues

I’ve heard the iPhone described as a computer that just happens to be a phone, and this is true from a hardware/software perspective. But how about from a consumer’s perspective? While most developers undoubtedly see the iPhone’s computing capability, I’d wager that “mass market” consumers see the iPhone as an entertainment device that just happens to be a phone.

It’s a question with important repercussions. We’ll get to that in a bit.

First, consider the attributes of entertainment media and compare to computer applications:
Media: pleasure-based, ages quickly, must be relevant, low margin, large audience.
App: task-based, ages slowly, must be useful, high margin, small audience.

So when you write an “app” for the iPhone, are you developing software or producing media? It’s a strange crossover hybrid, because the most successful apps are…both, really. The iPhone makes media more useful. Or does it make productivity fun? The lines are blurred.

But when it comes to how apps are sold, the answer is pretty clear. Fire up iTunes and observe how apps are seamlessly placed along-side music, TV, and movies. Notice too that app prices have dropped to accommodate larger audiences. As every iPhone developer knows, getting on the top 20 list is the key to sales. But there’s a lot of churn in that top 20, few apps stay there for long. So top apps are very current — here today, gone tomorrow. And the audience is fickle, which means predicting (or causing) popularity is, well, awfully hard.

This can have a tremendous effect on product development. If you’re building something productive, usefulness is no longer enough to be successfull — it needs to be fun, too. And you have to think in terms of a recurring product line rather than a single flagship product, or you’re unlikely recover your development costs.

But even more important is Apple’s relationship with you as a developer, and what it means to be an entertainer. They are the distributor, and you are now the starving artist. Imagine a long line of performers on a blustery morning waiting to audition for a major Broadway production. Now put yourself in that line.

A few developers will hit big and eventually earn esteemed status with Apple. But most will simply live in the crowd, creating products for fun or dreaming of stumbling across the-next-big-thing.

Developers are not used to being treated as a commodity, and accepting this reality means swallowing a lot of pride. But that is the reality right now — iPhone developers are a commodity, and Apple has plenty of room to err before it loses significant dev capital.

It’s amazing how much the Internet has changed the software development process. There’s now an entire generation of techies (including me) who were indoctrinated into the art of building software with a casual release process. Back in the old days, releasing software was anything but casual, because you’d put the bits in a box and put them on shelves to sit and wait for someone to buy them. But the web brings the customer to the software every time they use it, which makes traditional software release go all topsy-turvy.

It all starts with cost structure: in the ancient world when there was no Internet, how did you fix a product defect after it was released? Well, you put the fix on floppy disks and mail it out to customers. As you can imagine, that’s pretty costly. So if you release a product with a serious bug, you’re going to chew up a ton of money paying for what turns out to be a product recall. You know, like when a car has a safety defect and you take it into the dealer to get fixed. It doesn’t take much mental effort to realize that in this world shipping defects results in an unprofitable business. And thus software companies (the ones that succeeded, anyway) learned to be very careful when releasing product. This is where the term “GM release” comes from — the “Gold Master” CD on which the software was written to be mass-duplicated. Once the bits are written, they don’t get unwritten.

Along comes the Internet and its new-fangled web-apps, and suddenly it costs almost nothing to release a bug fix. That one little variable changes, and now the software development process is entirely different. The strict no-risk release process now loosens up a little, becomes more casual. Pretty soon, the “throw it against the wall” mantra becomes popular, and people start intentionally releasing unfinished software just to gauge market interest. Release-early release-often becomes an entirely new way of doing business.

For seasoned software developers, this change had a varied effect. Some got it right away, some didn’t. More interesting was the effect on corporate cultures. I remember from my time at Microsoft (early Internet era) how the entire corporate culture was built around the concept of bits-in-a-box. This new Internet craze had arrived, but many teams were applying old ways of thinking to the new problems. It’s not too surprising that they don’t fare well on the Internet to this day.

Of course the reverse happens as well. Having started my career building web applications, I remember the tough transition I had when I joined a company doing long-release-cycle software. I hadn’t yet learned the design skills, testing skills, and patience required to truly finish things off before releasing. I kept approaching implementation with a sense of urgency framed by the Internet, and my approach didn’t fit in with the rest of the team.

Any time you begin development on a new platform, one of the first things you need to understand is the release cycle. This is something that has tripped up many iPhone developers. The App Store doesn’t work the same way as releasing software on the Internet. Imagine a curmudgeonly long-time Apple veteran whose been through more OS builds than you have web sites. To him, waiting 4 weeks to get a bug fix out the door is pretty decent. And that perspective undoubtedly influences Apple’s approach to the App Store. Yes, Apple’s perspective on this is wrong, and it will eventually pose a serious problem for them. But for now, it’s sadly the app developer’s problem to solve. Design carefully, test for a long-time, and ramp-down quickly on changes prior to release. It’s not as fun and agile, but it’s doable if you plan for it.

Andrew Woolridge proposes an App Store for the web. Honestly, ever since Apple opened the iPhone App Store I’ve wondered why every platform didn’t already have its own version of the same. Trying to find software is generally a time-sucking, awful activity akin to mixing dough with a spatula. A web-based App Store would be awesome. The catch: how do you prevent it from ending up like download.com?

Imagine you’re the developer of a complex application with many moving parts. It’s been released, and by all metrics it’s a homerun: customer satisfaction is through the roof, new customers are flocking to it in droves, and the product is efficient and scaling well.

But there’s a bug in the system. It’s breaking things, but in a very small way. It’s not effecting the business bottom-line at all (although it could in the future). It’s easy enough to fix in isolation, but you’re not sure how your fix will influence other dependent components. And if this bug begins effecting the business, you’ll have plenty of time to fix it before it registers a serious impact.

What do you do? Wait, of course. You wait until either the bug presents a risk, or until you devise a way to fix it that presents no risk. When things are going well — beyond all expectations — the last thing you want to do is introduce risk where it’s not needed. Just sit on it.

Ok, now imagine you’re an executive at a large public company with millions of customers and tens of thousands of business partners. You have a products for which customer satisfaction is through the roof, and new customers are buying it in droves. You are decimating the market. Profits are through the roof and shareholders couldn’t be happier.

But, some of your business partners are telling you that there’s a problem. This problem isn’t really effecting your business, and fixing it carries the risk of impacting other parts of the product and business in undesirable ways. And, despite the fact that your partners aren’t fully satisfied, they’re continuing to work with you and tons of new partners are scrambling to set up partnerships.

You see where I’m going with this, don’t you?

When I say “please stop whining about App Store review”, what I’m really trying to say is: focus your effort on something more productive. Apple hears you, they’re just not going to do anything about it. (Or at least not what you want them to do about it.)

The classic argument for loosening App Store review is that Apple is harming their product more than they’re helping. By hand-cuffing developers they’re preventing bug fixes from going live, they’re making developers unhappy, etc — you know the story. And then, the argument continues, that hurts developers and customers both indirectly and directly.

Here’s the problem: the numbers disagree. There is no metric or indicator I’ve seen that demonstrates that the App Store review process is hurting Apple in any way. So from a business perspective why should Apple make any dramatic changes to its review process? All that does is add risk they can’t quantify. There’s a risk they know about, and it’s not yet harming the business. They’d be crazy to act on that risk in the name of adding an unknown (and potentially much larger) risk.

So if you want Apple to change its ways, you can do the following: 1) demonstrate that there is actual risk to the business, or 2) suggest ways to fix the problems that don’t introduce risk.

Opening the iPhone for unrestricted access isn’t going to happen. Consider the history of the PC with spyware, viruses, and worms. Or consider phishing and lack of recourse on the web. Yes, Apple is the sole gatekeeper. In some cases, they’ve abused that power. In the vast majority of cases they’ve benefited customers, as demonstrated by the fact that the iPhone’s App Store isn’t a vast wasteland. They have zero incentive to open up.

To fix the App Store, you have to answer this question: how does one open access for legitimate, quality developers while keeping the scummy or incompetent developers at bay? There are answers, and I’d wager that Apple is already working hard on new and innovative solutions. But the house isn’t burning down, so there’s no rush those solutions to market. They may never arrive, depending on how things go.

So until the App Store is fixed, discontent developers are best-served doing something productive with their angry energy. Go develop apps for other platforms. Or write up enhancement requests with inventive solutions. While it may not seem like Apple listens, they do. The just don’t always respond.

One thing that may not have been clear from my last post about Joe Hewitt leaving iPhone development is that I don’t disapprove of his actions. Quite the opposite, really, I applaud him for showing the world his beliefs through his actions rather than his words. He describes his concerns as philosophical disagreement, which I think is exactly right. Rather than ridiculing the review process while continuing to reap the rewards of iPhone and its App Store, he’s chosen to move onto something more appropriate for him. If more developers acted as Joe has, perhaps Apple would get around to fixing the flaws in its process. (And there are plenty, lest there be any doubt.)

Joe Hewitt garnered some remarkable press (for a developer) today by going on record saying he quit developing Facebook for iPhone because of Apple’s App Store review process. I am unimpressed. (With the article, that is — not with Joe and his paparazzi. Damn Joe, how’d you get TC in your pocket?) And I’m qualified to weigh in on this topic because…I wrote Pandora Radio for iPhone? Weak, but I’ll take the podium now, thank you very much.

Now, I understand that dealing with app review is a pain. No one likes it, it’s an imperfect process, it’s often arbitrary, blatant mistakes are made, etc etc. While some prognosticate a review-free ecosystem that is far superior to the status quo, let’s remember that such predictions are speculative, because no such mobile app ecosystem exists.

Read that last sentence again, because there’s a subtle trap in there. See it? Here’s a hint: name the platforms for which indy developers were writing apps prior to the App Store’s existence.

The moral of the story: the only reason indy developers are writing mobile apps today is because Apple let them when no one else would. So yeah, that review process is awful. But compared to the alternatives, the iPhone was unbridled freedom. Despite this, from day one we’ve heard endless harping about the evil review process and how bad it is for Apple and customers. Call it The Developer’s Thank You. And yet 100k apps later I’m still awaiting the flood of developers leaving the iPhone for greener pastures, and the flood of customers leaving the iPhone for other devices. Well, OK, there’s Joe Hewitt and Mike Arrington.

Apple is all about taste. The App Store is too. And there’s one thing I’ve learned from years of working for people with exceptional taste: to those without taste, tasteful decisions seem arbitrary and capricious. If you think the App Store would be better without a review process, ask yourself which criteria you’re judging. Can you honestly claim that the iPhone would be more tasteful if there was no review process?

Apple serves its customers, not its developers. And given Apple’s success with the iPhone product, it’s pretty hard to argue that they’ve been somehow missing the point. Quite the opposite. It’s always amusing to watch people question the sanity of product decisions for an insanely successful product. Are you crazy? This thing went off like a rocket ship! It’s hard for me to point to any iPhone product decision as an abject failure. It’s not about developer convenience. To misquote James Carville: it’s the product, stupid.

There may come a day when Apple’s review process causes it to lose customers. And if/when that day comes, I’m sure we’ll see Apple change its ways. Until then, can we give it a rest with the whole App-Store-review-process-sucks meme? The horse is dead. Hell, the whole farm is dead. Clearly, Apple and its detractors do not see eye-to-eye. The review process is a fact for now, there are alternative platforms for those who object, so let’s move along.

(p.s. Lest anyone take this post as criticism of Joe’s decision, it is not. To be clear, Joe was very respectful in his comments and he did what he needed to do: he voted with his feet. When I talk about “whining,” it’s not the Joe Hewitts of the world that I’m referring to.)

Apple says: we haven’t rejected it. AT&T says: we had no say in it. Google says: [redacted].

What? Are you kidding me? This, my friends, is what the old folks call smoke and mirrors. Google needs to speak up quickly and explain that redaction.

Here’s the problem: let’s say, hypothetically, that the FCC takes action based on these letters. We the public wouldn’t know all pertinent facts that resulted in such action. We would have no way to critique their judgement. But it’s our FCC. We own it, we have a right to know.

This whole thing stinks, badly. Big companies fighting big games over consumer territory. That’s bad enough, but now one of the parties would have the federal government as leverage in their favor. And they want to do it behind a veil of secrecy. Not good.

The FCC needs to stay away and let this sort itself out in the marketplace. And Google needs to speak up.

UPDATE: Google has since un-redacted the missing pages. Props to them for doing the right thing.

I’ve been published! A while back I wrote a chapter for the Apress book iPhone Cool Projects, and it’s “on the shelves” NOW. The chapter is about, of course, streaming audio on the iPhone. It’s a pretty neat book that consists of a chapter each for seven notable iPhone apps. The authors are a wicked smart crew, I’m not really sure how I got included. Check out the book!

The authoring process was interesting and fun, a great learning process, and more work than I expected. Every day I gain more respect for people who do a lot of writing, blogging or booking. Where do they find the time? And how the heck do they generate well-structured prose so quickly? It ain’t easy, believe me.

Anyway, if you’ve bought the book already, thanks! And if you buy it in the future, thanks! Hope it’s a good read for you.