Macworld Expo 2009 Predictions

Monday, 5 January 2009

As required by the FCC, all Mac-related web sites must publish pre-Macworld Expo predictions regarding what Apple may announce at the show. Remember: these are predictions based on little more than my own speculation and tea-leaf reading, so hold your applause until the end, and, please, no wagering. *Updated with results, Tuesday 6 July.

• New 17-Inch MacBook Pro — Seems like a sure thing. The lack of new 17-inch hardware was a glaring omission from October’s new MacBook line-up. Expect something that looks pretty much exactly like a bigger version of the new 15-inch MacBook Pro. Last-minute rumors claim that the new 17-inch MacBook Pro will have a sealed (non-user-replaceable) battery. Sounds odd, and if true, will surely generate complaints that it’s a stupid move on Apple’s part, but given Apple’s recent penchant for sealed batteries, it wouldn’t surprise me.

  Result: Correct.

• New Mac Mini — Yes. The current Mac Mini lineup is unchanged since August 2007, almost a year and a half ago. Overdue for an update, to say the least. I don’t think there’s any great enthusiasm for the Mac Mini at Apple, but it’s a strong seller.

  Result: Wrong.

• New 30-Inch Cinema Display — Yes. Much like with the 17-inch MacBook Pro, the existing 30-inch Cinema Display just looks old next to the new 24-inch model. As for a 20-inch model, I’m going to say no. 20-inch displays are the new 17-inch displays: too small.

  Result: Wrong.

• Speed Bump iMac Revisions — I’m not sure where the rumors started about there being significant changes to the iMac, but I expect what we’ll actually see will look the same as the current iMacs but offer slightly faster processors, slightly bigger hard drives, etc. Speed bump revisions don’t make for good demos, so while I expect updated iMacs this week, I don’t expect them to be announced during the keynote itself.

  Result: Wrong, but maybe kind of partial credit if I really stretch it, for saying they wouldn’t make the keynote.

• iLife and iWork ’09 — Yes, nearly a sure thing. These suites are both profitable and popular, and the current ’08 suites were released in August 2007. They’re both due for updates, and they both make for good keynote demo material.

  At the top of my personal wish list: improvements to iMovie and Pages. I see the logic behind Apple’s decision to scrap the old iMovie and start over from the ground up with iMovie ’08. But I find iMovie ’08 downright confusing. The difference between “events” and “projects” seems muddled, and it’s a clumsy tool when it comes to actually editing clips together to make a movie. As for Pages, I would love to see it gain additional professional-caliber typographic controls (including better support for OpenType fonts).

  Result: Correct, and iMovie ’09 looks like it’s exactly what I was hoping for. The new “precision editor” addresses exactly the shortcoming I found most frustrating about with iMovie ’08.

• Snow Leopard — I expect a demo, and maybe a loose release date (like, say, “first half of 2009”). As Apple emphasized when Snow Leopard was announced at WWDC last year, Snow Leopard is mainly about low-level under-the-hood improvements and optimizations to Mac OS X, not about new user-visible features. But the new Exchange integration for Mail and iCal is certainly demo-able.

  What I expect is for Apple to make old features look new, by updating the system-wide appearance theme. I’ve made this prediction several times in the past and been wrong, but eventually I’ll be right: it’s time for the last vestiges of the original Mac OS X 10.0 “Aqua” theme to go. Scrollbars and push buttons, for example, remain largely unchanged since the Mac OS X public beta in 2000. My bet says iTunes-style scrollbars everywhere, darker window chrome, and a light-text-on-dark-background menu bar.

  (The name I’ve heard for the new theme: Marble. Make of that what you will.)

  Result: Wrong.

