[Time code];

Disclaimer: there are aspects of the App Store approval process I find utterly appalling, particularly the stealth “no competing with Apple” unwritten rule.

Nevertheless, here’s a mental exercise for you. Consider the user-facing download-to-own software stores offered by the game consoles: Wii Ware, XBox Live Arcade, and PlayStation Network.

In what way is any Apple App Store policy more onerous than these stores’ developer policies?

Here are some links to help you research:

• To become an Authorized Developer for Wii, WiiWare and/or Nintendo DS/DSi
• WELCOME TO MICROSOFT CASUAL GAMES!
• SCE DevNet (almost utterly opaque… see also Developing for PS3 PlayStation Network (PSN))

Once we get past the much more expensive licensing, the pre-vetting of both product ideas (Microsoft: “Email mcg@microsoft.com with a description of your game and your contact information. We’ll send you a content submission form.”) and developers (Nintendo: “the authorization for Wii/WiiWare or Nintendo DS will be based upon your relevant game industry experience.”), and the fact that these platforms generally reject entire classes of applications (anything that isn’t a game)… I think it’s interesting to compare the anger and fury vented over the App Store, and consider that almost nobody is railing against these stores, even though they’re much more closed than Apple’s platform, and may collectively reach more users.

We might also do well to note how closed mobile development was before the iPhone. I know I’ve told this story before, but in a JavaOne conversation with O’Reilly people about how to get Java ME books moving, I said that everyone with an interest in ME (myself included) had figured out that getting your apps to end users was effectively impossible, and that with the network API often disabled for third-party apps, there wasn’t much point in writing ME apps anyways. My suggestion for an ME book that would move copies would be one which provided “the names, e-mails, and phone numbers of all the carrier and handset executives you’d have to go down on in order to get your apps on their phones.”

Fanaticism consists in redoubling your effort when you have forgotten your aim.

George Santayana, Life of Reason (1905) vol. 1, Introduction

A few weeks back, I asked the Twitterverse “When did user-facing Linux become completely and officially irrelevant? Seems like a fait accompli, doesn’t it?”. With the OSS community’s reaction to the iPad, I’m now sure of it.

And by reaction, I’m of course thinking of the response by the FSF’s John Sullivan to Steve Jobs’ much-discussed Thoughts on Flash. Sullivan’s piece is a straightforward “pox on both your houses” take, damning Apple and Adobe alike for not adopting the One True Faith of Open Source Software.

I had allowed myself to hope that the OSS community would take the hugely successful launch of the iPad and the flight of developers to the iPhone OS platform, even with Apple’s cravenly self-serving App Store policies, as an opportunity to take a good, long look in the mirror. With iPad sales now already estimated at over a million, you have to wonder how soon use of this nascent platform will exceed that of desktop Linux, if it hasn’t already. What should the open source community think of this profound preference for the unfree over the free? I would think they’d see it as a very public, and very obvious repudiation of the party line, suggestive of an urgent need for some soul-searching and time to re-examine how the OSS community is engaging the world at large.

Sullivan’s piece, sadly, shows no such self-awareness. It’s the usual total detach from real people that we’ve come to expect from True Believers. Indeed, the last third of it is the all-too-familiar zealous denunciation of all proprietary software, calling on readers to adopt Linux and Ogg Theora.

Seriously, Ogg? They’re still clinging to the “everything should be in Ogg” kick? OK, let’s ask the people who should know on this one, content professionals, to see if they buy in at all. DV magazine’s website logs 0 hits in searches for Theora and for Ogg, StreamingMedia.com’s 11 hits (versus 248 for H.264) are largely related to codec politics and not mentions in training articles or product reviews, and legendary retailer B & H assumes the search term theora is a misspelling of “theory”. No matter how many essays and insults the zealots spew forth, they seem unable to generate any inkling to know or care about Theora among video professionals.

In effect, the FSF’s position is to tell the world “screw you for not wanting the stuff we produce”, oblivious to the fact that the marketplace of ideas is very clearly telling them “screw you for not producing the stuff we want.”

