I don't think this is a fair comparison. You changed the business model from v1 to v2, by moving from a one time payment for unlimited articles to a pay-per-article approach.
A more suitable change would be to offer the app for free, with 10 free articles and 1 per day, and offer a one time purchase of 1.99 to lift the limits entirely, turning it into the equivalent of v1.
The way you did it is you changed it so that the act of sending an article cost money, instead of paying a small one time fee and sending as many articles as you wanted.
Based on the article, I understand exactly why it costs money - he has to pay for the server that does the hard work.
That said, as a developer I don't understand why the server is involved at all. Here's the relevant part of the article:
> The server would then fetch the article, format it, package it into a .mobi file the Kindle can deal with and send it to Amazon for delivery to the device.
I understand all this, I really do. What I don't understand is why the computer that I'm holding in my hand when I ask for the article to be converted, which is probably as powerful as the $20/mo Linode instance, can't do this conversion itself.
Surely it can fetch the article, convert it, and pop up an Email sheet with the attachment ready to go and the "to" address filled in. All it would require is for me to tap the Send button and it would get emailed to my Kindle without having the developer's server involved. This way if the developer decides to discontinue the app and take down the server everyone who purchased it isn't left out in the cold.
I agree with <tomnipotent> about being able to update the server independently of the app. That's a good reason right there (the app requires network connectivity for email, after all).
Another reason is specific to this use: Amazon distributes a Linux command line tool called KindleGen that converts HTML to .mobi formats. You could install KindleGen on a Linode box in seconds and have a proof-of-concept converter running in hours.
I suppose you could reimplement KindleGen yourself for iOS if you had unlimited free time, but it likely wasn't worth it for this particular project. Just look at the release notes for a single version of KindleGen:
-) Enabled support for JP vertical rendering and multiple page writing modes (L to R, R to L)
-) Enabled support for facing pages (left or right)
-) Enabled support for double page spreads
-) Enabled properties to support spine for fixed format content
-) Added KF8 and M7 file size stats that will be displayed after conversion
-) Added Mobi7 support for HTML tags with multiple classes (e.g., class="class1 class2 class3")
-) Data URI support for images and embedded fonts so that they can be referred directly in HTML and CSS files
-) Multiple bug fixes and enhancements.
And remember the author of the linked article wrote that the purpose of the app was to "experiment with various revenue models on the App Store..."
A server easily handling hundreds of thousands of requests per day would cost only $10 per month. And if you want to link the app price to server costs, a monthly subscription would make more sense.
True, though having the conversion logic built into the app would require no server (costing $0 per month) and scale up to billions of installs without any effort on the developer's part.
Agreed, I was quite surprised when I realized there was a pay-per-share model being attempted. I mean I'm sure it's cheap but as a consumer I HATE games/apps that do this. I'll pay to unlock features or level packs but paying for something that costs the developer nothing. The costs of the server were tiny and getting a couple hundred dollars a month from V1 sales dwarfs the server cost.
Their best bet would have probably been to just add the new features to the existing paid version behind a $1-2 IAP (One time).
Yeah that's what I was thinking. Paying per article is absurd IMO. when I started reading the article I assumed the change would be exactly as you described, x free articles and then $1.99 for full version.
Unfortunately, Apple offers a very short menu of business models to the (iOS) app developer, most of which are absurd for the developer. The very sensible approach you suggest is called a "demo" or "free trial" version by Apple and explicitly forbidden. As you should know, clarky07, since I've learned quite a few interesting things about the life of an Apple dev from your much appreciated blog posts.
Ah but the only restriction is the app can't become a brick. He was still offering 1 a day, and could probably restrict that further and be perfectly fine under that rule. In my apps I limit the things you can save. You are welcome to delete them and save more, hence the app doesn't brick, but most people like to keep their data.
They have this rule, which they claim is one of their most common reasons for rejecting and app (from Apple.com):
NOT ENOUGH LASTING VALUE
If your app doesn’t offer much functionality or content, or only applies to a small niche market, it may not be approved.
This certainly suggests that the more you cut back, the more likely you are to end up rejected entirely at some point when you submit some unrelated bug-fix upgrade for approval.
It also suggests that iOS developers can't create useful apps that are just for their own family and friends. If Apple doesn't see the benefit to their other customers, your family and friends won't be allowed to have your app.
A more suitable change would be to offer the app for free, with 10 free articles and 1 per day, and offer a one time purchase of 1.99 to lift the limits entirely, turning it into the equivalent of v1.
The way you did it is you changed it so that the act of sending an article cost money, instead of paying a small one time fee and sending as many articles as you wanted.