Archives for : January2010

Secret Video Attack Vector

Thinking about the iPad and the appealing idea of watching video on this device, the usual objections come up about being limited to the Apple iTunes ecosystem, and being shut out from great stuff, just like the AppleTV is.

But wait a second, there’s a second way to get video on your iPad, just like on an iPhone/iPod touch: apps can stream video. In fact, there are a bunch of these already. In many cases, the apps scratch the itch of certain niches. Apple continues to trot out the MLB app to show off crowd-pleasing baseball video, but I notice that I have downloaded at least four apps for streaming anime: Crunchyroll, Babelgum, Joost, and The Anime Network. Looking on the App Store, I see a few others, including one app that exists just as a container for the first volume of the charming His and Her Circumstances.

Let’s think here. Some of these services (Crunchyroll and Anime Network) offer Flash-based viewers on the web, but they’re not in the Flash business, they’re in the content business, so they use a different technology to get their content to iPhone OS viewers.

And what is that technology? By Apple fiat, it is HTTP Live Streaming, which Apple recently declared as the only permitted technology for streaming video to iPhone OS devices. Technically, it seems like you could also use HTML5 <video> tags in a UIWebView, but there are lots of nice reasons to use HTTP Live Streaming (content providers are probably happy to see DRM in the spec, even if most of us consumers aren’t).

So here’s what I’m wondering. If content providers are going to have to use HTTP Live Streaming to support all the iPhone OS devices, is this eventually going to put pressure on Flash? All that has to happen is for HTTP Live Streaming to become more viable on desktops, and then you’ll have a video distribution solution that skips the Adobe tax and the extra step of Flash encoding. HLS is supported by QuickTime X on Snow Leopard, but I don’t believe that the Windows version of QuickTime handles it yet. Pity.

Still, if I were Adobe, I’d be pretty concerned about HTTP Live Streaming right now.

Eek! A Patent!

Mike Shaver’s blog about Mozilla forgoing H.264 support in the HTML <video> tag is getting a lot of play, predictably from the /. crowd.

It’s a shame, because it’s a childish and facile argument. Here’s the gist of it.

For Mozilla, H.264 is not currently a suitable technology choice. In many countries, it is a patented technology, meaning that it is illegal to use without paying license fees to the MPEG-LA. Without such a license, it is not legal to use or distribute software that produces or consumes H.264-encoded content.

In short, the very idea that something is patented and requires licensing is prima facie proof that it is intolerable. Going on:

These license fees affect not only browser developers and distributors, but also represent a toll booth on anyone who wishes to produce video content. And if H.264 becomes an accepted part of the standardized web, those fees are a barrier to entry for developers of new browsers, those bringing the web to new devices or platforms, and those who would build tools to help content and application development.

Yeah, can you imagine if any other technology were encumbered by patents? They’d have to pass on the costs to customers too! Imagine if television were patented, or if automobiles involved 100,000 patents… surely those products could never exist and never be affordable.

There is a case to be made against patents and intellectual property as a whole, but this blog doesn’t make it. Instead, it blithely refuses to acknowledge that we do live in a world of IP, decrying its costs as if they are out of the ordinary or unjust. Ultimately, it flees back to the intellectual dead-end of “everything should be in Ogg”, a stance so untenable that even ESR conceded it was a non-starter, four years ago.

A final irony: by refusing to support H.264, Mozilla bolsters the primary alternative for video on the web: the Flash plug-in, which is not just patent-encumbered but proprietary, available only from Adobe and only in those environments where it serves the company’s strategic ends. Shaver, to be fair, admits that proprietary plug-ins are bad too, but declines to say they’re far more bad than patent-encumbered standards. Instead, he holds out for a pollyannaish vision of completely free web video technology, naming Ogg as his moral standard-bearer, without acknowledging Ogg’s lamentable but obvious feet of clay.

The Execution, Of All Things

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.

Yes, the font changed

In addition to other arbitrary changes on my system (ruining file-app association, losing the ability to stay asleep), Snow Leopard changed the default gamma, which made the white-on-black text on this blog significantly less readable at its default (small) point size. So I’ve increased the body font size slightly.

