Rss

Archives for : February2011

Mobile Me Free? We’ll See.

One of the interesting Apple rumors bouncing around is the idea that MobileMe might become a free service.

I really don’t like MobileMe, or .Mac before it. I think it’s badly overpriced, charging $99 for services that are available elsewhere, and are often better elsewhere, for free.

But what I really hate about MobileMe/.Mac is a sense that Mac OS X has long been deliberately crippled in service of MobileMe. Many of the obvious and interesting uses of Bonjour, such as syncing your laptop and desktop, never appeared in Mac OS X and are obvious by their absence… and that absence is explained by the fact that Apple hoped to charge $99 to round-trip your files through their server farm, rather than performing the entire transaction within your household LAN (which, aside from being free, would be faster and more secure). Year after year, when the O’Reilly editors would ping the Mac bloggers about wishlists for MacWorld or other milestone events, I always made sure to put “an end to .Mac” as one of my requests. And I never got my wish. To quote my appearance in Chuck Toporek’s pre-Macworld 2006 ruminations: “Add to this the confusion of explaining .Mac to the switcher or new user, and I think you’ll agree that not only is .Mac overpriced, it may actually be harming the Mac platform. I hope that by the end of 2006 it [.Mac] is either free or dead.”

So maybe now we’re finally going to get it. And this is what makes me think Apple is moving in this direction: AirDrop, an announced feature in Mac OS X 10.7 (Lion), offering simple computer-to-computer file transfer, the kind of thing for which Apple had previously told us to use .Mac/MobileMe public folders. If they’re finally using Bonjour for easy computer-to-computer file transfer — like they should have been doing since about 2003 — then that makes me think that MobileMe has finally been sufficiently discredited to allow OS X to add these kinds of features.

What changed? As always with Apple, who the hell knows? But you have to think they’re at least a little surprised by the emergence of Dropbox as the de facto tool for exchanging files between your desktop and productivity applications on your iPad. Not MobileMe, and certainly not the clumsy file-exchange offered by iTunes. I’m actually really surprised by how totally Dropbox has won: all the text editors I evaluated for light on-the-go coding (*) support Dropbox, and few bother with MobileMe. Does that sting Apple? Maybe. Hopefully.

(* Textastic totally won this comparison, by the way. Not even close. If you think you ever might need to touch HTML or C or any other kind of code on your iPad, go get it.)

Now the fun question for me is, if MobileMe becomes free, will it be worth my time? I certainly don’t see a compelling reason to migrate my mail off GMail, or my documents off Dropbox, so except for the “Find My iPhone” feature, which has already been made free and which I still don’t use, it’s not clear that there’s anything there that I care about. Maybe I’m overlooking something… let me know in the comments.

Philip Hodgetts on Final Cut Pro rumors

I retweeted this already, but if you care about FCP, read Philip Hodgetts’ A new 64 bit Final Cut Pro? for some excellent analysis about what this could possibly be, given the respective capabilities and release timing of FCP, QTKit, AV Foundation, and Lion:

My biggest doubt was the timing. I believed a rewritten 64 bit Final Cut Pro would require a rewritten 64 bit QuickTime before it can be developed and clearly that wasn’t a valid assumption. Speculating wildly – to pull off a fully rewritten, 64 bit pure Cocoa Final Cut Pro – would require building on AVFoundation (the basis of iMovie for iPhone), which is coming to OS X in 10.7 Lion.

CocoaHeads Detroit, Thursday Feb. 24

In my recent post about conferences, I forgot to mention that I’ll be speaking tomorrow (Thursday) night, Feb. 24, at MobiDevDay Detroit. Except this time, I’m going to make sure the damn Core Audio demo works (it worked on Saturday morning, but not in the afternoon). Also, even though the talk is already too damn long, I’d like to squeeze in two more slides: one for Accelerate, and the other for AirPlay.

For all you conspiracy theorists…

One more nugget about the I-AP subscription dustup (my previous blogs: 1, 2), particularly for all you conspiracy theorists who loves you some nefarious skullduggery!:

