Archives for : March2011

Taking the “World” out of WWDC

As I predicted (and feared), WWDC 2011 sold out in less than a day, taking only 12 hours to exhaust its supply of seats.

Erica Sadun says this means WWDC is broken, when demand so utterly exceeds supply:

Your resource scarcity is creating irrational frenzies, which hardly serves the community whose entire existence is there to support your company and its products. Today’s scenario didn’t even ensure the best developers will be there — just the fastest with a credit card.

Because Erica compares WWDC to Oracle OpenWorld, Jeff Lamarche assumes this is her recommended solution, and quickly dismisses it:

Making WWDC more like these giant, soulless, “enterprise” conferences is not the answer. Scaling WWDC to 10k, 20k or 40k is fixing the problem by shooting the golden goose. Trying to scale up WWDC like that would utterly destroy everything that is wonderful about it.

John Gruber agrees with Jeff:

It sucks that demand now outstrips supply for WWDC tickets, but I’m with LaMarche: I don’t see any way for Apple to change this other than by ruining what it is that makes WWDC great.

Actually, I agree with all three of them, but the arguments I want to correct are the ones that Jeff and John make, because I agree with Erica’s central point: a single WWDC that sells out in 12 hours is broken. Just because you don’t like the proposed solutions, it doesn’t mean there isn’t a serious problem.

But I want to make the “broken” point even more strongly than Erica did. Tickets went on sale around 8AM Eastern Daylight Time, and were gone around 7PM. I was able to get in because I was in a pretty sweet spot… Grand Rapids, Michigan, to be precise. But what about other parts of the world? Let’s look around some time zones. When it’s 8AM here in GRR, it’s 9PM in Japan. So the window of opportunity for Japan based developers ran from 9PM to 8AM, meaning that developers there who sleep “normal” hours had little realistic chance of signing up (granted, many of them have more serious problems to worry about at the moment). In Sydney, the window was open from 11PM to 10AM. In India, it was 5:30 PM to 4:30 AM. One would assume we will see very few developers from these parts of the world at Apple’s “worldwide” developer conference.

Even for those in the ideal time zones, an 11-hour window of opportunity is going to tend to favor some developers and shut out others. Anyone who needed to get approval from corporate is pretty much screwed in this scenario… how many companies will sign off on a $1,600 purchase and make the funds available at the drop of a hat? Some, sure, but many won’t. And that means we won’t see those developers at WWDC.

For some people, this isn’t a problem. On Twitter I see a sort of “cool kids” attitude… that if you care enough, you’ll find a way to get yourself there. Actually, what concerns me most on Twitter is that I see so many of the people I follow got tickets. That’s a bad thing if it means WWDC attendees are a monoculture of North American (with a handful of European) Apple fanboys.

Think you’re not going to miss corporate developers with only a tangential interest in Apple? I think you will… when the apps in non-computer fields don’t get developed, because the developers couldn’t get to WWDC, couldn’t go to the sessions or the labs, couldn’t come back to their companies with the passion, the sway, and the answers to make iOS and Mac projects happen in their firms. Want to, say, have your airline boarding pass and security check credentials all bundled up in an app that moves you to the front of the line? If Delta, Qantas, and Lufthansa couldn’t get their engineers to WWDC, maybe it’s less likely to happen. Now imagine a thousand other businesses that might contribute to the iOS and Mac ecosystems. Yeah, they’re not coming. But hipster indie developers like me? Us, you’ve got in spades.

The other thing that outsiders bring to WWDC is new perspectives. We need people from the outside to ask questions in Q&A and the labs that we might not think to ask… stuff like “does parsing XML in Cocoa really suck this bad?” Two of Apple’s biggest strengths are its seeming brutal honesty with itself (they don’t often float ill-conceived products that only got made because someone had political sway within the company), and its determination to be involved with the life and commerce of everyday people, not just geeks. A monoculture of WWDC attendees does not help them maintain those traits.