The quote at the top of this article was often cited by Chuck Jones in describing the character of Wile E. Coyote, who was never afforded a moment of clarity to reconsider his hunting regimen, the inherent dangers therein, and the prospects for a way of life that didn’t involve falling off cliffs every 30 seconds. I fear the OSS community is so wrapped up in their own self-righteousness, they are similarly immune to equally-needed moments of humility, clarity, and perspective.

Last weekend was the Voices That Matter: iPhone Developers Conference in Seattle, put on by Pearson, who’s publishing our Core Audio book. However, co-author Kevin Avila handled the Core Audio talk for this conference, so I took on two topics that I had fairly deep knowledge of, thanks to my work on Road Tip.

Core Location and Map Kit: Bringing Your Own Maps

This talk starts with a basic tour of Core Location’s more or less straightforward means of getting information about your current location, getting updates as the data gets better (i.e., GPS kicks in) or you move. Then we got into Map Kit and how to get map images of any given location. The sample app for this takes a list of Apple Store locations, which I converted from CSV to a plist and stuck in the app bundle, and shows you the nearest store to a given start location. Each time you hit a + button in the nav bar, it drops the next closest store as a pin on the map and re-scales the map so that all pins are visible.

This is where it gets good. Starting from a canned location at my house, the closest Apple Store is here in Grand Rapids. The next two that come up are outside Detroit (Ann Arbor and Novi). The fourth closest store is in Milwaukee. The comedy is when you see this on the map — Milwaukee is close only if you ignore the fact that going there would involve driving 100 miles straight across Lake Michigan. Since ferries across the lake are slow and expensive, and run only in Summer, you would probably drive through or around Chicago to get to Milwaukee… and go right past 7 Apple Stores in the process.

This is a common mistake to make — I forgot to show in my slides that the apple.com retail store finder does the same thing. Still, as-the-crow-flies distance calculations, paired with map images, can be a problem. Map Kit doesn’t know anything about roads, bodies of water, geographic features, political borders, etc… all it does is serve up images, and provide a touch UI to interact with them.

The last third of the talk is about “bringing your own maps”, meaning integration with third party map data providers to get some navigational intelligence into your app. The final code sample uses the MapQuest directions web service to get actual driving distances to the first few hits, and to keep the list of locations sorted in order by driving distance. This not only keeps me from going to Milwaukee, it even smartens up the earlier results: being right on I-96, the Novi store is now my second closest result, and as it turns out, even Indianapolis is a shorter drive than going around the lake to Milwaukee.

• Slides (on slideshare.com)
• SimpleCoreLocationDemo.zip
• AppleStorePOIMapper.zip
• MQAppleStorePOIMapper.zip

In-App Purchase: Best/Worst Thing Ever

My second talk was on In-App Purchase. In many ways, it covered the same hard-earned experience that I covered in An In-App Purchase Brain Dump. I spent a little time on both the iPhone Provisioning Portal (to set up an AppID, authorize it for I-AP, and provide enough of an app submission to create purchase objects, without actually going into the review queue), and on iTunes Connect (creating purchase products). The sample app simulated an online social game, minus the game, in which users might be able to purchase digital goods like virtual clothes for their avatar. The example offered a tabbed UI with a blank view for the game, a table of purchased objects, and a table for the store. When you tap “store”, the app collects the available products with a call to Store Kit, and tapping one of them kicks off the purchase. If the purchase goes through, the item is added to the inventory page.

Of course, this is easier and demos better because it uses non-consumable products, which have always been the best-understood and best-supported class of I-AP products. I did weigh in against the still-broken subscriptions, and how they have to be restored to a user’s many devices, even though restoreCompletedTransactions doesn’t support subscriptions, and nothing in Store Kit gives you a key you can associate with the user to save the purchase on your own server.

Erica Sadun talked with me before this session and mentioned an interesting workaround. Get your user to purchase a non-consumable item, and persist its transactionId. When they purchase subscriptions, log the purchase and this other transactionId on your server. Then, when they restore on another device, they’ll get this non-consumable back and its transactionId, which you can then use to query your server for subscription purchases. Depending on the nature of your app, and how well you hide the clunkiness from the user, this could be a very viable workaround.