What if the real story here is that Apple has decided to release an AppleTV SDK later this year? Streaming media apps would be far and away the most appropriate use of such an SDK — nobody needs Twitter clients for their TV or Angry Birds with a tiny D-pad — and by establishing a 30% tax on content now, it would be a fait accompli by the time the first Hulu, NFL, and Crunchyroll streams roll through port 80.

Not that I have any reason to think this is what’s going on. I’m just putting out there now in case I get lucky and get to do the “told you so” happy dance later.

You’re welcome. Happy conspiring!

Apple’s Full Employment for Data Entry Workers Act

Talking with a colleague from Cocoaheads Ann Arbor last night, I stumbled across an even bigger objection to Apple’s new “must offer in-app purchase if app content is available elsewhere” rule, beyond those that I covered in In-App Purchase and Rent Seeking.

The problem is that to make something available for in-app purchase, you need to create an I-AP product for it in iTunes Connect. In this web interface, you enter a product ID, a description in whatever languages you want to support, and set a price. To get approved by apple, you also have to submit a screenshot of the purchased product in the application.

Apparently, the web interface is the only way to create products.

And if you’re thinking “that doesn’t scale”… well, yeah, that’s what we suddenly realized. If you’re Amazon, and you have 810,000 Kindle books, does Apple seriously expect you to submit all 810,000 of those, one at a time, and with screenshots, via the ITC web interface?

Even if that’s possible, even if you think that content providers won’t utterly balk at the impracticality of it, let’s tease this out a little further. Add in the hundreds of thousands (or millions?) of titles available for the Barnes and Noble Nook. And 20,000 Netflix streaming titles, and so on… how on Earth is Apple seriously going to review and approve all these products? If we just assume 2,000,000 products need to be added by the June 30 deadline, and we assume each could be reviewed in about five minutes, then that’s 12 products per person-hour, meaning Apple would need over 160,000 person hours just to approve all these products. Divide again by 8-hour days and 130 days between now and June 30, and they’d need 160 employees doing nothing but reviewing I-AP products for this to work.

This, clearly, is madness.

The benign and simplest explanation for all of this is that Apple has painted itself into a corner, that it hasn’t really thought through all these issues. And if that’s the case, something will have to give: a bulk-submission tool, lax review of products, or (ideally) an abandonment of the new rent-seeking policy.

Conspiracy theorists could also pick up this ball and run with it: the premise that Apple is using an unreasonable and unworkable I-AP system to get content providers off the platform, leaving Apple as the sole seller of books and movies and such on iOS (while still being able to say “hey, they’re the ones who bailed on the platform”), is arguably consistent with the facts. I think it’s implausible… but not impossible.

I have to acknowledge one thing has gotten better: the new auto-renewing subscriptions are restored by -[SKPaymentQueue restoreCompletedTransactions], meaning it’s now actually practical to get a user’s new iOS device to recover subscriptions purchased with their iTunes account on previous devices. This is what I was complaining about in bug 7470096, and the new purchase type looks a lot more practical and thought-out. I feel like I should update Road Tip to use these subscriptions (and therefore gain restorability across devices), but anytime I touch that code, it’s throwing good money after bad, so it will be hard to justify for any reason other than shame that the current version is so compromised by the impracticality of the old I-AP subscriptions.

Spring 2011 conferences

