I’m : a programmer, writer, podcaster, geek, and coffee enthusiast.

Readability’s new service

I’ve always been a huge fan of Arc90’s Readability bookmarklet, which performs an article-text parse of any web page and displays the results in a highly readable, adjustable format. (It’s like Instapaper’s text view, but nicer and applied in place, instantly, to the web page you’re viewing.)

Today, they launched an entirely new Readability service: you pay a small fee each month, and they give most of the proceeds to the authors of the pages you choose (by using the Readability bookmarklet on them, or adding them in other ways). It’s a great way for readers to support web publishers, big and small, directly and automatically.

I’m working with Readability in three main ways:

Trust me, these guys really know their stuff, and their heads are in the right place: there are no sinister motives or shady practices. It works exactly the way you’d expect, and is one of the most positive, constructive efforts I’ve seen in the online publishing world in a long time.

I’m honored to be a part of it, and I can’t wait to see where it goes from here.

How should I get started with programming? Which language should I learn first?

I get these questions frequently. Keep in mind that I only “got started” programming once, and that was a very long time ago during which I was primarily thinking about which girls I liked (since I was 13 years old). But here’s how I think it works, especially for adults coming to programming for the first time:

The best way to get started is to rethink the question to be more pragmatic:

What do you want to make first?

Be specific. The answer isn’t “iPhone apps” or “websites”. An iPhone app or a website to do what, exactly?

If you don’t have a specific idea that you’re motivated to create, you’ll have a very hard time getting started and plowing through the hard parts. And there will certainly be hard parts: you’ll get frustrated, go to Google, find some guidance, bang against it for a while, then finally get it working and experience immense satisfaction for as long as you can go before hitting the next wall of frustration. Fortunately, as you get more experienced, you’ll hit those walls less frequently.

If you have a specific idea, the goal of achieving it and the incremental progress along the way will motivate you to keep going. If you don’t, every little frustration will be an excuse to give up.

Once you have that specific idea, the other questions become much easier to answer:

If you find that you truly enjoy programming, you’re very lucky: it’s a highly fulfilling hobby and can become a lucrative career if you want it to be.

Good luck.

Ode to the App Review team

I wasn’t always a fan of Apple’s requirement that all App Store submissions be reviewed by a fairly opaque process before release, which often led to confusing or unfair rejections.

But over the last year, I’ve grown to appreciate app review and the immense staff it must take to operate at its scale. We usually only see inflammatory blog posts and news articles about app review’s failures, while almost nobody ever mention its benefits. So I’m going to start.

First and foremost, the review process has created a level of consumer confidence and risk-taking that has enabled the entire iOS app market to be far bigger and healthier than anyone expected. Average people — the same people who have been yelled at for decades for clicking on the wrong button on the wrong incomprehensible dialog box and messing up their computers — can (and do) confidently buy large quantities of inexpensive apps impulsively, without having to worry that any of them will “break” their iPhones or iPads, rip them off, destroy their data, or require them to embarrassingly visit the corporate IT department, the Geek Squad, or their computer-savvy relatives (us) for help. Part of this is due to the highly sandboxed architecture enforced by the OS, but a big part is the app review process.

For software makers and trademark owners, Apple’s review process significantly cuts down on name squatters, illegal clones, piracy apps, legally risky apps (for better and for worse), and trademark infringers.1

The result of these processes is that Apple can more easily let us use their payment system without scaring their lawyers, devaluing their store’s image, or incurring high fraud and chargeback fees from their payment processors. Being in their storefront and billing system gives a lot of people an extremely easy way to pay us.

So we have a huge number of potential customers who are very comfortable installing a lot of apps and can buy ours by simply entering a password. Without app review, that market would be very different.2

Yes, they occasionally make mistakes. But these are humans — humans that, as far as I can tell, work their asses off to keep up with the massive volume of app submissions. (They seem to work a lot of overtime, too. As far as I can tell, they’re all in California, yet I’ve had apps approved late at night and on weekends regularly.)

Think of what that job must be like: plowing through an endless barrage of mostly terrible app submissions, many of which are unsuitable for the Store3, trying to evaluate people’s work against a very long list of often-subjective criteria, with the ever-present threat that an inconsistent or wrong decision might result in a shitstorm of bad press. Oh, and they only get a few minutes to decide on each app.

(And think of the email they must get.)

Despite all of that, app review gets better over time. As they’ve needed to handle ever-growing volumes of app submissions, average review times have stabilized and have actually started to get faster.

