Good Will Blogging
How do you like them apples...

Wil Shipley wrote a characteristically well-written and introspective post a few weeks ago, calling for paid upgrades on the Mac App Store. I heard about this from John Siracusa on Hypercritical #63 just today, so I’m a little late to this party, but here goes.

Siracusa skilfully breaks the issue down, via his listeners’ feedback, into two different but interrelated philosophical and business problems:

1. The software industry that an App Store with no paid upgrades creates.
2. The difficulties of recovering or replacing upgrade revenue for software businesses that depend on it.

The first problem is very interesting, but way beyond me to try to speculate about. The second assumes resistance to the first, that is, software businesses that are unwilling or unable to shift to a new-users-only revenue stream.

It seems to me that the answer lies in in-app purchases (IAP). There have been arguments made for IAP-based solutions by others, but all the ones I have heard focus on using IAP as a secondary revenue stream, and hoping that it all works out roughly the same. But I think there is a way to get exactly the same business model using the current App Store features.

Here’s a simulation of how it would work, using Shipley’s example:

• Delicious Library 2 is on the App Store and selling at $40.

• Bug fixes and minor enhancements are released as free updates as usual. The app version creeps up to 2.1, 2.2, …2.7.7.

• Meanwhile, Shipley & Co. are hard at work on “Delicious Library ∞”, the best thing since spit. This development is funded with the profits from Delicious Library 2.

• Finally, the big day arrives. It’s time to show Delicious Library ∞ to the world! The new version is released both as a fresh new app priced at $40 and as an IAP in Delicious Library 2 priced at $15.

• Simultaneously, the price of Delicious Library 2 is reduced (permanently) to $25. So if anyone accidentally buys Delicious Library 2, they can upgrade in-app to the latest version, and neither the customer nor Delicious Monster are any worse off than if they’d picked up the newer version.

• Both versions continue to get bug fixes and other updates.

• So far so good. Then one day, Shipley slips in the shower and hits his head. As he comes to, he sees a wonderful vision. It’s… “Delicious D”! The most delicious library the world has ever seen! The team sets to work, and after months of sweaty effort, Delicious D debuts on the App Store, again as both a new app and as a $15 IAP in Delicious Library 2 and Delicious Library ∞.

• And again, the price of Delicious Library ∞ is reduced to $25, joining Delicious Library 2 at the no-regrets price point. New customers who accidentally buy either “2” or “∞” can upgrade to the latest version for the same money as buying it outright to begin with.

• Eventually, Shipley decides to end support for Delicious Library 2. So after giving appropriate warning to his users (via the App Store release notes), the binary in the App Store is replaced with the same one used for Delicious Library ∞. So this would be a free upgrade from “2” to “∞” for those still hanging on to “2”.

• The “2” SKU remains on the store, but customers who buy either “2” or “∞” for will get the same “∞” binary. And they will be offered the upgrade to “D” in-app for $15.

• Customers who for whatever reason don’t want to upgrade from Delicious Library 2 to either of the new versions can simply ignore the update, accepting that there will be no further bug fixes to the product.

Now obviously, this is a hack. Shipley wants paid upgrades to be a baked-in feature of the App Store. But this solution is available right now. So let’s see how it stacks up.

First, it replicates the existing business model. Existing customers get to upgrade for a cheaper price, and new customers still pay the full price. Meanwhile, it’s fair to customers who buy directly from the website, since it’s possible to offer the same pricing.

Second, clearly this is a bit of a pain for the developer, since they have to maintain an SKU for every major version ever released, and also bundle the binaries of up to two versions in the older binaries. But the problem to be solved here is not the developer’s convenience. The problem to be solved is the developer’s business model. And it’s not that much bother to maintain multiple build targets, anyway.

But what about the customers? Won’t they be confused by this? Well, certainly it would be easier and simpler if there were only one app called “Delicious Library” in the App Store. But other than that, the developer has complete control of the communication once the customer buys and downloads the product. A first-time popup message in the old version could say something like, “Whoops! Did you mean to buy the latest version, ‘Delicious Library ∞’? Never fear! You can upgrade now for and pay no more than the regular price!”

(My apologies if someone else has already proposed this solution, or if this breaks some App Store rule of which I’m not aware.)

UPDATE: On further reflection, it occurs to me that this approach may even introduce a new revenue stream: Customers that wouldn’t have got on board with the product at the $40 price point, but are willing to hand over $25 for last year’s version. So on the high end, you’ve got the loyal customers who got in at $40 and pay $15 every year for the new version, and at the low end, you’ve now got a new set of customers that get in at $25 and ride the free upgrades to the old versions as you EOL the version they bought. Yes, they get free upgrades, but these are customers you wouldn’t have had at all, and if they like the product and are sufficiently impressed by the marketing of the newest version, they might decide later to give you another $15. All new revenue.

Just thought of this awesome movie idea:

Set in the near future.
“Likes” and “favs” on social networks are given monetary value.
When someone “likes” (etc.) your photo/video/status/whatever, you get a credit.
When you “like” someone else’s you use up that credit.
Enormous sums start to accrue.
The people at the top want to cash out.
But the people at the bottom are in too deep.
A few cases of violent debt collections are reported.
People get scared.
Some, out of desperation, post disturbing videos in a last-ditch attempt to win back enough credit to cover their losses.
The government is left with no choice but to post a video of a live Justin Bieber sacrifice to earn enough likes to neutralise and shut down the entire like economy.

Booyah!

As much as I would love to live the independent developer lifestyle, unfortunately, I have a day job. I work for a big financial company as a software architect and I manage a large team of engineers. For those who don’t know what the finance industry is like, one of its defining traits is an obsession with information security. As such, there is no way in hell my company would ever let me connect my iPad to the company’s network. Actually, they don’t even have a wireless network.

Nevertheless, I wanted to start using my shiny new iPad (3) in anger at work, so over the past two weeks I have ditched my trusty paper notebook for an iPad. I’ve gone all-in. Mostly I take the iPad to meetings, where I use the gorgeous Meetings for iPad to take notes. The app includes a brilliant feature to email the notes to attendees, but of course sending from my iPad meant the email would come from my personal email address. Most people wouldn’t notice that, so when they reply all to comment on something, I get emails to my personal email address. Definitely not cool with the information security folks.

Luckily, it turns out there is a simple way to get around this, using Gmail’s “send mail as” feature. Now I can send emails from my iPad and they appear for all the world to have come from my work computer. Here’s how to set it up:

1. Sign up for a new Gmail account. Yes, you’ll want a new Gmail account for this, as we’ll see later.
2. Go to Settings (now hidden in one of the two gear-icon buttons… ugh).
3. Click the Accounts tab.
4. In the “Send mail as” section, click “Add another email address you own”.
5. Type in your company email address, and deselect “Treat as an alias”. Click “Next Step”.
6. On the next screen, leave the first option selected, to send via the Gmail mail server, and click “Next Step”.
7. Click the “Send Verification” button, and check your company email. You should get a confirmation code from Google, which you can enter on the next screen.
8. Back on the Accounts tab in Gmail Settings, click the “make default” link next to your company email address. This means that all emails send from this Gmail account will use your company address by default (which is why I advise setting up a new Gmail account for this).
9. Now, on your iPad (or iPhone), set up the Gmail account as you would normally.
10. Finally, go to Google Sync on your iPad, and select the option to allow “Send Mail As”.

Now when you send an email from iPad, just select your “work” Gmail account in the From field. That’s it!