A quick update on upcoming conference talks…

  • Next Saturday, February 19, is MobiDevDay Detroit at the Compuware building downtown. I’ll be doing a talk on iOS Multimedia, a high-level overview of the various media frameworks (AV Foundation, Core Audio, Open AL, Media Library, etc.), with an emphasis on the practical questions of “which one do I pick for my application”. They’ve asked me to do the talk twice, once in the morning and once in the afternoon, so feel free to check out the other iOS talks from Dave Koziol, Chris Judd, Henry Balanon, et. al.

  • In April, I’ll be in Seattle for another round of the Voices That Matter: iPhone Developer Conference. This time, I’m doing Advanced Media Manipulation with AV Foundation, which will cover advanced AV Foundation topics like capture-time media processing, editing with effects (and exporting them), sample-level access, etc. It’s kind of a follow-up to the AV Foundation intro I did at VTM in Philly in the Fall, except that we can’t assume that attendees were there for Philly, so I’ll probably start with an abbreviated AV Foundation intro before getting into the rough stuff. I’ve also told the conference organizers that I could do the intro talk if a spot opens up that they need to fill, though I don’t actually suspect that’ll happen.

  • I’m going to update the blog’s right colum with a badge for the conference as soon as I post this entry, but in the meantime, here’s a registration code for you: SEASPK2. That’s good for $100. If combined with Early Bird pricing (ends Feb. 25), you’re in the door for $395. Which is, like, what, a quarter of what you’d pay for WWDC? Plus, hey, smaller crowds, indie speakers, Seattle (Shorty’s is two blocks from the conference hotel)… it’s just packed with win.

Annnnnd… now I need to get cracking on my slides for MobiDevDay in a week…

WWDC Tips

Apropos of nothing other than, I guess, the rumored dates for WWDC 2011, a colleague whom I met at Voices That Matter asked me for some WWDC tips.

My response got long enough that I asked if it would be OK to repurpose as a blog entry. Nothing here that’s particularly unique or special, I suppose, but he said he wasn’t finding other WWDC tips, so maybe this is a topic that needs to get kicked around the Mac/iOS blogosphere.

  • SELLOUTS: Rapid conference sellouts are becoming the norm. Last year’s WWDC sold out in eight days. CodeMash sold out in less than three. Google IO sold out in under an hour. If you’re serious about going, you’d better plan on registering as soon as it’s announced. The way things are accelerating, I bet WWDC will sell out in a day this year.
  • HOTELS: Check with someone else, because my approach is peculiar. I’ve picked up the habit from a colleague of mine, a former O’Reilly and Prags guy, of not staying down in the Moscone area, but rather partway across town at a small bed-and-breakfast called The Queen Anne near Japantown, and then walking a block each morning to catch a MUNI bus to Union Square and walk southeast from there past the Apple Store, Market St., and the Metreon to Moscone. It means going back to the room is impractical — when I go downtown, it’s for the whole day — but that’s never been a problem for me.
  • DINING: You get breakfast and lunch every day at Moscone. It’s about what you’d expect from meals for 6,000 people, but you’re at WWDC for the knowledge and the company, not the dining. You’re on your own for dinners. There’s a ton of stuff in the area there, especially if you walk north to Market St. or Union Square. A lot of people go across the street to the Metreon’s food court to escape WWDC, but I find it mediocre and crowded… instead, go north to the Emporium mall (you can enter through Bloomingdale’s, which you can see from Moscone West), which has two food courts, the larger one with some real variety and not too expensive.
  • EVENING EVENTS: The ADC awards are OK. I’ve never hung around for “Stump The Experts”, but that’s apparently a charming tradition. Thursday night bash is usually a lot of fun… more or less unlimited food, plus drink tickets, so hold off eating until you get there.
  • NOTES: In 2008, they didn’t post videos or slides until five months after the event. So, in 2009, I went in and took copious notes in every session… and then they released videos and slides the next week. In 2010, the videos and slides were made available to non-attendees for free, which was a first. If you like note-taking, get SubEthaEdit — there is a tradition of real-time collaborative note-taking at WWDC, and many hands lighten the load.
  • LABS: The labs are the most underappreciated and underused part of WWDC. When else are you going to get face-to-face access to Apple engineers? When you get big code questions or “that just bugs me” problems, set them aside and whip up a simple code example to take with you, and you can get the people who write the system and the libraries to help you. The years I went, I got massive pain relief on Game Kit and Core Audio from their respective labs.
  • OTHER POINTS:
    • Don’t lose your badge. They won’t replace it.
    • Moscone is within walking distance of BART, which runs to the airport. Depending where you stay, you almost certainly don’t need a car (and with parking prices in SF, you don’t want one). If you stay far from Moscone, arrange for a shuttle bus like Lorrie’s/Go/SuperShuttle to get you from the airport to your hotel, or use taxis. Moscone has a bag check on the last day if you want to check out from your hotel and leave your suitcase at the conference for the day.
    • Leave some time for shopping Union Square and Market Street, if you’re into that kind of thing (though some of my favorite shops have closed in recent years)
    • If you’re not in line for the keynote by 7AM, you’ll probably end up in an overflow room, watching it on video. I don’t have a problem with this, but some people do.
    • WiFi at WWDC is remarkably good. Many sessions also have power strips throughout the room. If you need to download something big (like an SDK that gets released that week), the lunchroom on the first floor has ethernet drops that are crazy fast (do not try to download a 2 GB SDK off wifi).