Moving WWDC across the street to Moscone North and South seems like the obvious solution, but Jeff and John are right to loathe it. The “big” Moscone is a dreadful subterranean corporate cavern, clearly designed more for debuting the 1983 Ford Thunderbird than for introducing the traits and idiosyncrasies of iOS 5. For years, I went to JavaOne in this convention center, and it was always my most hated conference. True story: talking about conferences with Dick Wall of the Java Posse, I complained about the hassle of getting around JavaOne, the inert and inept keynotes, the shameless corporate flogging sessions, and the often unrehearsed and sometimes unintelligible technical sessions. Dick, granting some of these points, maintained his enthusiasm for the conference, adding that “the best part of JavaOne is the hallway conversations”. I immediately snapped back, “if hallway conversations are the best part of your conference, then your conference sucks.” And thus sprang, fully formed, Adamson’s Third Law.

But who says bloating to a single 10-to-50,000 person event is the only option? Apple is clever, they may well think of something else, provided they think this is a problem they need to solve. For example, what if WWDC were four more or less simultaneous conferences, held in (say), Paris, New York, San Francisco, and Tokyo? You could quadruple headcount without bloating the individual event size, or the news impact of a single event (not that Apple even needs WWDC for that… events hosted on their own campus get as much play as the Moscone West keynotes). Oh sure, it would be different this way: favorite speakers like Tim Monroe (QuickTime), Bill Stewart (Core Audio), or Quinn “The Eskimo!” (DTS) could only be at one of these, and the pool of Apple developers at the labs would be diluted too. But a bunch of people who wanted to be at WWDC, and who should be, would be.

This is just one idea. There are surely other ways to fix it. But I agree with Erica that WWDC is now broken and something different really should be done for 2012.

Solving this problem would be good for Apple, and good for its developer community. Denying that it’s a problem when most iOS and Mac developers can’t get into the one official Apple developer conference? Now that’s “broken”.

We were already dead before the chip even shrank

Interesting questions are floating around about what changes iOS developers need to make, given the introduction of dual-core on the iPad 2, particularly in terms of threading. One question that came up is whether we should still default to nonatomic properties, as multiple threads could run through the getters and setters at the same time.

My opinion, at this time, and as expressed in a devforums thread, is that any code that will break under dual-core is already broken under single-core. The problem is not that two threads can execute simultaneously with dual-core, it’s that you have code sections that aren’t thread-safe and need to be. Dual-core will, at most, encounter the problem more frequently.

On iOS, we tend to make all properties involving UIKit nonatomic, meaning they do not synchronize access to the getter or setter (i.e., enforce a one-thread-at-a-time rule), for performance reasons. The reason for this really doesn’t have to do with the nature of atomicity, per se, it’s that any time you touch UIKit, you must do so from the main thread. Declaring nonatomic is just a consequence of this: the property should only be called from one thread, main, so you shouldn’t need to worry about coordinating multi-threaded access to the property. In other words, your thread management issues lie elsewhere, not with the atomicity of the property, so you can still declare these properties as nonatomic.

On the other hand, properties that aren’t related to UIKit may need to be atomic. If you think you’ll only ever call it from a single thread, fine, but if you’re not consciously enforcing that and just getting lucky, then you may be just one block, NSOperation, or callback on a mystery thread away from a nasty race condition.

In the first version of our iPhone SDK Development book, Bill and I all but ignored threading — NSOperation doesn’t even appear in the index — because we kept things simple enough that everything could be assumed to be running on the main thread. In the new world of blocks and Grand Central Dispatch, this is no longer a safe assumption, and we’d probably need to engage threading issues early. A greater awareness of threads and a willingness to use NSOperation or other threading approaches should help with performance on the new device too.

In-App Purchase Fanboys

I’ve blogged a lot about in-app purchase recently, and I’m finding that every time I tweet about it now, someone parrots back this “Apple is bringing customers to you, so be grateful” line. It’s a response that’s taking hold among Apple apologists, and I don’t think it’s nearly the counter-argument that its adherents think it is.

This argument is something that Daring Fireball’s John Gruber comes back to, notably in his Dirty Percent blog entry (more on that in a bit). But there’s a nice counter-argument in Josh Benton’s To the Victor Goes the Pricing Power (a title that parallels my own arguments that Apple is rent-seeking). Benton writes:

But if someone searches for and downloads The New York Times app — after the Times has spent more than a century building up its brand, at the cost of billions of dollars — can it really be said that Apple has “brought” that subscriber to the app, and that they deserve 30 percent of the revenue the app generates, forever? (Gruber doesn’t address the eternal nature of Apple’s cut; it’s like paying a New York apartment broker his finder’s fee, every year for the rest of your Manhattan-dwelling life.) It certainly seems like a transaction different in kind from, say, a game that exists only on (and only because) the iPhone platform.