• Updated Apple TV — Yes. I expect new hardware, but probably nothing radically new other than increased storage space. But it’ll be in the keynote as a signal that Apple is serious about this market. There’s been a lot of supposedly expert speculation that Apple is going to abandon Apple TV because it’s not a hit. But while it’s not a hit, it’s not a failure, either, and, more importantly, there is no dominant player in this field, where by “this field” I mean that for consumer-level digital media management for the living room.

  I’m not going to say that Blu-ray is dead because it isn’t. But if DVD isn’t the last mainstream physical medium for home movie distribution, Blu-ray will be. The future, obviously and inevitably, is in downloads. I’m already there, and you, dear DF reader, probably are too, but for the mass market, downloadable movies for the living room remain in the future.

  The iPhone was an instant hit, but the iPod wasn’t. Apple grew the iPod from a Mac-only peripheral into a cultural sensation slowly but steadily over three or four years. I think they have a similar long-term plan for Apple TV. And in large part Apple — along with every other hardware maker — is hobbled by the limitations of what content the movie studios will allow them to distribute. The iTunes Store’s movie library has grown significantly over the past year, but it’s still far smaller than what your neighborhood video store has to offer. And while iTunes has high definition movies available to rent, the only movies you can buy are in standard definition. That’s a studio-imposed limitation, and it’s one that works in Blu-ray’s favor, and against Apple TV’s. (Wishful thinking on my part: I’d love for Apple to announce some Boxee-like features built-in as standard Apple TV features. The TV networks seem more willing to play ball with digital distribution than the movie studios, so, maybe.)

  There are rumors that Apple might release software that allows any Mac to serve as an Apple TV. I know nothing about such software, but if you think of it more as the unification of Front Row and Apple TV, it makes perfect sense. But I don’t expect Apple to abandon selling dedicated Apple TV hardware soon — even the cheapest Mac Mini costs a few hundred bucks more than an Apple TV.

  Result: Wrong — no mention of Apple TV at all.

• iPhone Nano — No. Frankly, I just don’t get these rumors. The only way this makes sense is if it’s a replacement for the iPhone 3G — i.e. a slightly smaller form factor for the existing iPhone 3G’s features. But why now, just six months after iPhone 3G debuted? The pattern seems to be for Apple to release new iPhone hardware every summer, much like how they’ve usually released new iPod hardware in the fall. (And why “nano” rather than “mini” for something that, according to the purported third-party case designs that the rumor is founded upon, is only a little bit smaller? With iPods, “nano” is used for models that are way smaller and thinner.)

  Result: Right.

• iPhone Tethering — No, but I would love to be wrong. The longer I use my iPhone, the more frustrating it feels that my MacBook doesn’t have the same sort of nearly-ubiquitous network access. I’m one of the lucky few to have scored a copy of NetShare during its brief availability on the App Store, and there are other solutions for jailbroken iPhones, but I want Apple-style integration. I can’t see any way that this could happen without having to pay an extra monthly fee to AT&T, but if the price is even just semi-reasonable, I’d pay it in a heartbeat.

  Result: Right.

• iPhone OS 3.0 Demo — My wildcard prediction, which, I will reiterate, is based on nothing more than my own speculation and wishful thinking. One thing I’m nearly certain of is that the next iPhone OS release will be 3.0, not 2.3, if for no other reason than that there have been no developer betas since the release of version 2.2. To my nose, that smells like a major release with significant new features is in the oven.

  I fully expect iPhone OS 3.0 to be announced and demoed at least a few months before it is released. Third-party developers need time to adapt to any changes, add support for new features, and bang away on beta releases to shake out the bugs. But assuming there will be significant new features, Apple will want to unveil them at a high-profile event. If I had to wager, I’d bet on a special event around March, much like last year’s event to unveil the iPhone SDK. But if it’s going to be ready for developer betas sooner than later, it’d be a nice surprise to see Phil Schiller call Scott Forstall on stage to demo it now.

  As for what might appear in iPhone OS 3.0, here’s my wish list. First, a new home screen app (a.k.a. SpringBoard), designed from the ground up for a system where users have a few dozen or more extra apps installed. Managing dozens of apps on the iPhone today is simply a pain in the ass. Second, maybe an answer to the question of where the background notification API is — you know, the one we were told at WWDC to expect a few months ago, but which we haven’t heard a word about since. And maybe — pretty please, Mr. Forstall, with sugar on top — copy and paste.

  Result: Wrong. ★