The occasional app-review mistake, in either execution or policy-making, is understandable and unavoidable. And I’d say that all of the benefits make the occasional pitfalls completely worthwhile.

App Review team: Thank you, and keep up the good work.

  1. It’s not perfect, but compare any problematic search to the same search on the Android or Chrome storefronts and see how much Apple is keeping out. ↩︎

  2. Fortunately, you can see for yourself what it would be like by looking at a competing platform’s app marketplace. It’s not pretty, and it’s not nearly as profitable. I think I’ll stay over here. ↩︎

  3. Think of the crappiest iPhone app you ever saw that made it into the store. Now imagine what they must reject. ↩︎

Send your Instapaper reading log to Readability. You’ll be directly supporting the sites that you save to Instapaper, automatically.

Verizon iPhone selling mostly to existing iPhone owners?

Instapaper’s App Store rank is very stable. It’s almost always between #2 and #5 in the paid News categories on iPhone and iPad, and usually around #90-110 in the top-paid iPad category.

Since my ranks rarely change significantly, the resulting sales volumes seem to track the entire App Store’s volume. In other words, since my rank is held mostly constant, but my sales vary, it’s reasonable to extrapolate that trends in my sales indicate approximate trends in the entire App Store market.

The results are fairly obvious: I see huge spikes whenever there’s a new iPhone, iPod Touch, or iPad released, whenever they become available in a major new country, or whenever there’s a major reason for people to buy a lot of them (like the holidays).

Here’s every major spike from November 1, 2010 to February 18, 2011, relative to the average during that period:

Here’s the sales graph from Christmas day forward:

The entire span from mid-January through February 18 has only been about 0.8 times the average since November 1, indicating a moderate month so far with no significant spikes.

But the Verizon iPhone launched on February 10.

And my sales haven’t noticed. Ranks have held nearly constant, but so have volumes.

Assuming the correlation is approximately sound, this can be explained by three possibilities:

  1. Very few Verizon iPhones have been sold. I don’t think this is likely.
  2. Verizon iPhone owners are buying very few apps relative to other iPhone owners. This also seems unlikely.
  3. Most Verizon iPhones have been sold to existing iPhone or iPod Touch1 owners, who therefore already own most or all of the apps they want. This seems like the most likely explanation by far.

At first, this worried me. I’ve been assuming that the Verizon iPhone launch was going to be a massive boom, and it looks like it’s been fairly average so far. But now I have a different theory: that the Verizon iPhone demand is from more casual buyers, by definition, and will therefore be spread gradually over the next 18 months.

In order to get a Verizon iPhone between its launch and now, a buyer would need to have either stayed up until 3 AM EST and bought before 5 AM when they sold out, or have gone to a store within the last week and hoped they were in stock. (From what I understand, stock hasn’t been widely constrained.) But, more importantly, excluding the small portion of buyers within a few months of their 2-year contract’s end date, most buyers so far had to break a contract or pay a premium for a partially unsubsidized iPhone.

My hypothesis is that most people willing and able to do that for the iPhone were also willing and able to jump carriers to get an iPhone on AT&T sometime since its release nearly four years ago. And that the huge amount of more casual Verizon buyers — the ones whose arrival to the App Store I’ve been eagerly awaiting — are far more likely to wait for their contracts to expire.

These buyers have different priorities than us geeks. They’re more patient for upgrades and more tolerant of crappy phones (after all, crappy phones are all they know). For potentially the same reasons that they didn’t jump carriers to get the iPhone, they also aren’t willing to pay the unsubsidized cost to get one early. (And they’re also more likely to choose to wait until this summer if their geeky friends tell them that the iPhone 5 is around the corner.)

So I think that, while the Verizon iPhone’s sales are going to be strong overall, it’s going to be at a far more gradual rate than people like me had initially assumed.

  1. I excluded the iPad from this based on this reasoning: if someone owned only an iPad before, and then bought an iPhone, they’d probably buy a lot of apps for the iPhone anyway instead of just sticking with their existing iPad purchases because the most popular apps on both platforms have relatively little overlap. ↩︎


Webstock 2011 was amazing.

I was one of the speakers — a great honor in itself, considering the others — and they treated me and my wife like royalty the entire time.

I can’t possibly overstate how great they were, constantly going out of the way to ensure that we had anything we could possibly want. They pre-paid for our hotel Wi-Fi, booked us for late check-outs, and even booked our rooms the night before we arrived so we could check in right after our morning arrivals from the airport, without waiting like a jet-lagged zombie until the usual afternoon check-in times at most hotels.