Snow Leopard also adds a new monospaced font, Menlo, which I’ve swapped in as the default font for code tags, ahead of Panic Sans, DejaVu Sans, Inconsolata, and a few other programmer favorites. If you’re getting Courier (or, heaven forbid, Courier New), you’re either not a programmer, not on a Mac, or both. FWIW, if you’re on a Mac, you should be getting Lucida Sans as the body font.

And if you read the blog with RSS, then none of this applies to you. Thanks for playing.

CodeMash 2010 wrap-up

CodeMash continues to be one of my favorite conferences to speak at and attend, both because of its convenient location — the Kalahari indoor waterpark in Sandusky, OH, just a four-hour drive from Grand Rapids — and because of its unconventional mix of topics. The concept is to bring together a variety of development styles and platforms: .NET/Java/scripting, server/client/mobile, open-source/commercial, etc. In the last few years, there’s been an increasing Mac/iPhone presence, maybe not enough to count as its own track, but certainly enough to draw attendees from some of the other technologies. And that’s the point of CodeMash: sharing ideas, and seeing what the other guys and girls are up to.

Aside: based on multiple trips to CodeMash, WWDC, JavaOne, and miscellaneous other conferences, I’m struck by how the Microsoft technologies attract far more female developers than Java or Mac/iPhone do, with the open-source scripting languages (Ruby, PHP, etc.) a distant second. Absolutely no idea what’s up with that, but suffice to say if you see a woman at CodeMash, and she’s not Dianne, then she’s quite likely a .NET developer.

This year, three of the four members of the Java Posse were in attendance at CodeMash, doing an atypically-listless panel on Wednesday night, and a bunch of sessions. I felt I should go see all my friends’ sessions, so I went to Dick Wall’s on “Funky Java” and Scala, Carl Quinn’s on tools, and Joe Nuxoll’s on Photoshop for engineers. I came away from these interested in Dick’s company’s DNA science, reminded of Hudson’s value to well-managed teams, and sadly weary of Photoshop bling and what it takes to achieve it in code. Maybe I’m just burned out by the App Store shininess arms race.

I also assisted Daniel Steinberg with his 4-hour Cocoa tutorial, built around a big example project that he wisely saved off as 20 “stages” that attendees could download and review. Daniel also did a 1-hour Cocoa session which served as outreach to developers looking at the Mac platform and not yet ready to jump in.

Attending friends’ sessions filled up most of my dance card, but I did hit a few other things. Probably the most valuable one I went to was Jim Weirich’s “Source Control for People Who Don’t Like Source Control”. The gist of this was to present the design of a hypothetical source control system with modern features and clever ideas… that turns out to be Git. Given that I have a natural aversion to anything loudly and obnoxiously touted by the Linux community as superior (usually based only on the fact that it is from the Linux community), I’ve never really given Git a serious chance, and this was an eye-opener. Git may, indeed, not suck. FWIW, his talk is available as a Pragmatic Screencast.

As for my own talks, I did a half-day iPhone tutorial that ditched the slides entirely and worked entirely from Xcode. It’s a sensible, hands-on approach that I’ll be using from now on. I did three projects: a trivial web browser, a tab-based collection of converters (since those are so damn popular in the App Store), and a conference session browser (as a navigation app). I chose these because of a conscious desire to focus on the repeated creation of view controller classes and their corresponding GUIs, which is the bread-and-butter of iPhone development. It’s good exercise to really get used to creating views in IB, wiring everything up, setting the File’s Owner class, etc. Lots of beginner problems come from missing connections, particularly VCs that aren’t wired to views, so I thought it would be good pedagogy to focus on that stuff first, even at the expense of rhapsodizing about Obj-C or covering more iPhone frameworks.

I also did a session on iPhone tricks and tips that was a mixed bag: I pulled it together kind of late, so some of the media tips were kind of pedestrian (like setting your audio session category to adjust mixing and ring/silent behavior). Still, there were a couple wows worth remembering, specifically using multiple targets to build “lite” and “full” versions, and using keychain to persist data in a way that survives wipes. Slides here