E.T.

Saturday, 27 December 2008

Thanks to Santa Claus, I watched Steven Spielberg’s E.T. last night with my son. The last time I’d seen it was in theatrical re-release at some point in the mid-80s, when I was 10 or 11 or so. (Remember before home video, when they’d re-release hit movies into the theater a year or so after their first run?) I’m not quite sure why I hadn’t watched it since then — just one of those movies that slipped through the cracks of my I should watch that again list.

Good lord what a magnificent picture. I remember from my childhood that E.T. was exciting and sad and funny and full of wonder. And how the dynamics of Elliott’s family felt very real — not like a movie family living in a house on a soundstage, but like a real family living in a real house. What struck me watching it now is how incredible Spielberg’s filmmaking is, how pitch-perfect the performances are, how gorgeous and evocative the cinematography is, how perfect the score by John Williams is, and how clever and honest the script by Melissa Mathison is.

There are no bad guys in the film, and yet it’s filled with tension and conflict. Spielberg shoots the adults hunting in the woods for E.T. as silhouettes, mostly from the shoulders down — establishing them as bogeymen without a word of dialogue or imbuing them with any of the sinister motives you’d expect from “government agents” in a typical kid’s movie. They’re just guys doing their jobs, but yet we know to root against them, because they don’t get it — they don’t understand what we (through Elliott) do.

There’s a justifiably famous line from Arthur C. Clarke: “Any sufficiently advanced technology is indistinguishable from magic.” E.T. takes this to heart in a way that is reminiscent of 2001: A Space Odyssey. 2001 is cool and E.T. is warm, but in neither film is there any attempt to explain alien science far beyond our ken. There’s no attempt to explain how E.T.’s powers of levitation or healing work, or the mechanics of his symbiotic relationship with Elliott. They’re indistinguishable from magic and so Spielberg treats them as magic. (George “Midi-chlorian” Lucas could learn a lesson here.)

I watch a lot of kids’ movies these days, and E.T. stands out as the rare film that accurately and deeply evokes what it actually feels like to be a kid. (Particularly what it felt and looked like to be a kid in 1982; Elliott’s bedroom is filled with toys I owned.) Somewhere between E.T. and Jurassic Park, Spielberg lost his golden touch for directing child actors. I just couldn’t get enough of Drew Barrymore — so utterly adorable, but yet a genuinely frustrating and undependable seven-year-old kid sister. Henry Thomas (Elliott) comes across as bright, but very much a real 10-year-old boy. Compare and contrast to the brother and sister in Jurassic Park, who were so grating that I found myself rooting for the raptors. I think it was this general sense of dread regarding kids in a Spielberg movie that made me put off re-watching E.T. for so long. I was afraid I’d be disappointed.

But that fear was unfounded, and my memory of the film from childhood was correct. The only negative feeling the kids in E.T. evoke is jealousy, insofar as they make me wish, just as much today as in 1982, that E.T. had come to my house instead of theirs.

Jonas (just short of five years old) loved it; especially the parts where E.T. made the bikes fly. And the part where he drank beer. ★

Private

Monday, 22 December 2008

There has been much discussion lately regarding the use of private iPhone APIs. First with Google Mobile’s publicly acknowledged use of a private API to access the proximity sensor, then again with Landon Fuller’s report of having an app rejected from the App Store for appearing to use the private Cover Flow framework, when in fact Fuller created his own Cover Flow implementation from scratch because the iPhone’s system implementation has no public API.

A software platform provides a number of functions that software running in the environment can call. A public API (Application Programming Interface) is a list of these functions that are documented and supported for use by third parties writing software for the platform. The complete list of functions (or methods, classes, libraries, frameworks, or whatever specific technical terminology applies) available on the platform is usually, if not always, a superset of the functions published in the public APIs. Functions that are not in the public APIs are called private APIs or SPIs (System Programming Interface).

On the iPhone OS, like Mac OS X, APIs are divided into frameworks. Public frameworks are those with a public API for third party developers. Private frameworks are those with no public API whatsoever. Even the public frameworks, however, sometimes contain some private API calls.