That said, I still think I-AP subscriptions suck and hope that Apple deprecates them soon.

The last part of the talk covers of doing commerce without I-AP, which is more viable than you might think. If you’re already selling digital goods from a web store, you can continue to do so, and make your iPhone app a rich client to your web-vended content. In this case, you’re already doing everything that I-AP offers, so there’s no reason to give Apple a 30% cut. For example, the various e-bookstores within Stanza don’t use I-AP — they go out to websites for O’Reilly, All Romance Books, etc., to complete the purchase. This might not be allowed for an iPhone-only app, but where the goods are available in multiple forms, it only makes sense for Apple to allow an iPhone app to be a rich client to such a store’s goods.

My final example is streaming anime: Crunchyroll sells premium content subscriptions on their website, and their free iPhone app lets you use the same login to get the same content. By contrast, The Anime Network has premium subscriptions on their website and via I-AP in their paid iPhone app, and credentials aren’t shared between the two. Worse, the iPhone app offers fewer videos for the same price. Their use of I-AP is bad for them (they’re paying Apple to process payments they’re already capable of handling), and bad for their users. WTF?

• Slides (on slideshare.com)
• VTMPurchaseDemo.zip

Coming next: my 360iDev slides, and the much-anticipated cleaned-up Core Audio sample code

I just got back this morning on a red-eye from 360iDev (sorry, no link; not practical to do lots of HTML editing on the iPad, which I’m typing this on) and wanted to get a few thoughts out before I collapse from sleep.

It was so nice to get back into the world of iPhone OS, as I’ve been working on a day-job contract on the Mac, with far too much exposure to the broken parts of that platform, principally the installer technologies. The cleanups and relative lack of legacy entanglements make iPhone a more pleasant platform to develop for.

The conference organizers did a bang up job of getting top tier speakers and attendees. In a final panel, the speakers were nearly all people whose apps I used: Doodle Jump, Air Sharing, and so on.

It was also nice to run into my co-author on the iPhone book, Bill Dudney, his predecessor in iPhone evangelism, Matt Drance (who, in an ironic life swap, has replaced Bill in the Pragmatic Studio seminars), MapQuest’s Carl Edwards, Double Encore’s Dan Burcaw, and three fellow members of the Ann Arbor CocoaHeads group: Tom Hoag, Dan Hibbets, and Henry Balanon.

I did a highly ambitious talk on Core Audio, using all of my 80 minutes to get deeply into audio units, applying a ring modulator effect to captured samples from the mic, and mixing it with samples from a file to produce a “Dalek sing-a-long”. I need to clean up the example code, and will likely do a post on it sometime in the future. Still, this was the kind of conference where such an advanced talk would be well received. After Denver and San Jose, it will be interesting to see where they take this conference next.

The business sessions were at least as good as the tech sessions, maybe better. Harbor Master’s Natalia Luckoynova offered a lot of vital real world lessons about making a go of the app store in her talk, and Dan Burcaw’s tales of the enterprise rang all too true.

I’m not a fan of panels, but a wrap up panel on the iPad started well, and probably would be fondly remembered had they wrapped up at the scheduled time rather than going 40 minutes over.

I don’t really have a conclusion, so I’ll end with an observation: Word Press on the iPad offers no way to scroll through the list of category checkboxes. So I will have to save this post as a draft and finish up after getting back to a full-blown computer. Or maybe use my iPhone and the mobile site. Yeah, irony.

Road Tip 1.1 is out today after a week in review, and that provides an opportunity to talk about my first foray into location-based development.

The Idea

The origins of Road Tip probably trace back to a trip to Southern California last year with my family. We were on the way back to San Diego from Disneyland, looking to grab some dinner. All kids are picky, ASD kids doubly so, which meant we were on the lookout for a Taco Bell. Not exactly a rarity, but as it turns out, California doesn’t have those blue “what’s at the next exit” signs so common in the midwest and south. Moreover, they also don’t seem to allow billboards. The practical upshot is that if you’re looking for a particular brand of roadside service, well, good luck finding it. I actually ended up typing the search term “taco bell” into the Maps app while driving 65 MPH, a stupidly foolhardy thing to do, but such was my frustration.