The session I think I was happiest with was “Oh Crap! I Forgot (Or Never Learned) C!” This was actually the last gasp of a book I was writing last year called Just Enough C To Program the iPhone, a language book that used the iPhone SDK as a workbench. The idea of the book was to help the scripters and Flash developers who got lost in the pointer stuff in our iPhone book, as well as first-time programmers who wanted to develop iPhone apps right away, even if they had never programmed before. In short, it would serve as the prerequisites for our, or anyone else’s, iPhone book. But it’s not happening: it’s one of those projects where everything was fine until it wasn’t.

Still, I sometimes find I enjoy the directness, the concreteness of programming in C.

So that’s something I tried to bring out in this presentation: not just that you might have to use C for some reason, like calling into native code from your higher-level language, but that C’s performance, popularity, and even its primitiveness are traits to be admired and enjoyed. The last third of it really got into the traditional C “hard parts”: pointers, malloc()/free(), pass-by-value, arrays as syntactic sugar over pointers, when struct members take the dot versus the arrow operator, memory math, etc. Slides here.

The iPhone tutorial is a consistent big draw, but I just might propose a half-day “C re-education camp” tutorial for next year, to fully immerse attendees in the C way. Maybe with some OpenGL (which is called from C) so it’s not all about the command line. Any takers?

Road Tip approved, arrives Monday

Great news: Apple has approved Road Tip, my app for finding gas, food, and lodging at upcoming exits. It will appear in the App Store on Monday.

In anticipation of the debut, I’ve set up:

The only glitch is that the in-app purchases for extending service beyond the trial period remain an issue of contention, for reasons discussed earlier. The app comes with a three-month trial period, so there’s time to resolve this before it becomes a problem.

Yes, there will finally be a Core Audio book

Answering the recurring call for a proper third-party book on Core Audio, one that doesn’t throw the reader to the wilds of picking out side-effects and ephemera from sample code and mailing lists, I’ve got an announcement…

Oh, wait, freakin’ Amazon beat me to it.

Well, the announcement is that I’m joining Addison-Wesley’s Core Audio book as a co-author to Kevin Avila.

This has been in the works for a little while, but in the last week we made it official: sending around contracts, setting up a Subversion repository, and going over the first batch of stuff that Kevin has already gotten started, with the assistance of legendary Mac programmer Mike Lee. Our editor is Chuck Toporek, who tried so hard to get me to write a real Mac book for him at O’Reilly, and I’m pleased to have the chance to work with him for the first time.

I don’t know if we can replace subscribing to coreaudio-api as a practical requirement of aspiring Mac and iPhone audio developers, but hopefully, we’ll be able to keep a few people from going nuts trying to figure out WTF error 1718449215 means (it’s kAudioFormatUnsupportedDataFormatError, and I’ll bet you tried to use floating point samples on the iPhone, didn’t you?).

2010: Prove It

Two things I’m watching for in 2010:

Android puts the lie to iPhone assumptions, or doesn’t: The limitations on the iPhone SDK and the App Store aren’t just nefarious skullduggery: there are stated reasons, in the self-interest of Apple, users, and developers for them. But how valid are they? Would background processes really drain the battery? Would un-reviewed apps really lead to a swarm of malware and network degredation? We can’t know. But if Android is going to eschew these limitations, it could provide a great experimental test. If the Android world is beseiged by garbage, villainy, and 30-minute battery lives, then Apple’s restrictions will be vindicated. But if that doesn’t happen, then it might be time to petition Mr. Jobs for an redress of grievances.

Snow Leopard needs to deliver the goods: OK, a lot of us have upgraded to Snow Leopard, with its internal clean-ups and no new features. We’re promised that the this will give us better apps as developers adopt features like Grand Central Dispatch, which makes multi-core programming more viable. But until that happens, what we’ve got is a promise and a bunch of broken device drivers (and, at least for me, a sleep mode that usually wakes up immediately after going to sleep). So, is this the year Snow Leopard pays off? Right now, fast QuickTime exports is about the only place I see my 8 cores really flying, and it doesn’t make up for the feature loss in the QTX player. And booting into 64-bit mode is a total festival of breakage (my mouse and keyboard drivers still lack 64-bit KEXTs). So I’m really waiting and hoping this pays off in a big way this year. Or at least gets better with updates: my iPhone can connect to my current client’s Exchange e-mail, but SL’s, allegedly with Exchange support, still can’t.