Many of us requested scotch or bourbon after our talks, even if that meant at 10:30 AM, and they were happy to oblige. (Josh Clark humorously requested two beers, which they delivered ornately in a champagne ice-bucket.)

We all requested alcohol after our talks because we were nervous leading up to them — not because of any negative influences, but because the conference was just so good that we wanted to make sure we matched everyone else’s presentation quality.

Every little detail mattered: this was an extremely well-designed, thoughtful conference. The badges had our names printed on both sides (so you could always see who people were) and opened up to reveal a schedule and map inside, printed upside-down so we could read them while wearing it. The technical execution was as flawless as I’ve ever seen, with enough preparation and accommodation that attendees never needed to see a presenter’s desktop, watch a projector reboot, or wait for anyone to fumble with a laptop’s video output.

The presenters wanted to be great, to push ourselves, because the rest of the conference was just so good that we were motivated to raise the bar as high as possible. Greatness inspires greatness.

And Wellington, New Zealand is a great place to spend a week, even if it takes you a day or two to get there. The weather’s amazing, the food and drinks are affordable, and the people are incredibly nice and hospitable.

I took this picture from a helicopter. We suggest doing that.

The coffee

Wellington takes its coffee seriously — more seriously than I’ve ever seen a place take its coffee — so naturally, I had to try a lot of it. The highlights:

The Museum Hotel: Our hotel room came with a Bodum French press and an electric water kettle. On check-in, they gave us a handful of generously portioned hand-taped envelopes of what seemed to be pretty freshly ground coffee for it. It was surprisingly good — by far the best coffee I’ve ever had in a hotel room, and better than much of the coffee I’ve had outside of one.

Mojo: A local chain, with locations every few blocks, serving mostly espresso-based drinks and pastries. Great presentation, good coffee. (Those little black-and-white pastries are great.)

Cafe L’affare: Espresso-based drinks only, but they offered a huge variety. This little iced shot, the Bongo On The Rocks, was great: it’s like an iced ristretto with a bit of water, a tiny amount of cream on top, and a few large granules of sugar on the bottom.

Customs Brew Bar: One of the only places serving true drip coffee, not just espresso, this was my favorite coffee place on the trip. Sorry, I didn’t take any photos of the coffee before we drank it all, because it was too good to pause for a photo.

They offer about ten single-origin coffees to choose from, with your choice of brewing method, which included the Chemex and nearly everything Hario makes. (We went with dual V60s, each with these two-person Hario serving pots below them, so we could serve four people at once.)

The alcohol

(Photo by Tiff.)

This is Houston, a bartender at The Museum Hotel. Ask him to make you an Old Fashioned with Buffalo Trace, demerara sugar, his choice of bitters, and grapefruit.

I’ll warn you, though: anyone who tries it (or even watches him make it) will want one, and you might deplete the hotel’s supply of Buffalo Trace… three times in a week.

Thank you, Webstock!

We can’t thank the Webstock organizers enough for the fun, luxurious trip to this amazing conference. I highly suggest Webstock to anyone able to attend it in the future.

Thank you so much.

Subscriptions and the new In-App Purchase requirement

Apple’s new subscription-billing requirement has generated a lot of bad press and debate. The new rule, from the App Store Review Guidelines (developer account required):

11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected

In practice, this means that any app that requires content or subscription purchases, or uses a service that does, now must either implement IAP under Apple’s terms and take a 30% cut,1 or get kicked out of the App Store.

It’s easy to accept App Store policies that are defensible for practical reasons or quality concerns — and most are. But this one’s not clearly defensible as currently implemented.

Apple’s press release quotes Steve Jobs:

“Our philosophy is simple—when Apple brings a new subscriber to the app, Apple earns a 30 percent share; when the publisher brings an existing or new subscriber to the app, the publisher keeps 100 percent and Apple earns nothing.”

This is partially defensible: Apple’s promotions in the App Store certainly bring a lot of people to apps, and it’s all happening on their hardware and platform. But if someone wants the Wall Street Journal app and finds it by searching for “WSJ” in the App Store and selecting it directly, who really brought that customer to the app?

“All we require is that, if a publisher is making a subscription offer outside of the app, the same (or better) offer be made inside the app, so that customers can easily subscribe with one-click right in the app.”

This would be a great guideline — developers should offer IAP to buy content, since it’s so easy for users that they’re likely to make more money overall with it. But forcing all app publishers with purchase systems outside of IAP to suddenly and completely adopt it in parallel has no apparent practical or pragmatic justification. Instead, it just looks like greed.

