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