The thing is, it actually gets worse: Maps is only smart enough to do a radius search: it can find Taco Bells near you, but can’t account for whether they’re five miles off the freeway, or five miles behind you.

So later that Fall, I came on the idea of making an app to find stuff at exits, by taking into account your direction of travel, and looking for what would be on your way. In general, my plan would be “find exits, then find stuff near them”.

Building the thing

This actually turns out to be an interesting problem to solve. Most of the map APIs out there are built around the concept of “given a destination, how do you get there”, and give you options like taking certain kinds of roads (avoiding traffic, keeping Rain Man off the freeways, etc.). But this app is different: instead of “given destination, find a route”, it’s “given a route, find some destinations”. It also twists the usual logic of point-of-interest searching. Instead of “find stuff near a point”, it’s “find stuff along a route.”

The iPhone includes APIs for working with locations, and for providing map images, but not for working with directions. This is what Apple meant in their 2009 introduction of the iPhone 3.0 SDK when they said “bring your own maps”. I previously detailed my search for a map provider, based on the needs for an iPhone mapping application: an API that can be called from an C/Objective-C app, rich search functionality and a deep database of POIs, and license terms I can live with. I think a lot of people overlook this last point: most map websites are free, but using their data in a commercial application usually is not. I mean seriously, come on, do you think they pay their people to amass all this data and are then just going to give it to you because they like you, or because you make some speech about “information wants to be free” or some garbage like that? Puh-leeze.

Most people I know tend to default to Google Maps, but looking at it from the API point of view, they were out of the running early. They seem primarily interested in their JavaScript API, which can’t usefully be called from an iPhone app (unless you’re just writing a webapp). Their HTTP webservice-ish API has a lot of holes, and their terms didn’t seem welcome to commercial licensing.

I ended up contacting MapQuest about a commercial license, and went with their service. They have a number of APIs for various scripting languages, as well as a machine-to-machine XML API that these are all based on. I realized that as long as I was willing to send and parse a lot of XML, this would suit my needs perfectly well. After getting good results with a few proof-of-concept projects, I got in touch with MapQuest and worked out a commercial license to use their data in the app. In addition, I got access to their developer and marketing support, which has been very helpful, as I’ll get to in a little bit.

Building Road Tip

I had a few specific goals for Road Tip. I wanted it to be as un-fussy as possible. If it was going to be so distracting that it could only be used by a passenger, then there’d be no point writing it: just have your spouse or your kids do the Maps app instead. Using a smartphone while behind the wheel may not be safe, but since people (myself included) are going to do it anyways, I wanted to make the app as non-distracting as possible. So my design goals were:

• Glance-able: get the info you need with a 1-2 second glance at the screen, no longer than you’d look at a road sign or your radio.
• One-thumb control: able to be used by holding it in one hand and interacting entirely with your thumb. That means no pinch-to-zoom, no typing. I also made most of the buttons bigger than the default, to make them more hittable
• Nothing extraneous: all I want is stuff on my current freeway, not what I might find if I turn off onto other highways. And it goes without saying that an app like this cannot use banner ads.

This accounts for the high-contrast, minimalist GUI. It’s gotten me bad reviews on the App Store for not jumping into the bling arms race, but the point of the app is to not look at it for any more than a second or two. Honestly, the ideal UI for this app isn’t visual at all: it would be far more useful to do voice synthesis and recognition, having the app read out potential destinations and letting the user speak his or her choices. If we get speech in iPhone SDK 4.0, you can bet this will be something I adopt for a Road Tip 2.0.

Finding Your Way

So then there’s the whole idea of the app logic. It’s not that hard to find exits in the map data: with MapQuest’s “navt” (Navteq) coverage set, you just search for objects of display type 1736. An Exit Finder demo from MapQuest illustrates using a different database to do the same thing (this example provides road names for the exits, instead of just numbers, something I adopted in 1.1). The problem is to find the right exits. In my first version, I found all exits in a cone-shaped search region ahead of the user, not knowing what freeway they were part of. The problem was that when your freeway intersected another, you’d get info for exits that you couldn’t actually take or wouldn’t do you any good (such as the other freeways’ exits onto your current freeway). I tried to filter these out by examining exit numbers, but this approach was filled with both false positives and false negatives.