There is no real technical barrier, at least in Cocoa and Cocoa Touch, that prevents third party software from calling private APIs. The public/private distinction is a social barrier, not a technical one. The difference, from a developer’s point of view, is that public APIs are more than just a list of what works now; they constitute a promise, a commitment, from the platform provider of what will continue to work in the future.

A private API call is subject to change or vanish in the future. There is some reason why a private API is private. Could be that it is here to stay, that the platform vendor simply hasn’t gotten around to documenting it yet. But it could just as easily be a stopgap that the vendor intends to completely replace. And when the platform vendor in question is an opaque entity such as Apple, you just don’t know.

With the iPhone, there’s the additional issue of the App Store license agreement, which could not be more explicit regarding the use of private APIs:

3.3.1 Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs.

App Store guidelines aside, my take on the use of private APIs is not absolute. If you, as a developer, want to use private APIs for non-essential aspects of an app, and take care to check for their existence before actually calling them, and write code that fails gracefully if they don’t, then maybe it’s OK.

But if your app depends on private APIs, or you don’t test for their existence before calling them, you risk having a mess on your hands (and your users’ hands) in the future, when a system update appears where the private APIs on which you’re relying are changed or removed.

Google Mobile is an example that may well be doing this right — or at least doing something that can’t go wrong. The private API which I publicized their use of is for the iPhone’s proximity sensor, which they’re using to enable the “just lift the phone to your ear, wait for the beep, and speak your query” feature. They’ve implemented their own code to handle the proximityStateChanged message; if proximityStateChanged goes away in a future OS update, Google’s code to handle it simply won’t get called. The lift-to-talk feature will no longer work, but the app won’t crash. Google Mobile does not depend on the lift-to-talk feature — there’s a button you can tap to initiate a voice prompt manually. The point being that private APIs should be handled with extreme caution — they’re the programming equivalent of explosive material.

What has interested me all along regarding Google Mobile’s use of the private proximity sensor API isn’t the technical aspect, but the social one: the question of whether Apple has a double standard in place regarding private API usage by Google versus typical iPhone developers.

The Theory That Some Laws Are Meant to Be Broken

After I published my initial piece on Google Mobile’s use of private APIs, Erica Sadun published a piece at Ars Technica’s Infinite Loop investigating the issue. Sadun has been a prominent iPhone developer going back to the jailbreak era, and is the author of the recently-released iPhone Developer’s Cookbook published by Addison Wesley.

Sadun, in her Infinite Loop piece, espoused the theory that “there are two very different ways that developers use non-standard calls” (where by “non-standard” she meant “unpublished or private”). These are:

Linking to private frameworks. This is the bad, the evil, the Sauron of App Store. Apple offers two sets of frameworks, or libraries that contain linkable routines for developers. There are Public Frameworks, which are fine and dandy to link to, and Private Frameworks, which are not. […]

Using unpublished APIs. If linking to private frameworks is unacceptable, unpublished APIs play the role of a minor jaywalking. You might get a ticket, a citation, and a talking to, but you’re not going to jail forever. The App Store is absolutely littered with unpublished APIs. I’ve learned to spot them pretty well. When you see applications doing things that you know they can do but that they’re not entirely supposed to be doing, you can lay odds that the developers have gently called unpublished but public routines.

This distinction was novel to me. And, upon further consideration, I deem it nonsense. The public iPhone APIs are those which are documented by Apple in the iPhone SDK. Everything else is private, whether it is a method in a public framework or a method in a private framework. They’re both just as much undocumented, just as much subject to change, and just as much in violation of the iPhone SDK license agreement.

A few days later Sadun wrote another piece for Infinite Loop, “Dumping the iPhone 2.2 Frameworks”, with instructions showing how to extract Objective-C header files listing many of the private APIs in the iPhone SDK. She published these header files on her personal web site.