Implementation problems

Since there are so many gray areas and it’s very far-reaching, this is going to be a difficult policy to enforce consistently.

One issue is that this policy assumes that all apps are made by someone with the ability and authority to collect IAP payments on the service’s behalf, which isn’t the case for third-party clients using a service’s API.

If Twitter charged a subscription fee, or even sold any content whatsoever, no third-party Twitter clients would be permitted on the App Store, effectively preventing that entire market.

But we don’t need to look only at Twitter. There are plenty of paid services, or free services with paid upgrades, that have first- and third-party iOS apps. Some of the many examples:

What’s going to be the rule for third-party apps accessing paid services?

And if it’s acceptable for third parties to use the same types of paid APIs that would get first-party apps without IAP rejected, doesn’t that put the first-party apps at a competitive disadvantage and force an often-vague distinction between what is and isn’t “first-party”?

What happens if an app, that was previously permitted on the App Store, sells content, functionality, or services that aren’t allowed to be sold via IAP? Currently, prohibited IAP content includes subscriptions that last less than a week and any virtual currencies or credits that expire. What if your app requires something that IAP prohibits, but that you’ve been externally charging for?2

Some of the gray areas above rely on a distinction of what, exactly, is included in “content, functionality, or services in an app”. The paid features of Dropbox and Evernote, for instance, might be judged too insignificant in the context of apps to require IAP. If so, how much of a service needs to be free to get this exemption?

And what about a situation like Amazon’s Kindle app that will presumably be targeted for not selling Kindle books via IAP, even though Amazon’s catalog is so large that it surpasses Apple’s own limits on how many IAP items an app can register?

Reframing the discussion

I’ve seen three common arguments so far about this policy that I think aren’t strong and only serve to weaken the other points made around them:

But one argument that Apple should care about: this policy will prevent many potentially great apps, from many large and small publishers, from being created on iOS at all.

A broad, vague, inconsistently applied, greedy, and unjustifiable rule doesn’t make developers want to embrace the platform.

Android’s installed base is now large enough that a huge, compelling new service could launch exclusively on it. (It wouldn’t be easy, but it’s possible.) What if the developer of the next mobile killer app decides, for political or economic reasons like this, to release it only on Android?

What if major publishers, such as the New York Times or The Wall Street Journal (whose current app violates this new policy, along with Hulu, Netflix, Kindle, The Economist, and countless others), decide that they don’t want to offer their services through IAP (at 30% less revenue per customer) and just cancel their current or future iOS apps?

Don’t we all lose?

The discussion shouldn’t be whether Apple can enforce this policy, but whether they should. And if you look at what this does to developer relations, big and small, it’s easier to argue that this is likely to result in more harm than good to the iOS platform.

Update: Email from Jobs to further clarify (or confuse) the issue.

  1. The rules also prohibit apps from simply charging more in the IAP version. So, effectively, to keep anywhere near the same margin per subscriber, publishers need to either abandon iOS apps completely or raise their prices everywhere by 43%. ↩︎

  2. Instapaper’s Subscriptions currently offer nothing within the iOS apps, so I don’t expect Apple to reject Instapaper for not having IAP for its Subscriptions. But what if they do? Can I use IAP to charge for something that does nothing? ↩︎

Subscription rule not for SaaS access?

In response to an email about IAP and subscriptions affecting software-as-a-service (“SaaS”) apps such as Evernote, Dropbox, Salesforce, and arguably Readability, Steve Jobs reportedly replied:

We created subscriptions for publishing apps, not SaaS apps.

Sent from my iPhone

The response fits his style, so I’d say it’s likely that it’s real. It doesn’t really answer the question, though.

He only said that Apple didn’t create the subscriptions for SaaS apps, not whether SaaS apps can use them (are we prohibited from using them?), or whether we’re required to use them.

And even if Jobs himself would take a few minutes (during his medical leave, no less) to answer these questions more verbosely for some guy in an email, it would raise a different question: Why don’t the published guidelines reflect this clarification, and what’s stopping whoever gets your submission on the App Review team from following the literal definition?

The rule as stated, encompassing “content, functionality, or services”, sounds like it includes SaaS apps by any remotely straightforward interpretation.

If it’s rewritten and clarified to exclude functionality and services, and include only “content”, it’s still going to rely on vague definitions and a lot of gray areas, but it would solve a lot of the problems with this new rule.

(But it wouldn’t exempt Netflix or Hulu from the IAP requirement.)