My road tests proved this out pretty quickly. Consider the intersection of I-196 and US-131 in downtown Grand Rapids:

The exit numbers only differ by about 8, so a loose rule like “ignore exit numbers off by more than 20 from other nearby exits” that works well most of the time, doesn’t work here. A worse test is US-127 south through Lansing, MI:

If you’re heading south on US-127, exit counting totally doesn’t work, because as I-496 comes in from the West, its exit numbers take over. So you count down through the 70s when suddenly, Trowbridge Road is exit 8 and the exit numbers start counting up, to Jolly Road at exit 11.

It gets even worse if you use the relative location of exits to set up your next search for more exits, as I did. In that case, finding exits for the wrong freeway ends up sending the whole search off-course.

So what I needed was to really keep track of the road the user is actually on. MapQuest’s engineers gave me some advice for a technique that is harder and costlier, but maximally accurate: find the road segments themselves. The logic I ended up going with figures out the name of the road you’re on, then searches ahead and filters and sorts only segments that match this road. The practical upshot is that Road Tip can keep its search limited to the current freeway, ignoring intersecting freeways and even stretches where multiple freeways run together.

To that end, here’s an internal debugging screen (using the built-in map tiles, sorry MapQuest), that shows how this kind of logic handles the US-127 torture test without turning onto either I-496 or I-96.

This approach also has the advantage of handing twisting roads really well. I use a series of searches for road segments, each one set up by the direction vector of the last segment of the previous search, so it doesn’t lose track of twisting roads (and, when searching all services, can kick off the gas/food/lodging search while still searching for more road segments). Here’s the debugging screen again, this time looking at I-80 East near Truckee, CA, where it goes mostly North (and occasionally a little South and a little West) on the way through the Sierras and into Nevada.

Where’s my dinner?!

With a representation of the road accurate to a matter of feet/meters, I can then search for exits, and perform radius searches around each of them for restaurants, hotels, and gas stations.

I decided there were two primary use-cases to address: either the user knows they want to exit soon and wants to look exit-by-exit for what’s available if they get off now, or the user wants to know what services are on the road ahead, regardless of distance.

For the first case, an “exits” button lists the upcoming exit as a grouped UITableView:

Each row of the table is a button. Tap it to bring up the exit’s services, presented as a tab view of gas / food / lodging / all.

For the “hold out for Taco Bell” case, you take the other navigation branch, tapping “services”. This presents a short list to indicate what you’re searching for: gas, food, lodging, or “favorites” (which you set up in the Settings application, ideally before you go driving, since it’s detail-oriented and highly distracting). This view organizes service names (restaurant and hotel chains, for example) by the exits where their locations can be found:

In either branch, the final page is a map of your selected service, relative to the exit:

What’s Next?

So that’s Road Tip as of 1.1. I’m pretty happy with the utility of the app, even if the App Store reviews and ratings are a mixed bag. I built it to suit my needs, and use it on all my long drives, and if it’s not as bling as so many tricked-out iPhone apps, well, that’s really contrary to the point of the app.

The one most useful criticism so far is that the app has a very long startup time. I need to get the current direction in order to know which way to search for road segments, and the iPhone’s GPS can take up to 30 seconds to deliver that. Ugh! However, I’ve been experimenting in the last week to see if I can deliver a “good enough” estimate to start searching, even before I get the high-confidence course from Core Location. It’s a little tricky, because the the first update from CL is usually junk. For example, consider the following map:

When I run the app at my desk and I’m not moving, point 1 is the first location provided by GPS. Problem is, point 2 is where I actually am. Draw a line between them and you’d infer that I’m moving east-southeast. So to do the estimate, I have to ignore the first update and wait for the second and third unique locations before estimating the direction of travel. Still, on the highway, I’m getting this in 5-15 seconds, which is about half the time of waiting for Core Location. So that’s going into 1.2.