Anyone else have some good tips? Please add comments.

In-App Purchase and Rent-Seeking

In economics, rent-seeking occurs when an individual, organization or firm seeks to earn income by capturing economic rent through manipulation or exploitation of the economic or political environment, rather than by earning profits through economic transactions and the production of added wealth.
Rent-seeking, from Wikipedia

Most of my tweets today have been about in-app purchase, first with the news of Sony’s Reader app being rejected on the basis of its purchase model, and then Apple’s clarification / de facto policy change stating that apps that offer user-purchasable content must offer Apple in-app purchase in addition to whatever other purchase methods might be available.

Matt Ingram at GigaOM nearly nails the issue in a section header:

The Landlord Will Get His Share

What Apple seeks to collect is rent, specifically monopoly rent, the ability to extract excess payments not as a consequence of a mutually-beneficial trade, but because it owns the damn store and it sets the damn rules.

I have long argued that in-app purchase can be a pretty raw deal for developers. Slide 50 from my Voices That Matter (Seattle 2010) talk, In-App Purchase: Best/Worst Thing Ever puts this in perspective:

App Store In-App Purchase
Product Hosting
Audit Trail
Purchase UI
Purchase Restoration (sometimes)
Local Purchase Storage
Apple’s Cut 30% 30%

To clarify what I mean by each of these:

  • Product Hosting: Apps are hosted on Apple’s servers. In-App Purchases go on your server (unless they’re bundled with the app and simply unlocked)
  • Audit Trail: The audit trail for an app purchase is entirely verifiable through Apple. With In-App Purchases, the developer gets a digital receipt that he or she needs to log on their own server, after validating it against an Apple webservice.
  • Purchase UI: For apps, the description, screenshots, user ratings, pricing, and purchase process are all handled by iTunes or the iOS App Store. For I-AP, the developer needs to create a UI for all of this, beyond a simple “are you sure” alert provided by Store Kit once a purchase is initiated.
  • Purchase Restoration: Users can easily re-download their old apps to a new device for free with iTunes or the App Store, once they’ve logged back into their iTunes account. For In-App Purchases, developers are expected to provide restoration of “durable” and “subscription” products, but Store Kit’s -[SKPaymentQueue restoreCompletedTransactions] method only restores the former. There is no programmatic way to discover old subscription purchases on a new device. There’s also no way to get an identifier for the iTunes account, so you don’t even have anything to associate with the subscription purchase on your own server.
  • Local Purchase Storage: iOS is responsible for storing the apps on the device’s file system. The developer is responsible for storing in-app purchases, ideally in a form that will survive crashes, wipes and restores, etc.

If you sell a $10 subscription, you do almost all the work, and yet Apple still feels it is entitled to a $3 cut for doing little more than running a credit-card swipe. Obviously, I don’t think they earn it.

If Apple’s now going to force the issue, it’s truly a sad and ugly moment for them and for all of us. How far does this concept go, after all? Consider websites that have premiere memberships, like ESPN.com or Crunchyroll. Both of them have dedicated iOS apps, since the full functionality of their Flash-heavy sites don’t work in Mobile Safari. Is Apple going to insist that these memberships be made available for purchase by I-AP as well? Or will users not be able to use iOS devices to access the online content they’ve paid for? How is that good for the platform?

It’s enough to make you hope that content providers switch to an ad-supported model and let Google make all the money. That would be just desserts, with a cherry on top.