Her header-dumping post does contain a cursory warning that the use of these APIs violates the SDK agreement, and that software that uses such APIs is subject to break under future iPhone OS releases, but there’s an implicit “Go ahead and use them in your own apps if you want to and it’ll probably work out just fine” attitude that pervades. Why else publish such a piece if not to encourage the use of private APIs? And why not a single word encouraging developers to file Radar bugs requesting that desired private methods be made public in the future?

Boom

This general disregard for the division between the public and the private carries over in Sadun’s book. The book contains an entire chapter on how to use the iPhone’s private Cover Flow framework. (The use of private frameworks, of course, being in Sadun’s own words, “the bad, the evil, the Sauron of App Store”.) The chapter introduction contains far more encouragement than warning:

Although Cover Flow is not officially included in the iPhone SDK, it offers one of the most beautiful features of the iPhone experience. With Cover Flow, you can offer users a gorgeously intense visual selection that puts standard scrolling lists to shame. This chapter introduces Cover Flow and shows how you can use it in your application. Boom!

It is one thing for me to lecture in the abstract regarding the dangers of using private APIs — to warn against the fact that the underlying frameworks in the iPhone OS are undergoing significant changes between releases, and that apps which make use of private APIs really are more likely to crash when running on future OS releases.

It is another thing to be able to point to a specific example where this has occurred. An example like, say, Safari Bookbag, the iPhone client for the Safari Books Online service from O’Reilly.

When iPhone OS 2.2 shipped, Safari Bookbag began crashing on launch. iPhone developer Landon Fuller investigated, and found that the source of the crash was a call to a method in the Cover Flow framework that Apple removed between iPhone OS 2.1 and 2.2:

It’s clear from the disassembly that Bookbag is using the private UICoverFlowLayer API. When Apple released iPhone OS 2.2, the -[UICoverFlowLayer initWithFrame:numberOfCovers:] method was removed, and Safari Bookbag started crashing.

It ends up that -[UICoverFlowLayer initWithFrame:numberOfCovers:] is exactly the method which Erica Sadun’s Cover Flow chapter in The iPhone Developer’s Cookbook begins with.

Fuller, as previously mentioned, is the author of Peeps, an iPhone application that provides a Cover Flow style interface for browsing your address book. After a 33-day wait in the App Store submission queue, Peeps was initially rejected by Apple on the grounds that it was using the private Cover Flow API. What made the rejection noteworthy is that Peeps was not using the private framework. Fuller had done the right thing: he wrote his own Cover Flow implementation from scratch, without the use of any private APIs:

The last thing I would do is deliver time-bomb code to a paying customer. Private API can be broken or removed at any time by the vendor, and relying on it is unfair to your customers — they rarely have any idea that the application they just purchased may not work next week, or next month.

So Fuller took the extra time to do the right thing and had his work rejected anyway because whoever it was at Apple who reviewed the submission saw “Cover Flow” and assumed, incorrectly, that it was using the private Cover Flow framework. (Fuller’s story has a happy ending: Peeps was accepted into the App Store over the weekend.)

Given the situation with Safari Bookbag, and presumably, any other application which uses the private Cover Flow framework as prescribed in The iPhone Developer’s Cookbook, this wasn’t necessarily an unreasonable assumption on the part of the App Store reviewer who initially rejected Peeps. Incorrect, unfair, and frustrating, yes — but not altogether unreasonable. Bookbag was not the only iPhone app that was caught in this framework change. Here’s a comment on Erica Sadun’s weblog from a developer who used Sadun’s Cover Flow code for an application named Yoga Trainer Pro. The version of Yoga Trainer Pro currently in the store crashes on iPhone OS 2.2 (see the customer reviews), and the updated version submitted by the developer has been rejected by Apple because it continues to use the private Cover Flow framework.

The more widespread the use of private iPhone APIs becomes, the more likely it is that the iPhone will become the sort of platform where users resist installing OS updates, on the grounds that previous OS updates “broke” third-party applications they had installed.

But so while Erica Sadun’s judgment regarding the use of private APIs may be suspect, she is no hypocrite — Sadun herself is credited as the lead developer of Safari Bookbag. Boom, indeed. ★