After that, I don’t know… I’m very busy with a day-job Mac contract, and I really want to get back into media programming (and the Core Audio book), so this may have been a one-time-only foray into location-based iPhone app development for me. I can’t say at this point if it’s going to end up making financial sense to have spent so much time developing it and putting it out there on the App Store, but at least it’s been intellectually rewarding.

It’s easy enough to get hits with bad tech journalism: just rile the Apple fanboys. The Mobile Technology Weblog’s Microsoft Announces iPhone Killer deserves accolades for not involving any kind of actual announcement, nor in any way substantiating how its topic might be capable of “kill”ing the iPhone.

Android is a far more credible competitor to the iPhone, and as I said earlier, I’m interested to see if it can disprove some of Apple’s assertions about the way it conducts the iPhone ecosystem, such as the tightly-restricted review process or the prohibition on background apps, or if it will fail and thereby vindicate Apple. Still, whatever success Android might achieve, it’s hyperbole to posit it as an iPhone killer, at least at this stage.

Honestly, the two biggest threats I see to the iPhone come from the iPhone ecosystem itself.

In the worst case, one leads to mere tragedy, the other to catastrophe. Not that I’m predicting such a thing; I’m not a Cassandra (except when playing Soul Calibur, but that’s another story). But I do think these are issues that have the potential to cause great harm to Apple, its users, and its developers.

1. iPhone development is a bubble economy, already severely overinflated

Rilo Kiley, “The Execution of All Things“:
Soldiers come quickly, I feel the earth beneath my feet.
I’m feeling badly, it’s not an attempt at decency.

Surely only the most foolish and greedy developers at this point think they’re going to write a simple game and make a million dollars, like Steve Demeter, who pulled $250,000 in two months with the indie game Trism. The easy, early money has been made. Now there are 100,000 apps to compete with for attention, and only the top 2,000 have any significant usership.

But still, lots of developers are picking up Objective-C, learning from books like ours (thank you!), and putting their own time and money into writing their own indie apps. Even if they don’t expect to become iPhone millionaires, they’d at least like a shot at being, as Dan Grigsby aptly put it, warm, clothed, and fed with the proceeds of their iPhone work.

It’s possible the door has already largely closed to this too.

When I say that iPhone development is a bubble, I welcome you to interpret that in very literal economic terms. A developer who puts time and money into learning iPhone development does so in hopes of realizing a significant return.

And if you’re well off, well then I’m happy some for you.
But I’d rather not celebrate my defeat and humiliation here with you.

Personal case study: I put about two months of full time work into RoadTip… actually, three when you account for the month spent on the nightmare of implementing in-app purchase. That was time that I lived off a credit card, meaning I used a high-interest loan from Capital One to fund my development. I also put fixed costs, like artwork for the icon (from a former CNN colleague who used to work in the graphics department) and trademark registration on my card. So this is serious skin in the game.

After two weeks of sales, it is clear that I will never make back this investment. Not even close. I may never even make back the fixed costs, to say nothing of paying myself.

OK, there are reasons for this, not the least of which is the fact that there were no exit-finder apps when I started, and at least four others now (none of which seem to have bothered licensing their map data… would love to know how they’re not violating their providers’ terms of service). In the hit-driven App Store, you fall off your section’s “recently released” page after just a day or two, and unless you make the top 20 or have something else that makes you findable (a brand name, a well-travelled incoming link), you’re already dead.

Someone come quickly, this place was built for moving out.
Leave behind buildings, the city planners got mapped out.
Bring with you history, and make your hard earned feast.
Then we’ll go to Omaha to work and exploit the booming music scene, and humility.

If this is a hit-driven business, then the winners may be the ones who best understand marketing. And that’s the scenario by which we get lots of name-brand big-company apps, where there’s enough money to get the app in front of lots of people. The indie developer, who knows more about code than marketing, is at a severe disadvantage.

And if the risk of failure is not paying the mortgage, then it’s probably time for a lot of indies to bail out.

And this is still classic economics: too much money is in the iPhone market, chasing too little reward, and eventually there’ll be a pullback.