Now back to Dirty Percent… one thing that’s interesting about this essay is the degree to which Gruber acknowledges the legitimacy of many of the arguments against Apple’s new policy. He explicitly agrees with Matt Drance’s criticism that the price matching requirement is unreasonable, is troubled by the fact that the new requirement to offer I-AP for digital products available elsewhere is “is taking away the ability to do something that they previously allowed” (in more recent entries, he’s gone further and said this feels like a bait-and-switch), and on the topic of 30% being too big a cut for doing little more than a credit-card swipe, he simply responds that “Apple… doesn’t see it this way”, neatly avoiding taking a stand himself.

Far from an absolute defense of Apple’s new I-AP policies, Gruber has wisely distanced himself from the most indefensible of Apple’s actions, and left himself some wiggle room in case things change.

The most rabid Apple defenders have also blithely ignored the inherent problems of I-AP, preferring to change the conversation to a “old media needs to change their business models” argument (which makes them sound curiously like the “everything should be free” crowd, who willingly misread Lawrence Lessig and Tim O’Reilly in order to justify content piracy). As I’ve said on a number of occasions, “if you don’t hate I-AP, you haven’t had to use it yet.”

A client of a client of mine is likely to get caught up in this I-AP drama, and in a meeting this week, we laid out exactly how I-AP works, and what they have to do in order to implement it, including entering every product into the iTunes Connect web interface, a nightmarish prospect when you have thousands of SKUs. When we finished, there was a long silence on the phone, followed by a colleague saying “you can probably imagine the look on everyone’s faces here.”

Adapting a company’s current digital storefront to incorporate I-AP is a grievously unpleasant proposition. Adding a storefront UI and Store Kit to the iOS app, plus integrating I-AP on the server side (coordinating I-AP purchases into the existing storefront, validating purchase receipts with Apple, etc.) will cost tens, if not hundreds, of thousands of dollars in developer time. More work for me as a consultant, but I can see why clients aren’t eager to spend it.

Because think about it: if the “Apple will bring you customers” argument were valid, everyone would have willingly done this back in 2009 when I-AP first hit the scene. It would have been in their self-interest to do so.

Look, I used I-AP in Road Tip because it suits the economic model of the app: I have ongoing service costs to MapQuest for every user; a data subscription plan is an appropriate way to cover that for users who continue to use the app. But it’s not necessary for other kinds of apps, like apps that view content the user has acquired elsewhere, or deluxe clients for websites that don’t work correctly in Mobile Safari (because, say, they depend on Flash).

The legitimate fear is that some content won’t be available at all for iOS because the hassle and expense of I-AP is too great. Obviously, Apple is counting on this not being the case. And I think this is a bigger deal for the small, niche content than for the big media companies. My fear is that the Apple Fanboys will go out of their way to purchase content through Apple as a political statement, so the small providers that somehow do cobble together the resources to add I-AP and enter all their content into iTunes Connect will then lose 30% on every sale that they could otherwise have run through their website. If you’re determined to pay Apple and only Apple for your content, you’d better hope they’re capable of meeting all your content needs indefinitely, because you might lose third-party content providers in the process.

Core Audio / OpenAL freak out

Just posted the following to the #coreaudio IRC channel on freenode:

[1:50pm] invalidname: OK, this was weird.
[1:50pm] invalidname: I'm writing the second example for the OpenAL chapter.
[1:51pm] invalidname: The first one loads an iLife loop into an AL buffer, attaches to a source, and just orbits it around the listener
[1:51pm] invalidname: The second example uses the AL streaming API
[1:51pm] invalidname: So I'm writing the "refiller" function, which loads from an ExtAudioFile and shares a buffer between an AudioBufferList (CoreAudio) and an AL buffer
[1:52pm] invalidname: I'm copying and pasting code from the earlier example, making changes I know about, but I've gotten a little lost about which variables are local, which are pointers from a state struct, etc.
[1:52pm] invalidname: I mean literally, I'm changing * and & just to not get compile errors.
[1:52pm] invalidname: So I build and run solely to see where it crashes
[1:53pm] invalidname: And I hear my stream playing, going from one speaker to the other.
[1:53pm] invalidname: Core Audio never works the first time. OpenAL never works the first time.
[1:53pm] invalidname: I think my Mac may be possessed.