Software

Reiterating that Internet Explorer 9 will support both H.264 and VP8 for web video, Microsoft has decided that Chrome should too. Today they’ve announced an H.264 Extension for Chrome:

…we respect that Windows customers want the best experience of the web including the ability to enjoy the widest range of content available on the Internet in H.264 format.

I’m sure they’re pleased to be returning fire from Chrome Frame. If Great Grandma Drance were still here, she’d say “This is some movie. I should have brought my good lipstick.”

(via Nik Fletcher and Sebastiaan de With)

Apple announced iAd Producer on Monday, a new toolkit with for rapid and easy production of iAd content. The goal is clearly to increase the ease, and therefore volume, of iAd content creation moving forward.

The news resurrected some online discussion about iAd itself. Jonathan “Wolf” Rentzsch asked via Twitter:how come iAd isn’t an Objective-C based technology?

My reply was terse, so I’ll elaborate here. There are, in fact, a few reasons—both technical and non-technical—that iAd is web-based and not native.

Remote hosting

Serving targeted ads means deciding exactly what ad you’re serving, and to whom, at any given moment. The relatively lightweight assets and logic behind web content meet these needs nicely. Making the decision on the server, and then delivering the goods quickly, is what (good) web technology is all about.

Sandboxing

Why can’t the ad downloads be bundles of native code, instead of HTML/CSS/JavaScript? Isn’t native code faster? Can’t the native SDK do more than HTML5? For starters, third-party iOS apps are currently unable to load external native libraries on-the-fly. This technical restriction would have to be lifted in some fashion for native iAds to be a reality. This would be not just a huge policy reversal, but a security and stability headache as well: errant or rampant web code is generally less dangerous than errant or rampant native code. WebKit is already on every iOS device, with zero system changes. It’s not worth the trouble.

Audience

Today’s online advertising revolves around the web. The brands behind the ads, and the agencies they hire, have armies of web designers and engineers, and selling them on Objective-C is the wrong battle to fight. This is a brand-new business for Apple, with well-established competitors. If you want to steal customers, you start by making life easy for them. Combined with the sandbox issues above, the decision becomes a no-brainer.

Expansion

If iAd were a native technology, its scope would immediately be limited to “Apple platforms with a modern Objective-C runtime.” With more than 120 million iOS devices out there, and tens of millions of new Macs in the last few years, that doesn’t sound so bad. But why limit yourself? Those products can all display web-based content, along with modern computing devices from any other company.

In the long term, Apple can do anything it wants with web-based iAds: make them available to iOS web apps; place them in its own MobileMe web applications; drop them at the bottom of every iTunes Movie Trailers page; offer banners for MobileMe galleries and split the profits with the owner; include them in AppleTV content to subsidize lower rental prices (and finally turn that hobby into a business).I won’t argue Apple should do any of these things, nor do I have any idea whether or not it will. But it is reasonable to assume Apple has larger plans for iAd than what we currently see on iOS. The question is, can it gain and maintain the sponsor deals to make it a serious player in the advertising space? People are still waiting. An expanded audience and familiar, open-standard technology will only improve its chances.

I spent a significant part of my career promoting and supporting Java development on Mac OS X, so I feel the need to eulogize in light of Apple’s announcement this week.

First: there are people at Apple who care about Java enough to work endlessly on it—despite the company’s perceived sentiments. They maintained multiple JDKs, on multiple CPU architectures and OSes, for years. They architected bridges and components that provided deep Java-native integration with (at the time) unprecedented ease of use. Executive quips always make headlines, but every Java team at Apple has been talented and truly dedicated, and they deserve recognition.

And there’s the rub. Every hour of talent spent on Java is an hour not spent on the next Core Animation; the next Mission Control; the next iPhone. Apple is a consumer-focused company, and the Mac a consumer-focused product. They invested a lot early on in making Java on the desktop viable. It just hasn’t happened. I’m not particularly happy or sad about it, but desktop Java is over.

What about the iTunes back end? The online store? Don’t they use Java? That might be a rhetorically amusing question, but it’s a nonstarter. Whether Apple  has its own needs or not, supporting a few internal teams and supporting the world at large are two very different things. All that really matters is that it’s going away for us on the outside.

More importantly, server technologies are a different story. The layer with the least traction in the market on any platform—the client-side AWT/Swing UI—demanded the bulk of Apple’s efforts. Since the Intel transition, building a server VM for Darwin is almost trivial. I have to think there will at least be a viable headless OpenJDK for the Mac by the time Snow Leopard reaches end-of-life status. If there isn’t, then it’s hard to argue with this move. If Java doesn’t care about Java on the Mac, why should Apple?  It would be wonderful if Apple kickstarted a community effort by dumping its AWT source into OpenJDK, but now we’re talking about lawyers.