The question is if anyone will notice. Will the average user really miss 200 different Twitter clients or unit converters? Or is there some special, unique, topic-specific niche app that some tiny group of users would dearly love, and now will never get, because the developer who could write it is instead going to go take a contract to write the “American Idol Sing-A-Long Fun Kit”™ or god fucking knows what else?

Who knows? But much as I continue to think the world needs a touch-driven “IDE for podcasts”, something that might be extraordinary on a hypothetical OS X-powered tablet, I’m not going to risk any more of my own precious lucre developing such a thing. At this point, I expect my iPhone development to be largely for-hire works.

And we’ve been talking all night….

So that’s just sad, this one is dangerous:

2. Some of Apple’s iPhone development policies could violate anti-trust law

Anti-trust?! You should think I’m nuts. You’re probably thinking: Apple’s just a small player in a very competitive market, prone to lose their position at any time to strong competitors. You want to talk monopolies, let’s talk Microsoft.

No, I don’t want to talk monopolies. That’s the Sherman Act. I want to talk restraint of trade… the Clayton Act.

Consider this: the crux of the 90′s antitrust case against Microsoft — successfully prosecuted, if you’ll recall — was that Microsoft abused its dominant position by bundling its Internet Explorer web browser with Windows, to the disadvantage of Netscape Navigator, which had to be installed separately. Microsoft was branded as evil incarnate for the act of simply including a browser.

On the iPhone, Apple not only includes a browser, it prohibits developers from using any web-rendering technology other than WebKit.

Oh god come quickly, the execution of all things.
Let’s start with the bears and the air and mountains, rivers, and streams.
Then we’ll murder what matters to you and move on to your neighbors and kids.
Crush all hopes of happiness with disease ‘cause of what you did.

But that’s just the beginning. Consider some other technological and commercial restraints put on developers:

• You may not use any interpreted language or a virtual machine in an app.
• You must use Apple’s in-app purchase API, and pay Apple a 30% cut, for any post-sale commerce in your app.
• Effective December 2009, streaming video to an iPhone can only be delivered with HTTP Live Streaming

There’s more, but that’s enough to get us started talking about tying, the practice of compelling a customer to purchase one product as a condition of buying another. The crux of my argument is: could this be applied to Apple’s App Store policies?

Maybe, if a court is sufficiently inventive. It’s been 18 years since I took Prof. Litman’s telecomm economics class in grad school, but he was particularly interested in antitrust law, and I recall the significant issues of that area of case law. In one case — and I’m sorry, I forget if it was FTC vs. Proctor & Gamble (the “Clorox Case”) or U.S. vs. Alcoa — the court was basically willing to invent a market within the defendant company’s operations, in order to claim that the market was closed to competition.

Let’s play with this line of reasoning. Can we imagine parties that might have a complaint against Apple for shutting off a market to them?

• Sun (Java) and Adobe (Flash) for code-execution environments (i.e., interpreters and virtual machines)
• PayPal and other payment processors for selling apps and handling in-app purchases
• Adobe (Flash) and Microsoft (Silverlight) for video playback and streaming technologies
• Opera and the Mozilla Foundation for web rendering technologies

All of these companies have services that they could sell to iPhone developers, but for the fact that Apple forbids their use on iPhone by fiat. Of course developers contractually agree to that, but they don’t really have a choice: it’s Apple’s way or the highway. And you may agree that it’s better that way; that’s entirely reasonable.

But if you successfully make the argument that things like in-app purchase processing or video streaming are competitive markets, then you might have a case that Apple’s App Store terms violate the Clayton Act.

Granted, I’m not a lawyer, and if it were such a slam dunk, then it’s fair to ask: why haven’t Adobe, Sun, PayPal and the rest sued on exactly this basis? Fair enough.

Still, if we woke up next week to an antitrust investigation of Apple’s App Store practices, it wouldn’t surprise me in the least.

And lastly, you’re all alone with nothing left but sleep.
But sleep never comes to you, it’s just the guilt and forever wakefulness of the weak.
It’s just you and me….

The execution of all things.
The execution of all things.
The execution of all things.