Marco.org

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:

• Instapaper will soon provide an option to send logs of your reading activity to your Readability account if you have one, so pages you read in Instapaper will give “credit” to the publishers.
• I’ve created a special Readability edition of the Instapaper iPhone and iPad app to serve as Readability’s official mobile app, due out in the near future.
• I’m an advisor to the company.

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.

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:

• Which language should I learn first? The most platform-native, modern, commonly used language for the kind of thing you want to make. If it’s an iOS or Mac app, use Objective-C. If it’s a web app, use Python with the Django framework, or Ruby with the Rails framework. If it’s a Windows app, use C#.

  No language is “too hard” for first-timers. Programming is naturally complex and unforgiving, and that’s going to be intimidating at first. You’ll face the same challenges as a new programmer in any language.

• How should I get started? Search Google for a basic tutorial or find an entry-level book on how to make the kind of thing you want to make in your chosen language. Do a few tutorial projects, learn how to modify them to get a bit more comfortable with the language, then start your own project and deal with each wall as you hit it.

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.

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.¹

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.²

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 Store³, 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.

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

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:

• November 11, the day after a major new version that got a lot of press: 1.96 times the average.
• December 12, with a major New York Times feature: 2.86 times the average.
• December 25, Christmas day: 2.48 times the average, with a gradual decline to the average by around January 6. (My rank was nearly constant during this time.)

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 Touch¹ 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.

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.

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,¹ 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:

• Evernote’s app offers its premium accounts with IAP, but third party clients can’t. Are third-party Evernote clients now prohibited?
• Dropbox’s app doesn’t offer Dropbox’s Pro accounts at all, but the app is indirectly affected by the user’s storage space. Is additional storage space enough to qualify as “content, functionality, or services”? If so, does that put all Dropbox-syncing apps under the (impossible for them) IAP-requiring policy?
• There are a lot of first- and third-party apps that access Salesforce, LinkedIn, and 37signals’ services, all of which have paid service tiers. Will all of these be removed from the App Store if they don’t build in IAP?
• All Pinboard.in accounts are paid. Does that mean that nobody can make a Pinboard client except Pinboard itself, because nobody else can accept payments on its behalf?

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?²

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:

• “The 30% rate is too high.” It doesn’t really matter what this rate is. It could be 80% or 5% and be similarly defensible. Apple can charge whatever they want for the commission — the issue is that they’re forcing everyone to use their payment system.
• “I, or my industry, can’t afford to lose 30%.” That’s not really Apple’s problem, honestly.
• “Apple has no right to do this.” I don’t think this is legally true (antitrust concerns aside, for now). Apple can permit and prohibit whatever it wants within its platform. Just look at all of the restrictions that game-console manufacturers — or even dumbphone platforms, like Verizon’s BREW — place on their respective software publishers.

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.

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.)