A lot of Java professionals use Macs for development, even if they deploy somewhere else. What will they do? If they’re using Eclipse, I think they’ll be OK. It shouldn’t take long to shim SWT on top of an OpenJDK port, and IBM has shown a lot of initiative over the years. Other “pure Java” IDEs, like JetBrains’ (superior, in my opinion) IDEA, depend on a working AWT, and therefore have some more thinking to do.

John Gruber notes that this could conveniently make it harder for Mac owners to develop for Android. I don’t think that had anything to do with the decision. This was a long time coming. Java, like Flash, is a ball and chain for a company that loathes external dependency. And you just can’t argue that client-side Java is important to the internet experience like you can with Flash.

What about the web, then? That’s another abstract technology out of Apple’s control, right? Not entirely.

The sad part is that there are a lot of passionate third-party developers who worked very hard over the years to deliver a first-class Mac experience with Java. They will have to rethink their priorities and either focus on other platforms, or think about a Cocoa port (which, on the Mac, includes not just Objective-C, but Python and Ruby as well). They can take some solace in the fact that they got more support than Carbon developers, who were arguably more committed to Apple platforms in the first place.

Don’t think that Steve and Larry talked about this, either. Oracle probably cares the least of anyone. Java’s future on Mac OS X is in the community’s hands now.

When I was in elementary school, kids walked around the schoolyard with their miniature boomboxes blasting whatever they could get their hands on. They sat on the steps showing off cassettes, unfolding liner notes, and talking about which band was better. Half of the music I still listen to today came from those recess hours, and I’d never have heard it without them.

Music has always been social. It starts both friendships and arguments, and is a huge piece of everyone’s identity. When you think about it this way, Ping seems like something that should have happened years ago. It’s already a “can’t remember life before it” feature.

What took them so long? For starters, Ping, like most social networks, has a huge potential for chaos. There are (as far as I can tell) no moderators or editors. Users do and say what they want, to whom they want. They may say things that have nothing to do with music. They may complain about iTunes, or Apple, or other Apple products and services. They may give the service a life of its own that nobody envisioned. Aside from being hosted on Apple servers, Ping’s core content appears to be largely out of Apple’s hands. It’s a leap of faith for a company that’s used to being in complete control.

That said, it probably did not take long for Apple to realize it had a hit on its hands. I suspect Ping has already more than paid for itself through new music that people were not going to buy last week, and now have.  As the iTunes catalog gets bigger, it gets harder for you to find something really good, and much harder for Apple to bring you to it. The truth is, no amount of metadata or algorithms will ever beat “your best friend loves this.” (Are you listening, Google?)

It’s interesting how much more polished the Ping UI is on iPhone than on the desktop—a testimony to where Apple thinks the money is. Whether you’re standing in line, sitting in an airport, or on the bus, Ping will help you find music with more confidence, and in less time, than ever. The desktop UI, by contrast, looks horribly rushed, and not nearly up to Apple’s usual standards for a demo, let alone a shipped product.

Was there any urgency? Hasn’t iTunes been just fine as-is? Yes, but it had pretty much run out of tricks. I suspect someone at Apple finally realized how lucky they are that Facebook hasn’t started selling music yet. 500 million connected users talking constantly about what they do and don’t like, even “Liking” official band pages and sharing videos. The only missing piece is commerce. Is Ping a threat to Facebook? Not really. But Facebook Music would be a massive threat to iTunes. By striking first, Apple doesn’t need Ping to be amazing on day one; just good enough to make would-be competitors think twice.I’m already buying more music. I shudder to think what will happen once we have Ping for books and apps.

Under the radar of this week’s WWDC news is a small but very significant change to the iPhone Developer Program License Agreement. The change is in the oft-controversial section 3.3.2. Here is the last sentence of the old copy:

No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).

Here is the new copy:

Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s). Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.

I’ve said before that Apple’s aversion to interpreted code and external runtimes is the potential for someone else to take the platform over. That’s not the whole story, though. Games in particular tend to use engines and libraries that leverage interpreted languages such as Lua. Many of these applications pose no threat, neither implicitly nor explicitly.

While explicit approval from Apple is still required, these new terms seem to acknowledge that there’s a difference between an app that happens to have non-compiled code, and a meta-platform. It’s a step that should allow for many new possibilities.